6
Hi
Nice Topic. I am the webmaster of homerecording.de. At the moment, we have about 2 Mio. Page hits per month. There are always about 70-100 people online. We have real performance problems with xoops...but....
The reason is not XOOPS itself. Although my opinion is that the XOOPS core uses too much abstraction rather than trying to safe every unnecessary php command (like the XoopsCriteria and the XoopsObject, for example), it scales very well. There is a constant time of 2-3 seconds needed to run mainfile.php (which is in fact the core). And if php had something like a global object cache, you could even do more performance enhancements. Smarty as the template system is another problem, for example, there is a very bad concept of plugin functions. You can load plugins at runtime, but this is a huge overhead. There should be much more compile-time functiond. But it the end, the core is okay, it uses caching whenever possible, and most queries are finished in microseconds. moreover, it provides a good infrastructure like the MySQL query window, the block caching and the sanitizing of possible register_global injection variables.
The real problems come from the XOOPS modules. CBB, for example, is our "Sorgenkind": We have 650.000 posts in our database. There are many joins which are poorly optimized, we had to manually add missing indices (for example, there was no search index on post_time). The problem is that no one really took the time to optimize those queries. Optimizing a query is a science itself. You would have to look which indices are used and then try to rebuild a query to use better or just other indices. The typical XOOPS sites are rather small communities. They demand many features, performance is not the critical point. Try to ask: Is module X scaling with 100.000 hits per day? - you wont get many answers. I don't complain here, no one gets paid for anything.
Another this is that CBB doesn't implement fulltext search, we had to implement it ourself. Otherwise, you would have to wait for a long time (25 to 30 seconds per request) because CBB uses LIKE '%...%' which is a bad idea for 650.000 posts!!!
There are other modules like the "dictionary" glossary module where there is a word replacement function which is so poor that it will definitely kill your server. AMS - another example - doesn't work without register_globals, we had to fix that.
At the moment, we have a 3.4 Ghz root server with 2 GB RAM. When our contract has ended in October, we will migrate to a bigger server, a dual core with 4 GB as the MySQL backend and a small one as the php frontend. Hope this will solve our problems.
In my opinion, php itself is not the best language for huge websites. There is no type safety, no compiler, no global object cache. Java or .NET are IMHO better candidates. MySQL is a good database server, like Oracle, Sql Server and even Microsoft Acess, but like every other db server, it is not fast "out-of-the-box", every query has to be tested and optimized in order to be fast.
If you expect 500.000 hits per Day, you should really start coding your own customized website system. ASP.NET and C# is a very good combination, other people swear on Java and jsp. Both systems already have their own well-integrated template system, type safety, caching, an application server layer and so on.
greetings
Michael
