I would like use XOOPS but I found this:

" I have worked on XOOPS for few months.... It's very slow when you got large amount users. The design is piece of garbage (There are many template, none of them good and clean). Real hard to modified code. XOOPS hard coded everywhere classes, functions, variables, file names, URLs. ...."
http://www.opensourcecms.com/index.php?option=content&task=view&id=165

Thanks for any opinion or idea.

Well, I'm glad we get some negative feedback at least, as most we get here is positive

No, seriously: speed is a difficult thing to control, as it depends on so many things. Just one of those is the CMS. One thing that I've noticed is that XOOPS runs pretty fast, but can be optimised when dealing with large amounts of traffic. XOOPS.org is the busiest XOOPS powered site I know, and we're handling things ok, not great, but acceptable. We have a dedicated server (nothing too fancy, but she works her ass off for all of you, so be nice ). Hardware, configuration, website purpose, XOOPS finetuning, custom design and modules, cache settings, all these (and probably more) contribute to the site being fast or slow. So it's difficult to answer, but I wholeheartedly disagree with the commentator's conclusion that XOOPS's code is badly written (quite on the contrary!), and that many things are hardcoded (again quite the contrary). But judge for yourself

Herko

I totally agree with Herko on this. I have been using XOOPS for 3 years now, and I have yet to really run into a problem I couldn't figure out A. by myself, or B. in the forums. The code, once you get over the learning curve of php and OO, is very well written, and works very well. As far as buggyness, well as you know most modules are written my so many different people that its hard to standardize the way things are used and coded. So typically, the buggyness is usually because of the modules themselves. As far as speed is concerned, like Herko said, sooooooooooo many different factors relate to how fast or how slow the site is on the other end of the pipe. Line congestion, bad routes, server configs, human error in configuring php/mysql, not properly tuning the web site for speed and efficiency. Now granted my site is pretty heavy when you first hit it, but once you get there, it is pretty fast, especially if you knew how small my line speed is (a mere 256k up). Now, once you get there, and start changing pages thats where the server speed kicks in. Now granted the statement that I made above about hardware has alot to do with the quickness of any site. I read once a while back that if you can use a multi-processor server as a web server it will more than double your throughput. Believing in that statement is what made me choose the server that I run. I run all my sites on a quad xeon machine. Granted it might seem like overkill, but let me tell you, its not. It handles any and all queries with the greatest of ease. My site is as fast as many sites out there, but it is alot slower too. Granted if I were to be hooked up to fiber directly to my house this might be a totally different statement, but such is life.

I guess what I am trying to say is that site speed depends on many many many different variables, some of which you have NO control over. Some of them you do. Make sure your machine/server is powerful enough to handle many many queries, and has enough ram. Also, make sure you don't try hosting it on a 56k LOL!!! That helps out a ton!! Optimize the caching features of each module, and block. It helps. Its alot of work, especially if you have many modules on your site.

Set it up, play with it. The only real test is when you start filling up the database. Thats where you will notice a performance hit if there are any.

Cheers!

I will issue a short answer to the quote in the first post, whilst coining a phrase from the great TV character Blackadder.

"Utter Crap..."

Cunning... mr. Bladder!

Hi zzzzz,

It is hard to make a choice in CMS as any answer you get is always going to be weighted in bias towards that persons particular preference. I do not believe that XOOPS is the fastest CMS out there, but in saying that I beleive the difference between the top 10 (of which XOOPS is one of) is only really good for bragging rights. There is going to be nothing substaintial enough performance wise that should be of any serious consideration in your selection process.

The basic fundamentals as the others have mentioned above are what do come into play here, and your selection of CMS is not the only area that dictacts this. After all, you don't bake a cake with only one ingredient do you.

From top (being CMS) to bottom (being hardware), these are some things you'll need to look at when determining performance of your site.

CMS
- Cache. Setting up your cache correctly in your CMS can make a massive difference in performance.
- Modules. Some modules are hugely more resource hungry than others. A part of any evaluation should include thorough testing of any modules you intend to use.
- Theme. The amount of http requests, and content weight (particulary graphics) that are generated by your theme also play a large part in site perfromance. Obviously the lower the better performance wise.
- Content. One thing people tend to do is display a great deal of non essential content on their front page. Minimise this, and you'll also minimise page weight. Another thing is to limit links/content to external sites such as banner ads, images, news feeds and the like.
- MySQL connection. You can use either a persistent or non persistent MySQL connection. Which option suits you best will depend on your hosting environment.

PHP - On a busy site PHP optmisation can have a big effect. Running PHP in something like FastCGI mode (available for IIS and Apache) and using caching such as Turck MMCache and Zend Optimiser are highly advisable.

MySQL - I haven't tinkered with MySQL optmisation a great deal, but there is always chapter 7 of the MySQL manual for guidance here .

Web Server
- Performance here ties in closely with your PHP settings i.e FastCGI. Other things you can do is use http compression such as (among others) gzip (apache), ZipEnable (IIS 6) and HTTP Zip (IIS 5 & IIS 6).

Hardware
- What hardware you use is dependent on all of the above as well as site traffic. Ultimately it is your CPU, Memory and HDD's that are going to dictate performance here, and your server is only going to perform as fast as the weakest link in the chain. For example, if you have a very busy site and have a 3Ghz processor with 2GB of PC-3200 RAM, but only have a single ATA-66 5400RPM IDE hard drive, then anything that isn't cached is going to have very poor performance.