Quote:
Please install


Or any other searching solution.

@Mithrandir below: I forgot to punch the quote button. The first time sorry it was out of context.

WarDick, what has that to do with the server load discussion?

Quote:

Ever since reading this post I have been having nightmares about reaching and exceeding the connection limits of XOOPS.

Every person who has ever questioned the limits has been more or less attacked or at least treated harshly when they have expressed concerns over the connection ceiling.

Let's look at possibilities with an open mind. Have they been reached at less than 200 connections or not?

I propose a stress test.

What better place than right here on this forum.

It is running on an XOOPS optimized server??

It is setup and maintained by the experts.

We have enough registered members to conduct such a test.

To proof test the connections limits would require everyone to sign on at one time and use the site as you normally would, reading the news, searching the forums, what ever you do when you log in.

All thats left is to have a community support member set up a time and date to conduct this test. Plus the willingness of the community to participate in the test.

Lets find out where we stand. Is XOOPS a toy or a tool?

I don't think you'll get all the users to login and stress the site all at once. 24+ time zones and all that.

You can use a server test application and dialin exactly what you want and then measure the results.

It is also about server tuning and XOOPS configuration and admin choices for content. I've seen XOOPS sites that I'm sure would fall down with any reasonable load and others that can take it big time.

It isn't all about the core.

Quote:

I do admit some people get a bit "touchy" when XOOPS is spoken of in a less than favourable light. However, the majority of the time this is in response to posts that are not totally reasonable and/or fair. I don't see anyone in this thread being attacked, what I do see is almost everyone who has responded to this thread to date offering to help. As has been mentioned XOOPS will have a limit, but many variables go into determining this, such as hardware, OS, XOOPS and webserver performance tuning, so there is no such thing as a one size fits all answer.

On a high volume website, the three major hardware components that are going to get hammered are CPU, RAM and Harddisk. A celeron is hardly a server class CPU, and a standard IDE hardisk isn't either, but they should be sufficient to serve a high volume website without raising too much of a sweat IF THE SOFTWARE IS TUNED.

Coming from a Microsoft background by tuned I mean;

(1) OS - Using a server class operating system all unecessary services disabled, and that only the services/applications you NEED are installed. This will free significant resources in an Windows environment.

(2) Webserver - Is tuned to maximize resource usage. Running PHP in fast_cgi mode on IIS brings significant performance gains under load, As does tuning IIS itself with http compression and things of that sort.

(3) XOOPS - the site ylw633 is running is 150K worth in nearly 40 http requests, which quite expensive for a high traffic site. Using a fast performing theme such as some o the ones produced by 7dana, StudioC, Incarma and tjnemez will greatly increase site performance. As will caching (module & block) which can make an enourmous difference to site performance which ylw633 said he had not enabled at all. This means for every single site load the database will be getting absolutely hammered. I cut the number of SQL queries being reun be site load by over 60% by using the cache system (unless cache has expired that is).


Although my background sits with Microsoft, the same performance tuning concepts are going to apply no matter what environment you use. You just can't expect an out of the box implementation of any system to be able to adequately serve a large volume of users, it just doesn't make sense. If Ferrari sent Michael out in a F1 car to try and win a GP straight after they had assemble it without letting the technicians get in there and tune it, you would think they were crazy. Same goes for trying to serve a high performance website, or anything demanding high performance. As for stress testing, why not purchase & use one of the many web stress tools out there?

Anyway, to cut an extreme rant short , what I'm trying to say is that wether XOOPS is a toy or a tool depends greatly on the person(s) driving it.

No matter what script you use, running a dynamic site with any kind of volume will usually piss off admins of shared hosting companies. The most important thing to do for high volume sites is to use some kind of php accellerator, no matter if its commercial or free. I have no idea why shared hosting companies don't at least use a free solution to reduce server load. Search me.

If you are running any kind of high volume, you're best advised to get your own server. One reason the shared admins are PO'd is because most of them run the DB server on a different machine than the Apache, so there's a lot of network traffic between the two. If you have a dedicated server, you usually run both on the same machine, so the DB connection is faster than in a shared environment and doesn't eat bandwidth.

Here (germany) one of the best hosts for dedicated (root-access) servers is hetzner.de, where you pay 39 EUR (around 48$) for an Athon XP 3000, 1GB RAM, 160GB HDD, and 160GB of traffic. I guess you could find hosts for similar prices elsewhere, and if you don't, hetzner can take international domains too

like i said, the most important thing is running a byte-cache. I use zend accellerator on 30 servers to run a website with over 60 million visitors per day, and benchmarks have shown that I'd need about three times as many without the accellerator.

some new update:

we now have our own dedicate server that is 2.4GHz Celeron, 512mb RAM, and 80G IDE on FreeBSD, no WHM no cpanel, so no garbage applications that comes with it. Basically it's just a FreeBSD 5.1 box that is primarily used as a web server.

I have done excessive research and have personally optimized the kernel, system parameters, MySql (4.1.3), PHP (4.3.7), Apache (1.31). All applications are compiled using optimization and Zend 2.5.1 is installed to accelerate PHP. I have tweaked every performance related parameters of Apache and increased buffer of MySql. I have configured XOOPS to cache most of the blocks thus cut database queries on our main page from 90 to 60. I have even conducted an experiment of redirecting all static file request to thttpd running on another port and let Apache only handle .php requests, though this configuration failed to boost performance as expected.

Alright, our site can handle about 150 concurrent users during peak time but still will freeze sometimes and we are stuck now.

Here are some obervations we had on XOOPS and performance tweaking.

1. turn off Keep-Alive on the server will help quite a bit
2. I think there are bugs in database access of XOOPS, during off load time it may be OK but it seems like some dead-lock or race condition will occur if some condition is met. I am not an expert of PHP so I didn't bother to look into the code, the below finding is purely based on observation of the behavior of our server.

When our server is frozen (load is more than 10), most of the Apache process is serving either main page (index.php) or news module (article.php). It seems like tow or more processes started the lock down and the lock caused new httpd and MySQL to spawn for requests coming in, eventually every httpd process is at "W" stage and eats up memory thus crippled the server. Below is a capture of Apache status.

9.65 requests/sec - 25.4 kB/second - 2699 B/request
143 requests currently being processed, 7 idle servers
W_WW_WW_WWWWWWWWWWWWWWWWWWWWWWWW_WWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWW___..................
........................

During this stage the established TCP connection is about 100 and also about 100 MySQL is spawned as well. Basically we have eliminated the possibility of being attacked and think this problem is probably caused by XOOPS.


Since most of the resource XOOPS required is used on the generation of contents for different group of users (like module permissions), is there a functionality or module in XOOPS that can pre-generate static file (html) for all viewers (much like weblog applications)? Even doing so would pretty much abandon the flexablity of managed interface XOOPS has, however it will be a great feature to have in performance perspective.

You are certainly on the right track. However I would say that a slower PIII/IV will outrun that Celeron and be more stable. Static content in Apache runs great on a Celery but once you start using a lot of math (image manipulation, db, PHP, etc.) the Celeron is quickly overworked no matter what the MHz rating.

With disks so cheap you'd also get benefits by splitting IO over two or more drives.

But it should never freeze up even at 100% load.

Quote:

Hi what're sessions and how do I disable it? thanks