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.

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.

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.