This question may not be in the right place, but...

I am responsible for an intranet server running a XOOPS installation for a department within a fortune 500 company. The XOOPS software seems to work well, but is slow. This hasn't been too much of a problem up till now because of the type of usage that have targeted for our site (downloads, forums, etc.). We would like, however, to ramp up usage with work flow tracking (zenTrack) and other in-house developed modules. The idea is that we have ~100 departmental employees (say 20% on at any one time) that would use the site throughout the day with, say, and additional 5 top 10 users at any time from outside the department browsing the site.

Our existing setup is comprised of an old ~1 Ghz Pentium 3 server (I know, but at least it has 2 cpus inside of it) running against a raid with several IDE drives hooked into it. Nothing terribly fancy and seriously outdated.

The site, today, can take many seconds to generate particular pages, presumably due to the number of SQL queries that are being run for proper page generation.

So here's my question, what type of hardware would you suggest for replacing this old beast? Cost isn't so much an issue (lets say a top end of $20 thousand), but performance when this project is complete is important. I'd hate to spend money like that and still have each user wait 5 and 10 seconds to get page draws -- even if the site can handle many users at the same time.

So what do you all think? High end server with high-end SCSI raid? Separate out the servers into a multi-tier situation? What types of setups do you run on your intranets and do they meet your needs? Any and all comments are very welcome and thanks in advance!

--robert lankford

One of the newer dual Xeons with the Ultra 320 SCSI should do fine.

Is your intra-network 10mhz or 100mhz?

The problem may not be that you need a new server, but a better configured server.

What level RAID are you using?
Is RAID software based or hardware based?
Have you fine-tuned your Apache, PHP, and MySQL configurations?
Is this server running other applications?
Have you disabled all non-essential services (including GUI)?
Have you enabled caching in XOOPS?

If you're only running 1 site on the server, and you max load is only 100 users, you really shouldn't need all that much. On lower traffic sites, XOOPS does not consume many resources.

The exception here is if your visitors are performing complex queries frequently (Searching a large database of data). If that is the case, install PHPMyAdmin and use the "Show MySQL runtime information" tool to find out where you may need to optimize your MySQL configuration to handle the load.

Hope this is helpful.

James

EDIT:
Tabasco,

Even on a 10Mbps link to the server, 20 users average would still be quite fast. If you think about it, that's roughly 500Kbps transfer peak (roughly 50Kbps usable) per person. I once ran a phpBB forum from my home computer over dial-up (53Kbps peak) and was able to support 20 users.

Best Regards,

James

Thank you both for your responses.

First off, our lan is 100 megabits per second and bandwidth isn't my problem. I guess using "page draws" in my original post was a little confusing. My biggest problem is how "snappy" the pages are when generated. In other words, how long my server spends gathering information for drawing the page before the page can be delivered to the user.

I believe that the raid is hardware based (I haven't maintained the hardware on it, so I'm going from memory here). I think think the OS is NT 4 (I know, we need to upgrade). Other processes are relegated to print queues -- nothing much else.

As far as software configuration, I simply performed a standard Xampp installation. This package installed PHP, Apache, and MySql for me. I have done no optimization to it (and am not really trained in such skills). XOOPS is caching the html templates, but I'm not sure about any module-specific caching that should/could be used.

I ran the PHP-MyAdmin function that you mentioned in your note. The results are available in PDF form, if you care to take a look. It appears as though 85% of my queries are select related, while the rest primarily update the database.

Again, I believe my problems lie with module code in that it can simply require a large number of queries (select) to gather information for page generation. As a side note, the draw times are significantly faster for me than others in my area since I am designated as a "web master". I poked around and have noticed that a lot of security code is simply bypassed if the page is being generated for a web-master. This works technically, but in terms of performance, I never really see the hit that other 'normal' users see. So I'm been caught off guard a few times when people complain about the performance of the site and I think that everything is just fine.

I guess what it all boils down to is a recommendation on either software and/or hardware optimization that can influence this type of behavior positively. I'm willing to spend some money in order to get it faster and I'd kind of like to hear from people who maybe have been through this scenario before themselves.

Thanks again for you input...

Wow, I'm kind of surprised that this discussion hasn't generated more interest. Am I the only one out there with this challenge??

Anyway, I've turned on the MySQL debug mode and documented the query counts and page generation times for several pages on my site:

home page: 103 queries - 4.0959119796753 seconds to load.
pd-downloads root: 143 queries - 6.2500469684601 seconds to load.
pd-downloads category: 49 queries - 3.7887420654297 seconds to load.
wiki root: 66 queries - 4.8866550922394 seconds to load.
admin root: 4 queries - 1.0515160560608 seconds to load.
search: 43 queries - 7.092022895813 seconds to load.

It's early in the morning here and I'm the only person on the server. In other words, the numbers above are best case.

So what's the best plan of attack here? Can server software (apache, mysql, etc.) optimization really make a significant difference in these load times? Would running this setup from a newer and faster box make enough of an impact on the turn around times? Or, is 103 queries to the same MySQL database always going to result in several seconds of waiting?

Thanks in advance guys! Sorry to be such on noob on this stuff!

We know that Pd-Downloads is not that fast that it could be but it would be much better in the next Version. Th Querie Optimization is a direct developing thing for us.

rlankford,
There is something wrong with your server.
I get similar times as yours (if not better) on an old Pentium
120Mhz with 128M RAM, running FreeBSD. Sure, I do not support 100 users, but your times were the best case scenario, right?
I think there are a bit too many queries for your top page, I think you do not cache much, do you?

personally i'd go for a dual opteron.

they handle memory management, I/O and resources far more better than the xeons do.

but it would also be better with at least a 2 tier minimum.. seperate system for the SQL database.

definitely scsi drives.

and a full duplex network. (can you bridge network cards?? - 1 card for TX, 1 card for RX)

module optimization is also a needed priority.

cache where possible.

you might want to also try GIJoes fastest XOOPS cache hack aswell, it takes some setting up, but performance wise it's worth it.http://www.peak.ne.jp/xoops/md/mydownloads/viewcat.php?cid=2

wf-downloads is also a lot more optimized than pd-downloads, and with the new hack we have for it courtesy of Jegelstaff, you can even have dynamic submit forms that can be different form for every category. the hack works in conjunction with formulaire module..

I think Monty's suggestion is pretty close to being spot on, however with the loads you are talking of there shouldn't be a need to throw buckets of money at it. The general rule of thumb I go by is that Apache (or any webserver) is bandwidth bound, PHP (or any interpreted programming language)is CPU bound and MySQL is Memory bound.

In the article I wrote about performance tuning XOOPS on IIS I took an old Althon 1.4Ghz based system with 512MB PC133 SDRAM and a single ATA-66 10GB 5400RPM HDD and took it from serving around 1100 hits per minute using the default server/PHP config to serving over 4000 hits per minute using optimised Xoops, PHP and IIS settings (I didn't even get to MySQL memory optmisations which would further increase performance). To put that in perspective with my site having around 23 HTTP requests per pageview, 4000 hits a minute is equal to around 250,000 page views (5.75 million hits) a day. With 20 people on your server only in business hours you probably wouldn't see 250,000 page views in a month.

So in your situation you are not bandwidth limited, assuming you have 1GB or so of Memory in your server you shouldn't be memory limited either, the only thing that might let you down hardware wise is CPU. Personally what I would do is setup you current server as a dedicated MySQL server (make sure it has at least 1GB RAM), and then get a dual opteron system as Monty suggested with the fastest you can afford (again with around 1GB of RAM). With the load your expecting I would not even bother with SCSI drives, it's a waste of money as once apache, PHP and MySQL are loaded into memory the disk I/O will barely be touched. For the webserver just get a couple of WD 10,000RPM SATA drives, put them in software RAID 1 (very reliable, I've done it myself for several years) or use a hardware RAID hotswap system if 100% uptime is important. Even then though you'll still need to look at apache, PHP, MySQL and XOOPS optmisations to get really snappy responses from your server as there is only so much hardware can do. Look at loading PHP as a module using FastCGI for apache, use something like APC/eAccelerator for PHP acceleration, query caching for MySQL and block caching for Xoops. Also be sure that your theme for XOOPS is not bloated with images and HTTP requests, and use CSS for layout as much as you can.

Thanks everyone for your postings. I've found them very helpful (special shout out to Brash for his excellent post).

Believe it or not, I'd never even noticed the block caching feature of XOOPS before. That's bad, I know. Anyway, the biggest difference to my site was made by caching the 'Main Menu' block. Each module gets parsed to see if it needs to have sub-items, and that process was really slowing me down.

So, I now have acceptable (3 seconds, instead of 6 or 7) turn-arounds on the existing hardware. We still plan to purchase a new server, however, because of expected increased demands in usage that are coming. But, because of everyone's great feedback, I am now pulling way back on what my reccomendation for that hardware will be.

Thanks again everyone.