Hi bradburn,
I think Chainsaw has pretty much nailed it on this one. XOOPS will never be as fast as a compiled language as it is based on PHP which is an interpreted language (processed on the fly). This by no means results in in being slow though. I have done some extensive performance testing on Xoops, and I have found that there are 6 major elements to making your XOOPS site fly;
1) Hardware must be adequate for the job. The main components getting hit in your system when web serving are CPU, RAM and HDD, and if anyone of these are vastly slower than the other then you will have a bottleneck. For instance, there is no use going out and getting a brand spanking new P4 3.4Ghz CPU with 1GB of RAM if you are only going to put the old 1GB HDD from your Pentium 100 in there. HDD performance is critical in high load situations, and I have tried helping users in the past where their hosts are using quad Xeon 2.4Ghz servers, but only using a single standard large capacity 7200RPM ATA-100 IDE HDD to serve everything from. This is not a good match.
2) Web server configuration. It makes no difference whether you use Windows & IIS, Windows & Apache, or *nix & Apache, and the suggestion above that you should be running Linux in a high load situation is quite simply incorrect. Our Windows/IIS intranet servers at work handle several thousand concurrent users everyday. The real key here is how you configure it to perform for your particular environment. With IIS for example (as IIS is my area of expertise) you get much better performance under high loads if you configure you PHP application mapping in ISAPI mode rather than straigh CGI due to the fact when using CGI the web app is loaded into and out of memory for every single request, where as with ISAPI the web app is only loaded into memory once where it can be used again and again for all requests. Then on top of that again you can greatly increase PHP performance by using an caching/accelerator such as Zend, mmcache or eaccelerator. You can also get further performance gains through performance tuning your MySQL environment, but I haven't explored that to any great depth at this stage. Yet another thing you can do on top of this is HTTP compression, which both IIS and Apache can do. What this does is compress appropriate files (text based such as CSS and HTML) on the fly which are then decompressed once delivered to the end user. This can not only greatly increase performance, but can also substaintially reduce your data bill for high traffic sites.
3) Choice of XOOPS modules. Finally we actually get to XOOPS
. As indicated in these two articles I wrote;
Performance Analysis Of 4 XOOPS Article ModulesPerformance Comparison Of NewBB 1 Vs NewBB 2 Performance can depend a great deal on which XOOPS module you choose to use. By rule of thumb all the XOOPS core module are very good performance and scalability wise. Outside of that though you are on your own as not all modules perform equally for a variety of different reasons. I suggest you read the two above article linked above.
4) XOOPS cache. This is one of the most underutilized features in Xoops, particularly when it comes to block caching. I would have to say that 99% of the people I have helped saying that XOOPS is slow did not have any caching enabled, or at the very least did not have block caching enabled. PHP is an interpreted language, if the HTML output it and Smarty produce are not cached, then it must be processed by the CPU. If it is cached then the HTML output is already there and can be delivered to the user as is. XOOPS blocks are the biggest offenders here as they are typically trying to collate a lot of data into a small space which can often bump up the MySQL queries and PHP execution times. Caching these blocks can quite easily double your XOOPS sites performance, I cannot stress how important it is to spend a decent chunk of time setting up your block caching if performance is a concern for you.
5) Site Content. This is back to basics really, but you only have a finite pipe between your server and your user. All content on your site must fit down this pipe, so unless your on a LAN you need to be concious of this and try to only include minimal relevant content, particulary on your front page as it will get the most traffic.
6) Your XOOPS theme. Lots of graphics certainly does do a lot for visual appeal, but it can have a massive impact on your site performance. This comes from three fronts. Firstly all graphics must be downloaded by the users browser, and if there are a lot of them and if not optimised can really strangle performance. The second front is that each and every image produces a HTTP request, and while graphics are cached by your users browser when downloaded for the first time, HTTP requests are executed evvery single time the page is loaded. The third front is latency, and is directly tied to HTTP requests in regards to how it effects your site performance. If you have a user on a 56k connection trying to connect to your site from the other side of the world then it is very likely they are looking at a latency of 500ms or above. Not much on it's own, but if you have 100 HTTP requests or more in your website it is very easy to see how this latency issue will quickly make your site unusable for this user.
You need to remember your site is only as fast as the slowest link, so if the majority of your users are still using standard 56k analog dial-up connections (which is still the most popular connection medium worldwide) it is irrelvant that your site might be hosted on a dedicated 1.5mbps T1. It is all about knowing your audience.
Anyway, sorry for this bable of crap, but hopefully you can pick through it and find some useful pointers. Moral of the story is that XOOPS is a perfectly capable race car, how it performs relies very heavily on the drivers ability
.
