In light of recent events, the traffic on our website kaizoku-fansubs.com has increased almost 100-fold. I do not know if the problem lies with Xoops, but this is a good place to start. Here's what is happening:

Site enabled, traffic starts flowing at about 40-50 hits per second, and everything seems okay. Mysqld pops up from time to time when running top showing a large query go by. Everything continues to be cool.

Something happens.

1 maybe 2 httpd processes jump to consuming every last cpu resource, leaving it impossible for apache to create new threads to handle web requests. PHP is running as mod_php and the host's solution has been to shut us off and leave us off until we can figure out the problem. Here's what we have done so far:

1- disabled our high traffic pages by placing a temporary redirect to a static html page (to prevent httpd binding if it was one of those pages)

2- ran myisamchk on all our tables in order to repair any possible corrupting

3- disabled statistics module (hey, at that many hits, anything is possible)

4- disabled custom XOOPS pages including bittorrent tracker, scrape page, and file parsing scripts. (see step 1)

We are currently in a state where we are running XOOPS with the following:
XoopsCore, newbb, FAQ, WF-Section, XoopsLinks, XoopsDownloads
mods: edituser.php (prevents sigs > 500 characters and image restrictions on size and dimensions)

Our host will turn us on once again this morning, but if things fail again, I am curious where people (core / module / php people) would begin in attempting to disect things. I am (hopefully) going to turn off modules 1 by 1 until we get to the XOOPS core. However, if anyone else has had similar problems, that'd help too.

Cheers!
~Jakob

I don't know.
I am not an expert on server configurations and high-load sites, but we are very interested in hearing feedback from a server perspective.

I would say that in general XOOPS is not power hungy, but it may depend on staying below a "magical border" which we have not found yet.

Also, do you know with absolute certainty that it is YOUR site, which is the power hungry one?

Looking forward to following your progress and findings.

Jakobo, your test is interesting
Hope you can figure out what causes server load.

Few days ago, my xoops-test site was suspended for CPU cost though neither me nor server technical staff could find out what caused it.

For my testing site at that time, only one active user and few fresh-installed RC or beta modules, including news, newbb, wfsection, wordpress blog, wakkawiki.

Look forward to more info.

I presume all the relevent blocks and modules have their cache set to the longest possible lead time?

Caching has been fully enabled. Here's a snapshot of top



the 25% usage just hoses the whole system. Still can't find anything in the access logs for it. This is reaching a critical point to where our host is willing to shut us off and terminate our account.

I am grasping at straws and this may not even be a correct theory... but, if no one else gets back to you, and you want to try something before you get the boot...

As a test. What happens to your server load if you turn off ALL (and for a good test it must be ALL) cacheing.

I am pretty sure Smarty lays dormant if cache-ing is turned off for everything. Pretty sure, not 100% sure.

If so, this would at least let you know if Smarty is impacting the server load for some reason.

Just a test... a random theory. Hope that helps, and leads to something.

Granted, this will mean more MySQL queries... but, perhaps that is preferable to the alternative. Again it is just a test. XOOPS is pretty efficient with its queries, anyways.

Also, have you alternated your persistent connection settings and your gzip compression settings? What are they set at now, just as a reference to others.

Finally, be sure to turn off any blocks that are always updating... like Site Info blocks that show the current number of users, who's online blocks, etc. I've seen some of those blocks bring sites to a crawl. Again, just as a test.

Turned all caching off: no improvement. Persistent Connections are on, gzip compression is currently disabled.

The current server software is Apache 1.3.28 which while I'be pointed out to them is old, they claim is stable.

We have at this point rolled back to the XOOPS default install (with our user DB) and have disabled most of the modules (except for news). We'll see from here what happens.

what makes them so sure it's your site causing the high usage?


in the spirit of experimentation, i can toss up a test account on my server for you to play with (temporary basis). it would give you a chance to experiment with the site in a low traffic scenario, or you could even redirect the high traffic to the temp site to see how it gets handled.


when your site is disabled, do they still have any high process usage at all?

have you run a google search on their version of apache or php to see if there are known loops or hangs with those versions?

have you tried turning off Persistent Connections?

It is tied to the newbb module. We haven't pinned down what exactly, but enabling this module will (after about an hour) generate the server spikes that are crippling at best.

Hopefully I'll be able to track it a bit more this evening. I will probably also try the newest newbb off of dev.xoops.org to see if that solves anything.

for bd_csmc: Yeah, when we are disabled, those spikes go away. I have tried disabling persistant connections before, but it didn't seem to help.

have you tried the advanced caching patch in the XOOPS sourceforge repository and enabled caching on the newbb module? that might help to fix whatever the problem is


btw, what version newbb were you using? default?


have you tried XOOPS 2.0.7 to see if that fixes the problem?
(doubt it, but worth a try)


fyi, the newer newbb at it's current stage is fairly unusable in alot of areas, so be warned, back up your files before installing (and database)