I am relatively new to Xoops, and have set up two sites. Once works well, the other is slow (12 seconds to load first page.)

I have looked for a "best practices" (or items to avoid) which impact speed. The setup screens do a good job of inidcating settings and implications, but was hoping to find a quick ckeck-list of the stupid things I may have done which would cause the system to run slow.

Both my sites are base on Xoops 2.4.4 and use the Contents (1.32) Module.

The site which runs fast is running on Dreamhost.com on Linux; the one running slow is on Web.com on a Windows system. Both run PHP 5.x

The slow one has:
- cache set to 1 day or more in blocks and system-wide settings
- GZip enabled
- recompile templates = false
- persist connection for mysql = yes

I has tried a number of modules (AMS 3, ArchContact.1. ContactUs .8, Edito 2.31, iMenu 3.1, Liase 1.23, MultiMenu 1.74, News 1.64) which have all been disabled and uninstalled.

I am using MySQL 5.0.77; besides xoops_config and xoops_group_permissions, no table has more than 50 records. the entire DB.

The regular HTML pages and non-xoops pages are served up promptly.

Using debug, I have no errors- just a slow load as follows:
Timers
XOOPS took 12.436 seconds to load.
XOOPS Boot took 2.595 seconds to load.
Module init took 0.665 seconds to load.
XOOPS output init took 7.517 seconds to load.
Module display took 0.063 seconds to load.
Page rendering took 1.274 seconds to load.

I am using default theme; the main page has only 8 blocks, with nothing fancy - just text. (I tried to disable half of these and it did help a little, but the blocks was one of the main advantages for moving to xoops.) I have only a samll graphic at the top and a logo on the page. I used Speed Test (http://www.indeep76.com/) which indicates the image load are not a problem.

Any thoughts? I see that 2.5 is available, but hoping for some guidance on things I may have overlooked before trying the upgrade.

Thanks in advance for any suggestions.

If everything is the same (modules, code, and number of queries), but one site is slower, that would indicate that there is a problem with that particular host.

Unless you have an requirement that it should be run on Windows, I would just switch the slow site to Linux on Dreamhost.

Thanks for the quick reply. The sites are different and the Linux site is much simpler, but a 12 second load time will not work - this is all static data - no forums, etc at this time.

Is there that much of a difference between Linux and Windows on speed?

Any other dumb things I could have missed in setting up the second/slow site?

- If a module is disabled/uninstalled (but still shows on the bottom of the modules screen), can I assume it has no impact?

It's really hard to say what is causing it. I would suggest to test the same site on Linux and compare the results. If it's faster, move to Linux.

I don't know about performance differences between Linux and Windows, but unless you HAVE to have a Windows version, just test your "Windows" site on Linux, and if it's faster, just move it there.

Uninstalled modules should have no impact on performance, as far as I can tell.

In order to make an apples-to-apples comparison, you need to set up a site on both providers as close to the same as possible and then look for the differences.

I suspect that the Windows host isn't loading the PHP module effectively with IIS, but that is my best guess. However, it is also possible that your Windows provider is also massively oversubscribed. In that case, it doesn't matter who your provider is.

You might try turning off the gzip and the persistant connection. My suspicion is that you are seeing a difference in servers. The vast majority of servers out there that provide windows servers also generally provide linux servers as well. The hardware is the same but a linux server costs nothing for the OS as opposed to hundreds if not thousands for the OS of windows server. Plus the performance of a linux server should be much faster since a graphical environment is not necessary. Unless you have a specific reason to use a windows server I would suggest asking for a linux server instead.

I seem to have read somewhere in one of my classes that you should not use a persistent connection unless necessary as this can be a performance hit. Also using gzip would also slow down things as it would require associated files to be compressed and decompressed as needed and this step can slow you down.

In this age of cheap storage I would never use gzip compression with a website. Only to store files offline.

Quote:
gzip compression actually reduces response times. See here

Thanks for suggestions.

I found turning off GZip helped with load time; it is now around 4 seconds.

Changing the makefile.php :

// Use persistent connection? (Yes=1 No=0)
// Default is "Yes". Choose "Yes" if you are unsure.
define('XOOPS_DB_PCONNECT', 1);

to zero actually increased time by about a half second. I set it back to 1 and times now remaining around 3 - 4 seconds (using 10 retries):

Timers
XOOPS took 3.382 seconds to load.
XOOPS Boot took 1.290 seconds to load.
Module init took 0.290 seconds to load.
XOOPS output init took 1.802 seconds to load.
Page rendering took 0.403 seconds to load.

Before trying to reinstall on a Linux system, just wanted to ensure I exhausted all options...

Still would like to see it closer to the speed of the second site:
Timers
XOOPS took 0.193 seconds to load.
XOOPS Boot took 0.032 seconds to load.
Module init took 0.002 seconds to load.
XOOPS output init took 0.060 seconds to load.
Module display took 0.022 seconds to load.
Page rendering took 0.045 seconds to load.

The Windows (slower site) has XForms module 1, Protector 3.4 (currently disbaled) and Content 1.32 modules installed; the faster site has Content 1.32, SmartFAQ 1.08 and Forum 3.08 modules installed.

The time is from the first page display and both show only system blocks. Blocks have only basic HTML tags (unordered list tags and paragraph tags).

Thanks again for suggestions.

Quote:

Problem with this though is that it takes processing time to actually compress and decompress this stuff. In order for Gzip to speed up the response time it requires that it takes longer to transfer the uncompressed data than the combination of the compressed data and the processing time to compress then decompress this data.

If the server can cache the compressed files then it becomes a no brainer from the server side as it will only need to compress them the first time they are accessed.

However the browser is still then the limiting factor. If the computer the browser is running on is an older computer that has little CPU power then you want to do as little CPU loading as possible. This again would be greatly improved if the browser also caches the files.

But then again, if both sides cache the requests then it becomes a moot point if you are using gzip or not as it would only impact the original request.

The other thing to take into consideration is the connection speed. Someone on a dialup would get MUCH better throughput with gzip than someone running a 12G connection. Someone on a local network with a fiber 1000T network or loading from the localhost might see a considerable reduction in response time not using gzip.

I also want to point out in my original comment I was thinking of the storage of the files on the site, not the transfer of data across. Also some connections already do a considerable amount of compression so it actually slows down the response to compress data that is already compressed.

So I guess what I should say after typing all of that... Gzip CAN reduce response time in SOME instances but in others it can increase the response time. If enabling it slows down the response then it is a sign that either the browser or the server is over loaded in comparison to where it should be.

Good link though Mamba, I book marked it for future reference.

Thanks.

I found there is an IIS 7 setting for "Compression" and "enable static content compression" is set to true at the server level and I cannot find a way to override this. I do not know if this is creating a problem or not.

Looks like I am moving to Linux!

Again, thanks to all for the help!