WHMCS's TTFB is consistently about 200ms slower than others like Wordpress on the same server, normal?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)?
By WHMCS John
After applying the 7.5 update, you may encounter the following error:
The file /path/to/whmcs/index.php is corrupted. Where /path/to/whmcs/ is the location of your WHMCS installation.
This message occurs when the server environment does not have a sufficiently recent version of the Ioncube Loaders installed so as to meet the compatibility requirements.
This error will occur if you are running Ioncube Loaders version 10.0 or earlier. WHMCS 7.5 requires Ioncube Loaders 10.1.0 or above.
Update the IonCube Loaders installed on your server to version 10.1.0 or higher in PHP 5.6 or 7.0, then attempt the update process again.
Once the update to WHMCS version 7.5 has been completed, you may switch to a PHP 7.1 or 7.2 environment is desired.
It may be necessary to contact your server admin/hosting provider to make these configuration changes.
More information: http://help.whmcs.com/m/75601/l/851363-troubleshooting-a-the-file-path-to-whmcs-index-php-is-corrupted-error
We are running shortly our WHMCS installation 7.2.3 with Nginx, php-fpm 7.0 and almost all is running well. but we had a problem with the knowledgebase which was not reachable anymore over https://whmcsurl/knowledgebase
after installing some nginx rules like here posted we can again open the knowledgebase like https://whmcsurl/knowledgebase. but now the search is not working ( 404 not found). the question is now if someone has working nginx rules or can help with the problem?
rewrite ^/announcements/([0-9]+)/[a-zA-Z0-9-]+.html$ /./announcements.php?id=$1 last;
rewrite ^/announcements$ /./announcements.php last;
rewrite ^/downloads/([0-9]+)/([^/]*)$ /./downloads.php?action=displaycat&catid=$1 last;
rewrite ^/downloads$ /./downloads.php last;
rewrite ^/knowledgebase/([0-9]+)/[a-zA-Z0-9-]+.html$ /./knowledgebase.php?action=displayarticle&id=$1 last;
rewrite ^/knowledgebase/([0-9]+)/([^/]*)$ /./knowledgebase.php?action=displaycat&catid=$1 last;
rewrite ^/knowledgebase$ /./knowledgebase.php last;
best regards chris
Today ionCube released v4.5.0 which compatible with PHP 5.5.X.
So I updated my PHP 5.4.x to 5.5.x and installed the new loaders but when I try to access to the Administrator panel I got this error:
Please know that before you update to PHP 5.5.x because WHMCS team need to the update WHMCS files in order support the new ionCube loaders.
I have just had a really frustrating experience with ioncube and I would like to share my information in case anyone else has the same problem, or happens to google this.
The problem seems to be with the latest ioncube loaders, specifically the file "ioncube_loader_lin_5.4.so"
The latest version of this file has the filesize of 1181432 bytes. After installing this file I immediately noticed that whmcs has problems with loading, it would load once in 20 times. The error message in apache log was this:
exit signal Segmentation fault (11), possible coredump in /etc/apache2
The solution for me was to rollback to an earlier version of the file, with the filesize of "1171544" bytes.
I hope this information helps you.
Recently Browsing 0 members
No registered users viewing this page.