Hi everyone,

I'm running a community site (http://www.zortal.gr) using XOOPS and i'm experiencing high cpu load and slow server response. We have about 10.000 daily visitors and about 100 online users at any time. Data transfer is somwhere between 4-5Gb/s daily...

We have our own server (Pentium 3.0 GHz - 1,5Gb RAM - SATA 120 HDD) that is only runnig our main site and one database. The server is located at a high speed server room at one of the biggest ISP's in my country, so bandwidth is not an issue... MRTG reports show CPU loads that go above 800% of our server's CPU

We mainly use the following modules - News, Newbb, MyLinks, XcGal, FlashChat, Shoutbox, Randomquote and some other smaller...

We just moved to this server and we expected to have better response but i now think that this high cpu load is actually a problem of XOOPS that needs to be fixed. Do you have any reccomendations so we can overcome the high cpu load at least for the moment? Can someone help?

Can you give further information as to which parts of the site leads to these high CPU loads?

We can go through every bit of caching and optimisation of the XOOPS core, but if one part of the site is responsible for this, it may be better to analyse it first.

I see FlashChat in that list, chat scripts are known to be resource hogs... maybe if you disabled that temporarily you can find out if that is the main cause or not. That would probably help in deciding if it is XOOPS's core, or a 3rd party module.

Herko

Quote:

As you can understand, it's difficult to identify which "part of a site" is responsible for high cpu load. I tried turning off some parts but there was no much difference. Can you help me on how to identify the source?

Quote:

I tried disabling flashchat but unfortunately there was no change at all... Actualy it got worse because all those people that were chatting, suddenly returned to browsing... :(

I tried disabling xcgallery and there was a huge difference - not perfect but cpu now is a little below 100%. So i believe this is what causing most of the problem - the rest are depended on XOOPS core i think... Is further development of xcgallery abandoned. Can someone help on fixing thos cpu load problems with xcgallery?[/quote]

Which server OS and webserver do you use?

Quote:

Apache on Fedora Core

I don't know which tools hosting companies use, but apparently there are some way of finding out which pages in particular result in high CPU load.

Perhaps Ackbarr can give an idea on this.

Interesting. I'm not yet convinced that Fedora is the best public server OS, very frequent updates and a bloated kernel. I've found that a custom kernel compile (from older stable source stripped of unneeded bits) is faster. Of course all the other kernel tuning bits apply including no startup GUI or unneeded running apps.

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.

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.

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

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?).

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

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.

Careful caching of course is a factor.

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.

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.