very slow site

[redkevin11]

My site is randomly running extremely slow.  I just now had a page generated in 13.446877 seconds.

I get between .13 and > 60 seconds generation time!  I would ideally just like it to be below 1 or 2 seconds. 

http://64.130.12.211 - see stats in the upper left corner.

I'm hosted on Pair Networks, a reputable, and very reliable company.

phpinfo

Please let me know if more information is needed.

[Ted]

It just seems too inconsistent to me to be anything code related.  Just clicking around now, I'm not getting anything over 0.5 sec.

I had a site with pair about 5-6 years ago, and I do agree that they're very reputable.  However, that doesn't mean they (or maybe another client) aren't overtaxing the machine you're on...

Anyway, if it was consistently slow, it would make me wonder if it was the code.  But the random stuff doesn't make any sense.

[lemkepf]

Could it be related to when it's "not cached"? Try clearing the cache, then load the page and see how fast it goes. If it goes slow every time after you cleared the cache i bet it's code related...

[redkevin11]

That makes sense, wishy.  I seem to always  get slow loading pages if I've been away from the site for an hour or so.  If I empty the cache though, I can't duplicate the problem.  

If the problem persists, I will contact pair and see if someone else is hogging resources.  

[LeisureLarry]

Just one question does your hosting company have an internal sql server (i.e. localhost) or an external? I can tell you that this cms won´t work good with external ones.

Greats LeisureLarry

[Ted]

Actually, the problem isn't CMSMS with external sql servers.  We really don't make that many queries per page load (roughly 10-15).  Some things like Zen Cart do well over 200 per page load.  The issue is with the internal network there and whether it can withstand that amount of network traffic...

[LeisureLarry]

Hmm with the old stable hacked a little bit I had up to 40 queries on an uncached page. With the new beta I have 20-25 queries (cached/uncached) without hacks but with modules.

The problem with external sql servers is how many clients use one server, how many queries there are and how good the network between both servers is. But what I wanted to say is, you have an external sql server and your pages with cms ms are loading slow, then take a new hosting company where you access your sql databases via localhost.

[redkevin11]

Patricia, i'll try your suggested links and see if it makes a difference.

I contacted my host, and they don't see any server overload or any other problems with the hosting or database server.

I am now generating a log of load times at http://64.130.12.211/tmp/loadtime.txt.  The top of the log is a little ugly since I was formatting the log.

By the way, I personally like having an external DB server so I can easily log in to it remotely with cocoamysql or yoursql without messing with "tunneling".

[sloop]

Hi all,

I'm a noob to CMS, and a PHP developer too.  My $0.02 - with PHP web apps in general, and CMSes running under PHP in particular, there's a whole lotta code that gets executed for each page view, and that's why a chunk of CPU time is needed.  (I don't know how much of CMS executes for a cached page, but I wonder if ./include.php and other include()s needs to be invoked if you're dealing with a cached page?)

Some geeky advice: On a site I know will be getting a lot of traffic, I'll be doing Apache mod_rewrite caching for pages that don't change very often.  I set up rules in .htaccess to check if a URL already exists as a file.  If it finds the file, it is served statically - if not, the request is sent to CMS.  Here's what that looks like:

#.htaccess
Options +FollowSymLinks -MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.* /index.php [L]

The RewriteCond tests whether the pathname part of the request URL exists as a file on the webserver's hard drive.  The RewriteRule executes if it doesn't exist, and sends the URL to CMS, where it does the normal thing.

In preparation for this, I run a script that uses wget to suck down the parts of the site that are known to be cacheable.  Ultimately, I'd like the Admin code to generate these pages when they're changed by an admin user.

The other thing I'll probably end up using is squid, an HTTP cache program.  It can serve static content a lot quicker than Apache serves it.

Cheers,
sloop

[thumbsucker]

I'm getting a really slow load on my sites too.

In fact, about 9-12 seconds to load the home page! 

I know it's not the host because my other site running Vbulletin loads very quickly.

Anyone know what can be done?  I would hate to have to switch CMS again. 

[thumbsucker]

I think changing to the "false" setting did the trick!  Thanks!!


Should I still put a # before "header("Content-Length: ".strlen($css));" in stylesheet.php?

[redkevin11]

My host (pair.com) has verified that there is NOT anything hogging resources on the server (web host or db server), but they moved me to a different db server 2 days ago just to be safe.  I'm the only one on this db server right now.

I am still having a very slow-loading site.

Take a look at these page-loading stats.  http://64.130.12.211/tmp/loadtime.txt.

I have tried the above suggestions and it hasn't made a difference.

I have run other scripts on this server and it seems to be fine.

[sloop]

redkevin11,

It sounds like you are running on a shared host - that right?  It would be good to know how much cpu time your page generation is actually taking, versus wall clock time reported by CMS.

Short version: I modified index.php to add the CPU time usage, and the ratio of CPU time over clock time.  Download the attached zip file, and try swapping in each of the two index.php versions it contains for your original index.php (first copy or rename the original index.php to another name, so you can revert it later.)  Report back here with the "Generated in..." message, and hopefully your host is reporting real CPU usage

Long version: CMS's index.php seems to report wall clock time - that is, how many real-world seconds have transpired since starting the script.  On a busy, multi-site server, that number won't bear much relation to how long the CPU took to generate your page.

Being curious about these things myself, I threw together an experimental version of index.php based on release 0.11.2.  It includes some calls to PHP's posix_time() function, which reports how much CPU time the current process has taken.  Mind you, the accuracy of this function within PHP is up for debate, and its output is known to vary from O/S to O/S.

However, if you accept that it's not 100% accurate, and need some idea of how busy your hosting provider's machine is, I suggest trying it.

Attached is a zip-file with two versions of index.php - one for Linux-based hosts with PHP /proc permission, the other for everything else, including Linux hosts where /proc access isn't known.  (The Linux version attempts to obtain the current process load average from /proc/loadavg, which requires that the 'open_basedir' config setting includes '/proc'.  Don't worry if it doesn't, just use the other, "nonlinux" version.)

[sloop]

Okay, the forum doesn't seem to like zip-files, so here it is: http://onjs.com/test/cms_index_timetest.zip.

[sloop]

"the ratio of CPU time over clock time"

This should be "the ratio of clock time over CPU time."  The value of this number: Say the page takes 0.2 cpu seconds to make.  If the host is not busy, you should see a low ratio.  But if the CPU is taxed by many websites being served from the same machine, you'll see a high multiple - higher than 1, and maybe higher than 5 or 10 or more.

Big numbers indicate a busy server, iow.