Jump to content
onliner

6-8 seconds for domain checker to respond AFTER TTFB

Recommended Posts

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

 

 

 

 

answer.PNG

Share this post


Link to post
Share on other sites
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 ?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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" ?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 ??

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.
 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Similar Content

    • By WHMCS ChrisD
      The following issues have been identified in the 7.7.1 release - published on 11th February 2019
      CORE-13208 - In some instances where a Domain Registration order is placed that contains only a domain, payments via 2CheckOut do not mark the invoice paid. MODULE-6979 - The convert to for processing option is not honoured with 2Checkout MODULE-6978 - Promotion codes could be deducted twice when using 2Checkout Inline mode This hotfix applies only to 7.7.1
    • By WHMCS John
      An issue has been identified in the 7.7.1 release - published on 11th February 2019, that can result in a GoCardless transaction being recorded more than once.
      This occurs when the server does not acknowledge the transaction within the GoCardless timeout period.
      This hotfix applies only to 7.7.1
    • By startover909
      I'm currently in the process of setting up WHMCS (7.5.1) along with a main site on a pretty much empty dedicated server (decent E3 with SSD). The site does not run "slow" by any means. It loads in about 650ms to 800ms on Pingdom and GTMetrix tests. What I did find curious is that it is exactly and consistently around 200ms slower TTFB compared to the same sites on the same server, mostly running Wordpress. All running the same PHP and MySQL and over SSL (so all the overheads are accounted for). So while the other site would have a TTFB of say 250ms to a given test server (including SSL handshake), WHMCS would take about 450ms, pushing it just a bit over the most "ideal" ballpark. This can be also easily verified by using Chrome's developer tool - network tool.
      Is this 200ms due to the IonCube encoding, or is the speed of the application itself just what it is? Does this number seem right to you? If you have any other PHP/MySQL site especially Wordpress running along side WHMCS on the exact same server, and not utilizing CDN's such as cloudflare that can skew the results,  do you mind doing a test and see if your WHMCS is also consistently a bit slower TTFB (test during idle times)?
      Thanks.
    • By hexonet
      Hello WHMCS fans,
       
      The domain name landscape is changing dramatically with the introduction of more than 1000 new TLDs. As well there is a significant shift towards the secondary market. Taking these factors into consideration, we decided to develop a new Domain Checker Module for WHMCS.
       
      Key Features:
       
      - Support for the new gTLDs (.BIKE, .EMAIL, .SEXY, and many others ...)
      - High-performance Domain Availability Checks using our registrar API
      - Support of NameMedia Aftermarket premium domains
      - Support of Donuts Registry premium domains
      - Support of RightSide, .BUILD, .CEO & .MENU Registry premium domains (coming soon)
      - Categorization of the TLDs in 2 levels for an improved user experience
      - Various performance optimizations
      - Ajax driven search (no page reload)
      - Easy to install
       
      We're looking for individuals around the world who are interested in beta testing our new module.
      If you are interested, please send an email to support@hexonet.net and we will send you all the required information.
       
      A public demo site is available at:
       
      http://try-whmcs.hexonet.net/
      User / Pass: demo / demo
       
      Thanks in advance.
       
      Your HEXONET Team
    • By fiberit
      I get domain unavailable for extensions: .eu .be .aero .gr
       
      I have check this issue with some long names and always get "unavailable".
  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated