Initial Server Response on a simple "Hello World" PHP file behaving erratically.

next do
Code: 
cd /usr/local/directadmin/custombuild
./build set_fastest
./build clean
./build update
./build php
./build rewrite_confs
 
lol! 21h00 yh I agree....I do need sleep. I had little last night. Lets tackle it further tomorrow. I will also do more research in to this one as well.

Thanks so much Brent! :) we had a big win with the extra 0.6s reduction in TTFB.

P.S. The build commands are running
 
btw, commands are done. restarted httpd (Apache or LiteSpeed or whatever :oops:) but still no change....

Tomorrow I will see if I can figure out more info on why it is not taking effect.
 
So I got a call from the client complaining that he can no longer access the database remotely even though his IP and host was added to the access hosts. At first I thought that maybe the firewall was blocking him so I completely disabled the firewall but the problem remained. After some fiddling, I found that disabling the bind-address in the my.cnf allows him to remotely connect again.

Do we need this bind-address setting in my.cnf?
 
No we haven't opened the port on the CSF firewall. We simply added his dyndns host in the Access hosts.

3306 is closed on CSF

I have warned him but he has a desktop client for Prestashop that he uses and prefers over the web backend of prestashop.
 
I still for some strange reason am not able to get the opcache settings implemented. I don't understand it. I have set the opcache.ini in the custombuild/custom/opcache folder and when I build the opcache again it does show that the new settings are being copied over to the cageFS skeleton but the settings are not taking effect when I check the phpinfo() page.

I'm not sure where to now on this one other than opening a ticket with CloudLinux or DirectAdmin support.
 
bluesteam said:
I still for some strange reason am not able to get the opcache settings implemented. I don't understand it. I have set the opcache.ini in the custombuild/custom/opcache folder and when I build the opcache again it does show that the new settings are being copied over to the cageFS skeleton but the settings are not taking effect when I check the phpinfo() page.

I'm not sure where to now on this one other than opening a ticket with CloudLinux or DirectAdmin support.
Click to expand...
Well you might ask CL first as it is their software. DA most likely knows as well. I just dont use CL. You might open a ticket with DA and mention the performance issue and you wanted optimize the server with opcache and see what they say..

either way report back.
 
johannes said:
Comodo ruleset can also slow down things.
Click to expand...
Thank you for this reply :-) However I don't think it is wise to switch off the rulesets entirely. So the question then is which rulesets are safe to disable that will improve the performance?

@bdacus01 I finally managed to get the opcache settings changed. The reason was because the client is not using the CustomBuild PHP selector but rather the CloudLinux PHP Selector which mean to change the default opcache settings, it needs to be done in the relevant php version's opcache.ini file which is located in /opt/alt/phpXX/etc/php.d.all.

php.d.all is a symbolic link to a folder in the same location called php.d.all.def

In this folder is the opcache.ini file where all the new settings must take place.
Once the edits are done, cageFS needs to rebuild the alt-php-ini by executing the following command:

cagefsctl --rebuild-alt-php-ini
Click to expand...

after this is executed, there won't be any output on the command line but the alt-php-ini will have updated and the new settings applied. :-D
This is confirmed in the below screenshot:
1625386988188.png


However, I ran a few tests to see if the TTFB had come down but there has unfortunately been no improvement. See below screenshot:

1625387203430.png


Any other suggestions?
 
bluesteam said:
@bdacus01 I finally managed to get the opcache settings changed. The reason was because the client is not using the CustomBuild PHP selector but rather the CloudLinux PHP Selector which mean to change the default opcache settings, it needs to be done in the relevant php version's opcache.ini file which is located in /opt/alt/phpXX/etc/php.d.all.

php.d.all is a symbolic link to a folder in the same location called php.d.all.def

In this folder is the opcache.ini file where all the new settings must take place.
Once the edits are done, cageFS needs to rebuild the alt-php-ini by executing the following command:



after this is executed, there won't be any output on the command line but the alt-php-ini will have updated and the new settings applied. :-D
This is confirmed in the below screenshot:
View attachment 4474

However, I ran a few tests to see if the TTFB had come down but there has unfortunately been no improvement. See below screenshot:

View attachment 4475

Any other suggestions?
Click to expand...
How does it look now? Opcache isnt an instant thing.
 
Been kind of watching the conversation and just thought I would throw this out there. As I see that it was mentioned it was Prestashop having performance issues, I did a little looking. Found the following page as a good place to start to help optimize. I see complaints from others about the same issue. Brent has been awesome helping.

www.prestashop.com

Speed up your PrestaShop - Tips and recommendations

A fast loading website is the goal of every shop owner, as a slow website can lead to a long list of issues, from disappointed customers who lose patience and abandon their cart, to an overloaded server that stops working, and search engines penalizing your site's ranking due to speed. After help...
www.prestashop.com www.prestashop.com

Some suggestions... Smarty Template set to compile/cache. HTTP/2 push module. Lazy Load images.
 
(Kind of just scrolled through this thread)

If you are using CloudLinux, what limits do you have imposed on the account in question? CPU, Memory, IOPS, etc.

If these limits are set too low - at least in my experience - this will severely undermine performance.
 
We
sparek said:
(Kind of just scrolled through this thread)

If you are using CloudLinux, what limits do you have imposed on the account in question? CPU, Memory, IOPS, etc.

If these limits are set too low - at least in my experience - this will severely undermine performance.
Click to expand...
Lifted all limits to test if it was CloudLinux. Made no difference.
cjd said:
Been kind of watching the conversation and just thought I would throw this out there. As I see that it was mentioned it was Prestashop having performance issues, I did a little looking. Found the following page as a good place to start to help optimize. I see complaints from others about the same issue. Brent has been awesome helping.

www.prestashop.com

Speed up your PrestaShop - Tips and recommendations

A fast loading website is the goal of every shop owner, as a slow website can lead to a long list of issues, from disappointed customers who lose patience and abandon their cart, to an overloaded server that stops working, and search engines penalizing your site's ranking due to speed. After help...
www.prestashop.com www.prestashop.com

Some suggestions... Smarty Template set to compile/cache. HTTP/2 push module. Lazy Load images.
Click to expand...
We have also been down this road. As far as I know, the client has enabled all the caching options in prestashop and also worked through that forum thread but maybe I should go through it myself to double check. Thanks for the advice
 
You must log in or register to reply here.
Back
Top