I'm resurrecting this thread because I've done some research into why and how this is happening. On our system, the process is unbearably slow - it takes more than 8 minutes to do the database query, and this is often further exacerbated by either A2Billing's logout timer, or the fact that anyone who actually tries this goes off to play Solitaire while they wait.
I found that the problem was with the database query being run when initially requesting the ratecard page. In MySQL I ran the following query while I was forced to wait for the new page:
Code:
SHOW FULL PROCESSLIST;
which told me that the following query was running:
Code:
SELECT SQL_CALC_FOUND_ROWS cc_prefix.destination, cc_ratecard.dialprefix, cc_ratecard.buyrate, cc_ratecard.rateinitial, cc_ratecard.startdate, cc_ratecard.stopdate, cc_ratecard.initblock, cc_ratecard.connectcharge, cc_ratecard.id_trunk , cc_ratecard.idtariffplan , cc_ratecard.id FROM cc_ratecard LEFT JOIN cc_prefix ON prefix=cc_ratecard.destination ORDER BY dialprefix ASC LIMIT 0,10;
Further research revealed that left joins are particularly expensive, and the time it takes to do them really adds up when doing them on thousands or tens of thousands of rows (we have about 40,000 rows in our ratecard table). Therefore, it is important to reduce the number of rows that we're doing right joins on. It's not feasible to reduce the actual size of the ratecard table, since allowing our customers to dial anywhere in the world is our business plan. And clearly, setting a limit on the results returned isn't doing anyone any good. So after tinkering a bit, I found that the best way to reduce the processing time in this query is to add a WHERE clause to narrow the results from the SELECT statement.
In the MySQL command line, I obtained excellent results by using some kind of default dialprefix from the cc_ratecard table. After all, the whole point of the initial rates page isn't to display all of the rates, but to ask the user for a rate to display. It would probably be an even better idea to display no results at all, and wait for the user to search for a dial prefix.
This is definitely a bug. I would post a patch if I had either the time or the expertise, but I suspect one of the regular developers on the project would be able to do it *much* faster than I could in any case. FYI, issuing a patch would be much appreciated, since our version of A2Billing has been customized somewhat, making upgrading to a new version painful at best.