Topic: PHP Sluggish on ß6?

[ylluminate]

I am not sure how to approach this issue.  Presently PHP appears to execute slowly on the server we're running on.  The processor utilization is very low (< 1-2%) and therefore I am thinking that there must be some sort of php.ini optimization that needs to occur.  Or perhaps I need to figure out how to run fastcgi on the system as the current method may simply be extremely suboptimal?

Dunno and not sure what to think until I get some input as to perhaps where to start and what may have bearing on this as per SME Server / CentOS defaults.

Thanks much guys.


-George

[purvis]

Maybe there is a way for you to test with these two centos 5.6 creations
CentOS-5.6-i386-WebServerEdition-0.1.iso
CentOS-5.6-x86_64-HypervisorEdition-0.1.iso

at
https://docs.google.com/leaf?id=0Bxt9RsVFMMlyNThkN2UyYzktYWEwNC00YzVmLTllZDgtMTJkOTE2ODEzYTli&hl=en_US

i just located those two iso last night
i also see google hits on version 0.2.iso and 0.3.iso
i have not yet tried these two installs but will in the near future
i am not endorsing these installs, it is just a fyi to you
i figured you might like to compare results from sme server to both these installs
i am using the program "hdparm -Tt /dev/sda" and a program called seeker(google linux seeker) to test my drives speed.
i also saw where you can set the memory amount that php uses, see the below link
http://wiki.contribs.org/Useful_Commands

please report back with whatever results you have or what you feel is going on.

 

[ylluminate]

I'll look at those, thanks.

In the meantime, I did start poking around a bit more to attempt to see where it was spinning.  Since PHP was using such low processor time and seemingly MySQL wasn't being pounded, I thought perhaps it would be useful if we had a Mac OS X fseventer type of tool.  I found a handy little doodad that works with inotify in inotify-tools called `inotifywait`. 

This is exceptionally useful as you can use it to monitor any and all file activity on the entire filesystem.  It certainly should become common knowledge for any admin that needs to troubleshoot things.

I did a:

Code: [Select]

`wget http://download.fedora.redhat.com/pub/epel/5/i386/inotify-tools-3.14-1.el5.i386.rpm`
`yum localinstall inotify-tools-3.14-1.el5.i386.rpm`

And then modified: /proc/sys/fs/inotify/max_user_watches to something more reasonable, like 100000

You'll want to learn more about how to use it with: `man inotifywait`

For example, I found this command quite useful and telling in my case (simply trimmed out any chatty services that weren't like to match my issue at hand):

Code: [Select]

inotifywait -rm / --exclude "/proc|/dev|dnscache|squid|samba|iptables|cron\.d|tinydns|/spool/|ntp|clamav|freshclam|MYI|MYD|sess_|access_log"

This yielded about 14,000 lines of cache activity for Concrete5 with exceedingly many entries like:

Code: [Select]

/home/e-smith/files/ibays/share_name/html/files/cache/ ACCESS zend_cache---593ee045d00a356e1adfff791e74b6551d87846f68906481b9a2a4ae035b9599
/home/e-smith/files/ibays/share_name/html/files/cache/ CLOSE_NOWRITE,CLOSE zend_cache---593ee045d00a356e1adfff791e74b6551d87846f68906481b9a2a4ae035b9599

So I believe it has something to do with some cache dysfunction for this particular scenario as it makes no sense to have this much activity for a small app.

[cactus]

Not telling us anything about you application makes it fairly impossible for you to help you troubleshoot, it could be all kinds off reasons that your application is not performing as expected, such as bad coding, bad database optimization and normalization or other factors outside PHP, virtualisation, zend cache.
Indeed you should investigate but you should also not jump too conclusions. The fact that a certain PHP application is not performing as you desire does not immediately mean that PHP is the problem.
You can also use something like xdebug to debug you PHP appliacation and profile your application and see where it spends it's time. That will most likely give you the quickest way to showing you where your application is spending it's time.

[ylluminate]

Sorry, yes, I'm seeing the problem with the Zend Cache.  I reached the conclusion that this is likely not an SME Server issue, but rather the CMS itself that is having the problem.

I was considering the use of debug to also profile it, however there are over 14,000 lines of zend cache entries from my prodding with `inotifywait`.

I thought my last note was more clear than apparently it was.  After disabling the cache the app speeds back up to normal and respectable performance levels.  I don't think xdebug will be any more telling than that, but sure, it's a good idea to corroborate the finding.  I've already shared this information with the CMS forums as I believe it is a bug introduced in the update from a few days ago.