6-8 seconds for domain checker to respond AFTER TTFB

[onliner]

Hello,

As WHMCS support couldn't reproduce the issue, I want to check if someone has experience this 'odd issue'.

Simply, when a domain check query has been entered, either as direct in the domain check box, or as a link like

https://domainxxxxx.xxx/cart.php?a=add&domain=register&query=somenewdomain.net

it takes WHMCS between 6-8 seconds just to respond to a query. In all, it can take up to 14 seconds to load the result.

I've minimized the auto search to just one TLD, and I've also disabled spotlight TLDs.

3 independent online speed test tools, return following results:

I'm using the default templates, both for orderforms and design.

Load time: 6.89 s

Fully loaded: 13.811s

Fully Loaded Time: 8.9s

I'm getting about 400ms as a TTFB.

I don't have any ideas left to try. I would appreciate any constructive input. Thanks in advance!

WHMCS 7.7.1

PHP version 7.2.19

PHP Memory Limit  1024MB

 

 

 

 

[brian!]

10 hours ago, onliner said:

I don't have any ideas left to try. I would appreciate any constructive input. Thanks in advance!

you haven't mentioned which method you're using for lookups in domain checker, e.g standard whois, domainspinning or a registrar lookup option?

theoretically, if it was standard whois, and that one TLD was an obscure TLD with a slow whois server, then I could slightly understand the delay... if it were namespinning, same situation would apply as that would probably default to using whois anyway for a TLD that eNom didn't sell.

if this is happening with major TLDs, e.g .com, then the above should be irrelevant and i'd expect far quicker responses than 14 seconds.

have you discussed the situation with your host ?

[onliner]

6 hours ago, brian! said:

you haven't mentioned which method you're using for lookups in domain checker, e.g standard whois, domainspinning or a registrar lookup option?

Same result with all of them.

 

6 hours ago, brian! said:

if this is happening with major TLDs, e.g .com, then the above should be irrelevant and i'd expect far quicker responses than 14 seconds.

Yes, no matter which TLD I select.

I'll try to reduce the currencies in the price list, currently, 20 active, to see if that makes any change.

[brian!]

5 minutes ago, onliner said:

I'll try to reduce the currencies in the price list, currently, 20 active, to see if that makes any change.

I wouldn't have thought that would matter as the table doesn't get shown again after a search...

is it any faster if you switch to using "Modern" ?

[onliner]

9 minutes ago, brian! said:

is it any faster if you switch to using "Modern" ?

No, it's the same, as it takes 6 seconds just to open(show the first pixel of the WHMCS after domain search has been initiated.

[onliner]

After deleting 12 currencies from WHMCS, I was able to lower the TTFB to 3.5 seconds from previously 6-8 seconds. Not idealistic but better.

[brian!]

7 hours ago, onliner said:

After deleting 12 currencies from WHMCS, I was able to lower the TTFB to 3.5 seconds from previously 6-8 seconds. Not idealistic but better.

I assume that you didn't have any clients using any of those currencies ??

[onliner]

8 hours ago, brian! said:

I assume that you didn't have any clients using any of those currencies ??

WHMCS doesn't allow you to delete currency if any client or invoice is using the particular currency. Which is good. Could cause too much mess otherwise.

[WHMCS Lawrence]

17 hours ago, onliner said:

After deleting 12 currencies from WHMCS, I was able to lower the TTFB to 3.5 seconds from previously 6-8 seconds. Not idealistic but better.

If deleting currencies helped, this is likely a MySQL issue as doing so would reduce the number of queries needed to display the pricing and process the request. The likely next step would be a general tuneup of MySQL on your server.

As a starting point, you may want to set max_connections to a low value like 50 and increase based on your available RAM. Other important setting are wait_timeout (at least 600, so MySQL doesn't drop connections too soon), table_definition_cache (at least 5000), sort_buffer (2-4M seems to be good), read_buffer (2-4M seems to be good) and max_allowed_packet (16M is usually fine).

Note: in MySQL, "M" means megabytes.

Once this has been done, restart MySQL and let it run for at least 48 hours. Then you can look into something like MySQLTuner to do an automatic check and see if it makes any suggestions on improvements: http://mysqltuner.com/

As always with MySQL, the above are just general starting guidelines. Ultimately, the best possible performance will require a thorough review and optimization by a qualified database administrator, but this should at least be a good start.
 

[onliner]

double post

Edited July 19, 2019 by onliner
double post

[onliner]

14 minutes ago, WHMCS Lawrence said:

If deleting currencies helped, this is likely a MySQL issue as doing so would reduce the number of queries needed to display the pricing and process the request. The likely next step would be a general tuneup of MySQL on your server.

As a starting point, you may want to set max_connections to a low value like 50 and increase based on your available RAM. Other important setting are wait_timeout (at least 600, so MySQL doesn't drop connections too soon), table_definition_cache (at least 5000), sort_buffer (2-4M seems to be good), read_buffer (2-4M seems to be good) and max_allowed_packet (16M is usually fine).

Note: in MySQL, "M" means megabytes.

Once this has been done, restart MySQL and let it run for at least 48 hours. Then you can look into something like MySQLTuner to do an automatic check and see if it makes any suggestions on improvements: http://mysqltuner.com/

As always with MySQL, the above are just general starting guidelines. Ultimately, the best possible performance will require a thorough review and optimization by a qualified database administrator, but this should at least be a good start.

Super valuable information!

In the WHMCS folder, there's both .user.ini and php.ini file. Which one shall I target? To avoid conflict as WHMCS maybe is looking for a specific file.

Thanks in advance.

[WHMCS Lawrence]

Just now, onliner said:

Super valuable information!

In the WHMCS folder, there's both .user.ini and php.ini file. Which one shall I target? To avoid conflict as WHMCS maybe is looking for a specific file.

Thanks in advance.

 

Those are configuration files for PHP - not MySQL. Generally the MySQL configuration can only be modified by the root user on the server and resides in the /etc/my.cnf file.

[brian!]

15 hours ago, onliner said:

WHMCS doesn't allow you to delete currency if any client or invoice is using the particular currency. Which is good. Could cause too much mess otherwise.

I wasn't taking for granted that you had tried to delete the currencies from inside WHMCS.... there are many ways to delete them - some not advisable... 🙂

13 hours ago, WHMCS Lawrence said:

If deleting currencies helped, this is likely a MySQL issue as doing so would reduce the number of queries needed to display the pricing and process the request.

I assumed that the queries used on that page, both pricing table and search results, would only be in the current currency and not all of them - seems a little unnecessary to me if it's doing that.

[onliner]

5 minutes ago, brian! said:

assumed that the queries used on that page, both pricing table and search results, would only be in the current currency and not all of them - seems a little unnecessary to me if it's doing that.

Well, my approach, in this case, was to disable one after another possible variable that could cause the problem. So after several tests, mostly related to templates, etc. I deleted 12 currencies. That lowered TTFB with 3 seconds. A fair trade-off I guess.

But I'll also use the recommended MySQL values by WHMCS Lawrence.

That will maybe additional decrease the TTFB with 1-2 seconds. And that is my goal, to achieve WHMCS TTFB under 1,5-2 seconds. Maybe I'm unrealistic, as their 600+ TLDs list to be loaded in conjunction with a domain search. I'll post my findings here.

 

[brian!]

36 minutes ago, onliner said:

Maybe I'm unrealistic, as their 600+ TLDs list to be loaded in conjunction with a domain search. I'll post my findings here.

aahh, the fact that there are that many TLDs will likely have an impact to some degree - that pricing array can be a hefty beast when there are a lot of TLDs to get pricing/settings for.