We are evaluating XOOPS to power a large-scale site. XOOPS is currently our top choice, based on features and the strength of the developer community. We have not been able to find much information about XOOPS' scalability (other than the interesting paper -- and comments -- about the 4 major article management systems).

By "large scale" I mean a site that has more than 1 million users and more than 5 million page views a month. We estimate peak concurrent users at about 100,000.

We expect that in order to support this kind of traffic, we will need to extend/alter XOOPS. If so, we of course plan to contribute those changes back to the XOOPS community. We also plan to enforce very strict internal rules about page coding, SQL calls, and the like, in order to avoid creating our own problems through careless development. Finally, we will do a careful review of the code in all 3rd-party modules we plan to deploy.

All the said, we are hoping the community might help answer some of our urgent questions:

1. Which XOOPS-powered sites are the largest, in terms of users and other load-related measurements? We would love to chat directly with those teams.

2. Which elements of XOOPS are most sensitive to load-related problems? Said a different way, are there parts of the XOOPS architecture that are likely to not scale well?

3. Which members of the XOOPS community have demonstrable skills in this "scalability" area? We hope to be able to hire 1 or more people, with real money, to help make sure we can handle this load.

Thanks in advance for your replies or questions. We're all very impressed with XOOPS!

"estimate peak concurrent users at about 100,000"
-- really a challenge for XOOPS, and of coz a real chance both for you and for XOOPS.

Not sure what the main functionalities of your site are but generally speaking, forum is usually the most busy part, if you are not hosting a downlod site.

Which is the "biggest" XOOPS site? I don't know the real answer but this one, the online community for a Chinese news agency, is above average: http://bbs.huash.com

If you look for forum and article mangement related developers, I happen to have relevant experiences and glad to exploit Xoops' scalability.

1. An example of a large site using XOOPS: Novell's developer site.

Hi tommelcher,

With that kind of traffic you are going to face scalability issues with PHP before you even get to a CMS, purely because PHP is an interpreted script rather than being compiled. Added to that you are going to need a massive amount of bandwidth to support 100,000 concurrent users, you'll be looking at something like a dedicated OC-3, maybe even an OC-12. No doubt you've taken that all into consideration though.

Anyway, throw enough processing power at web application and you can acheive almost anything. I'd assume with the kind of traffic you'll be looking to support that clustering your service, which is something I can honestly say is an environment I've never heard of XOOPS operating in. However, effective clustering is a function of your clustering solution rather than your choosen CMS.

The largest site I know of using XOOPS in any detail outside of Xoops.org is iis-resources.com, but even then we only get around 250,000 page views a month there which is no where in the league you speak of. I can remember reading about a drag car website some time ago that had 500,000 visitors in a weekend, but can't remember any details.

Funny you should mention the article regarding the analysis of 4 XOOPS article managements systems, as I wrote that paper. I'm actually in the middle of writting another paper on performance tuning your XOOPS environment which deals with performance optmisations in a single low end system environment from the operating system level right through to web server and web application level in a Microsoft environment. I've gotten some pretty impressive results so far, with performance improvements in the vacinity of 1000% over the default. Even so, this would be of limited value to you as it only covers general performance tuning methods, where as you will need to do some significant performance optmisations at the web app code level I'd say. Anyway, I'll be very interested to follow your progress here.

Quote:
I asked this question some time ago (search 'scalability' in forum, or check my profile, forum topics) and didn't get adequate answer

From other side I know rather ordinary site with 50,000 hits per day (70+ on harders time), somebody tells about 100.000 hits per day here, on xoops.org
5 millions page views a month is ~167000 hits per day (even if we think about absolutely uniform load, which is only dream), more realistic will be something like 200,000 hits per day

I think, only this load (without huge amount of concurrent users) will be enougth to kill XOOPS, or clean Apache will die under 100,000 connects: 1000 parallel downloads killed

CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2400.09-MHz 686-class CPU)
Hyperthreading: 2 logical CPUs
real memory = 2146959360 (2096640K bytes)
FreeBSD/SMP: Multiprocessor motherboard: 4 CPUs

Hi and welcome here,

First, as it has been said already, XOOPS will be highly dependent on external parameters/software (but if you plan to make such a site, I guess you already have somebody who knows that close to you).

Now, to answer your questions about XOOPS by itself:

0. Considering your objective, use the latest 2.0.x version as your codebase. There will be a clear upgrade path from this version to the next one (2.4.0) and the 2.2.x releases are quite less scalable, so you'll get more comfortable by doing this.

2. I wouldn't say any particular part has scalability problems, however several ones can/must be enhanced so you can reach you goal.

- The boot sequence (things done or launched from include/common.php) is particularly sensitive to speed enhancements as it will be performed on each page request, even if it does not actually have main problems.
- The output generation layer will have to be refactored (ie: it actually generates useless DB queries that could be prevented).
- The output caching system will have to be greatly enhanced too. It will also be a main actor on such a website and the actual one, if not inefficient, is too limited to give you a good control of your site caching policy.

3. We'll be publishing our objectives for the next major release really soon (within days/next week): changing the parts I talk of will be part of our targets, so to demonstrate what I said is precisely what I/we intend to do ;). I guess you will want to follow what's happening here before mid-september (and after... ), and we can talk again about your project soon.
But again, the success of this will depend on your server configuration, as well as on these XOOPS enhancements.

skalpa.>

Thanks very much PHPPP. I'll follow up on your offer of help separately.

Thanks very much for the detailed reply, and for writing the paper. I look forward to reading the next one. Sometimes optimizations for "low-end" environments yield great insights for higher-end ones... :)

Thanks for the tip!

Thanks for the stats.

Actually, since XOOPS.org is a large site and the community is growing, i wonder if the folks who run the site would mind sharing their peak load figures here? We're interested in peak concurrent users, and peak pages served per second. Of course, a snapshot of the hardware and bandwidth at that time would help.

Of course, being a newbie here, apologies in advance if this information is either "not shared" or too much of a hassle to write up.