How XOOPS handle a site with 60.000 visits/day?
I'm planning to switch my old, perl hand made and very very hard to admin scripts, to a XOOPS solution.-

Hi Bsacco,

I'm wondering the same thing. I've been doing some research on this question, but I've not found an answer to this.

One of the big factors may be whether you use a shared host or a dedicated server. On a shared host, the efficiency of your site is at least partially dependent on how efficiently the host manages their server resources (and their server configurations). If you can afford it, you are better off on a dedicated server, since you are not competing with others for resources.

Unfortunately, I cannot afford a dedicated server at this time, which is why I'm trying to find out how XOOPS performs in high traffic on shared hosting (and which shared hosting plans work the best).

Another factor is how graphics intensive your site is. The more graphics/downloads/uploads, the more load on the server being used. This may not be a major factor on a high capacity dedicated server, but may be a significant factor on a shared host.

As for how XOOPS can handle high traffic in an optimal operating environment, I would imagine that it works fine (unless there are bugs in the code that cause problems during high traffic). From what I read, PHP and MySQL can handle a lot (and this is what XOOPS is based upon).

Anyway, I'm pretty much rambling here, since I really don't know how XOOPS will perform at various traffic levels, and on various types of hosting/servers. I wish there were some documented guidelines available on this.

I'm planning a huge move for one of my old web sites, from static to CMS with Xoops. I would hate for the site to not work right or not work at all under heavy traffic. This is why I'm trying to find some information on how XOOPS performs under various conditions, before I completely commit to making this big move to Xoops.

Dave

The boys over at mamboserver.com did a study of several popular content management & portal systems. In their study XOOPS performed on par with Mambo:

http://forum.mamboserver.com/showthread.php?t=11782&page=1&pp=10&highlight=load+XOOPS

Several things that will help your site's performance:
1. Use of a PHP pre-caching engine. I've had good results with Zend Accelerator and Turck MMCache. In a shared hosting environment, ask if they use one. If they give blank looks, look for a different host.

2. Caching of relatively static content. Make use of the smarty caching in high traffic, but low modification areas. An article module is a good example of this. The articles themselves change infrequently compaired to their usage frequency.

3. In a shared environment, ask if they use a MySQL query cache. This feature of MySQL 4+ greatly improves performance on frequently used queries.

Hi ackbarr,

Thanks for the links and tips.

Is the PHP pre-caching engine something that the host sets up? Or, is this something that I would need to manually configure or turn on? I have the same question for the MySQL query cache.

I assume that I turn on the smarty caching within the blocks or admin preferences section.

Dave

I believe the pre-caching and MySQL caching is part of the server configuration and not something you would be allowed to interfere with.

Quote:
caching is enabled for modules in the system admin -> preferences -> general settings section and the blocks are cached by editing the individual blocks from system admin -> blocks -> [edit selected block]

However, one very very very important thing to remember, when using caching, is that this will save the output of the page or block - which means that it will not update at all. So for instance the main menu will not show submenu links (or show the same submenu links all the time) because it is saved in a static output. Also, it will not change depending on the user's permissions, so everyone will see the same output.

The same goes for e.g. News articles, where if the page is saved when an admin is viewing the article, the [edit | Delete] links will show for EVERYONE (they will not be able to actually edit the articles, due to permission checks, but the links will show up for them as well)

Hi Mithrandir,

So basically the caching saves the output of the last user (when the caching is set), and displays that static output for the life of the caching.

Ok, I understand this better now. And as Ackbarr mentioned, it is better to cache content that doesn't change often, but that is visited often.

Thanks for the information,
Dave