Site is EXTREMELY slow

Permalink
I have followed every suggestion to help fix my site. I am now at my technical end. The site is pinevalleyhoa.org hosted on a shared server with dreamhost. I have never had performance issues before and dreamhost has been very helpful. Their last reply to me was as follows:

I'm sorry that you are encountering these issues. It would appear that
the sites that are running under your user "gte037p" are occasionally
hitting our shared server's memory limits. This is why your site is
seemingly slow, and the 500 errors are directly related as well. Here is
an excerpt from the log kept by our Process Watcher, the daemon that is
killing your troublesome php5.cgi processes:

Mon Jul 2 11:14:08 2012 procwatch3 INFO: PID 27902 (php53.cgi)
gte037p:pg559055 - killed for uid ram total exceeds limit
Mon Jul 2 11:14:08 2012 procwatch3 INFO: PID 19521 (php53.cgi)
gte037p:pg559055 - killed for uid ram total exceeds limit
Mon Jul 2 11:14:08 2012 procwatch3 INFO: PID 26423 (php53.cgi)
gte037p:pg559055 - killed for uid ram total exceeds limit
Mon Jul 2 11:14:19 2012 procwatch3 INFO: PID 26479 (php53.cgi)
gte037p:pg559055 - killed for uid ram total exceeds limit
Mon Jul 2 11:14:19 2012 procwatch3 INFO: PID 17339 (php53.cgi)
gte037p:pg559055 - killed for uid ram total exceeds limit
Mon Jul 2 11:14:30 2012 procwatch3 INFO: PID 27370 (php53.cgi)
gte037p:pg559055 - killed for uid ram total exceeds limit
Mon Jul 2 11:14:41 2012 procwatch3 INFO: PID 29773 (php53.cgi)
gte037p:pg559055 - killed for uid ram total exceeds limit
Mon Jul 2 11:15:43 2012 procwatch3 INFO: PID 29719 (php53.cgi)
gte037p:pg559055 - killed for uid ram total exceeds limit
Mon Jul 2 11:15:54 2012 procwatch3 INFO: PID 29850 (php53.cgi)
gte037p:pg559055 - killed for uid ram total exceeds limit
Mon Jul 2 11:15:54 2012 procwatch3 INFO: PID 29823 (php53.cgi)
gte037p:pg559055 - killed for uid ram total exceeds limit


Procwatch is a daemon that runs constantly on shared servers to monitor
the usage of RAM/CPU and execution time so that no single user can use an
inappropriately high percentage of the shared resources and impact the
overall health of the server or the server's ability to serve all users'
pages.

Now, it's important to get these errors fixed to keep your sites running
with optimum speed, as well as keep our servers happy. Unfortunately it
can often be a bit of a trial-and-error procedure, but I will provide as
much information as I can to aide you in this process.

Firstly, it should be noted that any sites running under your user can
contribute to the problems you are encountering. For example, if site A
is running processes that are taking up 85% of your individual limit, and
site B tries to run a concurrent process that takes up 20% of the memory
cap, site B will have it's process killed since it is the one that took
you above your limits, even though site A's script is the obvious memory
hog... For this reason, it's important to keep all of your user's sites
optimized and running smoothly.

There are quite a few things that can contribute to high memory
consumption on any given site, but I will mention the most common
causes...

Plugins - Especially third-party plugins can often be poorly written and
run up the memory consumption. I often recommend disabling all
non-critical plugins and see if the problem gets better, then enabling
them one-by-one until you are able to identify one that causes problems.

Database related overhead, or an unnecessary amount of database queries -
If you are trying to query your database for thousands of results at a
time, this can also cause issues... Try to keep all database sizes and
queries to a minimum by deleting irrelevant or old information from your
database. You might also try optimizing tables in your databases by
visiting your database through PHPMyAdmin. Simply use the "Check tables
having overhead" link located directly underneath your tables and then
"With Selected:", choose "Optimize Table". This might reduce overhead in
your database, which is basically a lot of empty and redundant space that
can slow your queries down.

It is also possible that a spike in traffic, or a heavy run by a site
indexer (such as the GoogleBot), or even abusive hits by a given IP
address, could cause this on a short term basis, so you might want to
inspect your access logs for such activity (you can often manage this
problem by implementing a robots.txt or by blocking abusive IP addresses
with .htaccess).

The other sites I have hosted under the user name are very basic wordpress sites and one RapidWeaver site. They all have very basic settings and few, if any, plug-ins. Also, those sites seem to run very well, overall.

This issue only began with the concrete5 installation.

I have tried turning Page Cache on and off within C5.
Within Dreamhost: Cloudflare, Page Speed optimization, PHP 5.3 FastCGI.
I've also followed the documentation list here:http://www.concrete5.org/documentation/developers/system/performanc...

It seems like the problem is somewhere within the site.

Please help!

 
mnakalay replied on at Permalink Reply
mnakalay
Hello,
According to tests I ran, the big problem is the time between the browser sending a request and the first byte received back also know as "Time ot First Byte"
This is the sign that what dreamhost told you is correct. I mean, it is definitely a resource problem, it doesn't mean it is Concrete5's fault. It also is a common problem on shared hosting with servers packed so full that everybody gets a tiny bit of processor power.

What's more, your CPU usage seems to be really limited during that time, really nothing special. Results change a lot, some tests gave 20 seconds or more load times, other gave 9 seconds. I think probably you are on an overcrowded server. But don't think my word for it, it's just an assumption.

Anyway, one thing you can try and see if it makes a difference is block caching (not just page caching). In theory it should help with the TFB I mentioned.

You should also check your site.php file, make sure you don't have any extra quotes and extra lines at the end, spaces or any extra white space outside of the
<?php
// There shouldn't be a single space, line, anything outside of the php tags
?>
gte037p replied on at Permalink Reply
I've turned on cache here: dashboard/system/optimization/cache/

I do not understand how to setup block caching. I followed this thread, but I am confused...
http://www.concrete5.org/community/forums/documentation_efforts/spe...
jero replied on at Permalink Reply
jero
You could try this in config/site.php

define('CACHE_FRONTEND_OPTIONS', serialize(array('automatic_cleaning_factor' => 0)));


The default values for the Zend cache can be pretty aggressive when it comes to cleaning. If it works, you may need to clear your cache by hand once in a while, because you will burn more diskspace.
gte037p replied on at Permalink Reply
I tried that, and I get the following error printed on the homepage.

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/gte037p/pinevalleyhoa.org/config/site.php:15) in/home/gte037p/pinevalleyhoa.org/updates/concrete5.5.2.1/concrete/startup/session.php on line 32

Warning: session_regenerate_id() [function.session-regenerate-id]: Cannot regenerate session id - headers already sent in /home/gte037p/pinevalleyhoa.org/updates/concrete5.5.2.1/concrete/models/user.php on line 71

Warning: Cannot modify header information - headers already sent by (output started at /home/gte037p/pinevalleyhoa.org/config/site.php:15) in/home/gte037p/pinevalleyhoa.org/updates/concrete5.5.2.1/concrete/libraries/view.php on line 843
gte037p replied on at Permalink Reply
I tried that, and I get the following error printed on the homepage.

*Warning*: session_start()
[function.session-start<http://www.pinevalleyhoa.org/index.php/login/do_login/function.session-start>]:
Cannot send session cache limiter - headers already sent (output started at
/home/gte037p/pinevalleyhoa.org/config/site.php:15) in*/home/gte037p/
pinevalleyhoa.org/updates/concrete5.5.2.1/concrete/startup/session.php* on
line *32*

*Warning*: session_regenerate_id()
[function.session-regenerate-id<http://www.pinevalleyhoa.org/index.php/login/do_login/function.session-regenerate-id>]:
Cannot regenerate session id - headers already sent in */home/gte037p/
pinevalleyhoa.org/updates/concrete5.5.2.1/concrete/models/user.php* on line
*71*

*Warning*: Cannot modify header information - headers already sent by
(output started at /home/gte037p/pinevalleyhoa.org/config/site.php:15) in*
/home/gte037p/
pinevalleyhoa.org/updates/concrete5.5.2.1/concrete/libraries/view.php* on
line *843*
guythomas replied on at Permalink Reply
guythomas
You probably added an unwanted space when you edited the site.php file. Go back in there and make sure you have no spaces at the beginning or end of the file.
jero replied on at Permalink Reply
jero
I've never known it do that before, but it does sound as if youi may have added a blank line into site.php, as guy points out.
mnakalay replied on at Permalink Reply
mnakalay
I really assumed he already checked his site.php file since I offered it as a possible solution 2 days ago.

Another possible problem could be the php settings.
On godaddy, when this problem happens the fix is to create a file php5.ini at the root and to add to it
cgi.fix_pathinfo=1


I don't know if it would work here though. worth a try
thecaen replied on at Permalink Reply
I have encountered a similar problem. Did you find a solution?