11
kotis
Re: High Cpu Load
  • 2005/3/31 19:39

  • kotis

  • Just popping in

  • Posts: 82

  • Since: 2002/12/23


Quote:

DonXoop wrote:
Are you using a PHP pre-compiler/cache? That can help. Also a compiled from source Apache, MySQL, PHP, etc instead of the canned binaries can help a lot.


Zend is installed... the rest is default fedora stuff

Quote:
Have you studied your phpinfo(); page and verified optimum parameters? The defaults of the Fedora binaries might be less than ideal with your load. Important: if you're using PHP as CGI instead of module that will cripple the system with your load.


Not sure about that... I'm sending you a pm with a link to my php info page so you can help if you have the time...

Quote:
Have you looked at what if anything is hogging the CPU, via a console "top" command or other detailed command?


Top command shows nothing special. At top is httpd of course... Is it possible to give me a list of any other commands?

Quote:
With the servers on one box you likely don't want persistent connections but is something to play with. Using a socket connection instead of IP to localhost might be faster (can XOOPS use socket?).


i think peristent connections are not used... How can i check that?

Quote:
What about external content like ads? Any local db queries before the external calls? Using phpAdsNew stand alone or with an XOOPS module?


phpadsnew is used standalone but it is running from a different machine. This machine only serves the domain we are talking about with no external scripts...

Quote:
There is a little script floating around that will show the query times and counts. That might show if you have a very high query count or time or just a lot of users.


This is the one i found...

https://xoops.org/modules/news/article.php?storyid=1862

...i hope it's the one you 're talking about. I 'll give it a try...

Quote:
Careful caching of course is a factor.


I'll check caching again... I'll come back with results...

Quote:
You might hack the photo gallery for better performance. I'm not familiar with yours but things like random pics are usually pretty db intensive. No doubt your users are hitting the pics pretty heavy.


As i understand, this is not a db problem... MySQL load is low... System load is the one that goes high...

Quote:
I'm not a fan of using any chat apps that anon users can get to even if you then force a login. They will frequently hit the link and load the app before seeing the login.


I tried turning chat off but there was no improvement at all. It actually got worse because all chatters returned to site browsing... :(

Thanks for your help... If you think of anything else, please post it here. I 'll come back with any results soon...

12
kotis
Re: High Cpu Load
  • 2005/3/31 20:42

  • kotis

  • Just popping in

  • Posts: 82

  • Since: 2002/12/23


I changed some settings for blocks caching and i placed the Page timer & MySQL counter hack at the bottom of my page. At the moment page is loaded at about 0.6 - 0.8 seconds for 80 to 95 queries with 70 online users, but this is not the time of the day with the highest traffic. I'll wait for a while to see if block caching helped and i'll come back with more...

13
kotis
Re: High Cpu Load
  • 2005/3/31 21:16

  • kotis

  • Just popping in

  • Posts: 82

  • Since: 2002/12/23


I also enabled GZIP compression the hard way after reading a post by OnePay on this page:

https://xoops.org/modules/newbb/viewtopic.php?topic_id=16786&viewmode=flat&order=ASC&start=10

that says:

Quote:

In our implementations "$xoopsConfig['gzip_compression']" returns NULL (it is turned on in the admin), so it would not even try to use ob_gzhandler. However, when I remove the complete if-statement and just put "ob_start('ob_gzhandler')" there is no "Content-Encoding: gzip" in the headers. Only after placing the "ob_start('ob_gzhandler')" on the very first line (in the first else-statement) in the "common.php" file it outputs the site using gzip compression.


At last... the site is now gzip and loading is much faster... I 'll still wait for a while to have even more online users to see how the response will go...

14
DonXoop
Re: High Cpu Load

I replied to the PM. Most of it I'll include here for clarity. Some of these things you've already done and are seeing improvements.

If you don't do a lot of perl I would say disable mod_perl since it can eat a lot of memory.

I don't know all of the modules but you might consider if you need: dba, dbx, hyperwave, etc.

For security I would turn register_globals Off and only enable for specific modules that really need it On (.htaccess or in httpd.conf)

One setting I've used to get a bit more is in httpd.conf:

<Location />
 
# Insert filter
 
SetOutputFilter DEFLATE

 
# Netscape 4.x has some problems...
 
BrowserMatch ^Mozilla/4 gzip-only-text/html

 
# Netscape 4.06-4.08 have some more problems
 
BrowserMatch ^Mozilla/4.0[678no-gzip

 
# MSIE masquerades as Netscape, but it is fine
 # BrowserMatch bMSIE !no-gzip !gzip-only-text/html

 # NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
 # the above regex won't work. You can use the following
 # workaround to get the desired effect:
 
BrowserMatch bMSI[E] !no-gzip !gzip-only-text/html

 
# Don't compress images
 
SetEnvIfNoCase Request_URI 
 
.(?:gif|jpe?g|png)$ no-gzip dont-vary

 
# Make sure proxies don't deliver the wrong content
 
Header append Vary User-Agent env=!dont-vary
</Location>


this adds compression on top of what Zend will do.

When running top is httpd always at the top with long CPU times and using most of the resources?

Make sure you don't have things like DNS resolution in the web logs (isn't by default).

If you have multiple disks you could split some of the IO over the drives. The temp space is one, swap is another, web files vs db files are best over unique disk channels.

Check if you are quickly going into swap space. As much RAM as you can get is always helpful.

Maybe more tweaks.

Oh, .8 and 80 queries is a tad high. Try to get the queries down and it will speed up some more.

Login

Who's Online

150 user(s) are online (104 user(s) are browsing Support Forums)


Members: 0


Guests: 150


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits