Good for you, but the problem remains. After another investigation, the question again moved to MySql. As I was saying, I have old versions of Asterisk even with 10,000 sip extensions and no problem, but freepbx 15 and 16 make massive use of Mysql queries that are not fully optimized, recursive queries even for the various connected softphones (think of the recent change from replicate_cdr to trasient_cdr) and this also blocks very bulky systems from a hardware point of view.
Example mysql bug
and again
However…The moral is that if you have 1000 pjsip extensions and as many users (both local and for example from active directory) and these are inserted as dynamic agents the system goes to complete block both for Sangoma Connect and in case you want to add a new user, at best sangoma Connect also takes 2 minutes to alert itself and it also takes 45 seconds to add or update a user.
I have 31 queues, and inserted all the dynamic agents that can log in (about 600 out of 1300) as soon as this operation is performed for all the queues or in any case for a certain number, it is not possible to add users unless it takes a very, very long time .
The reason is that the system writes all this information into the sangomartapi_call_queue_members table and as can be seen with almost 20,000 rows (but if they were even just half as many it would change little) each time a query of the type
SELECT cqm.*, u.default_extension AS extension, u.fname AS first_name, u.lname AS last_name, u.displayname AS display_name
FROM sangomartapi_call_queue_members AS cqm LEFT JOIN userman_users AS u ON cqm.person_account_id = u.id WHERE cqm.call_queue_account_id = 200
and missing index on call_queue_account_id and persona_account_id
the query reads the entire table every time !
imagine adding a new user and each time scanning a 20,000 row table for just 1 insert
other queries are
SELECT * FROM userman_users WHERE default_extension = ‘923’ LIMIT 1
with no index on default_extension
and SELECT DATA FROM queues_details WHERE id = 918 AND keyword = ‘member’ ORDER BY flags, also here no index is used
so if use dynamic member with many trains the user and group system is unusable
At the same time, Sanogma Connect is unusable and upon opening it reads the indicated tables to understand which users have logged in in the queue, imagine even just 100 operators starting thousands of queries on a non-indexed table…sanogma connect uses until 2 minutes to start
This is partly solved by eliminating dynamic agents from queues and using Agent Regex Filter
It’s a shame, however, that in this case Sangoma Connect, not seeing any data in the angomartapi_call_queue_members` tab, cannot show who is logged in or on pause