Thread

It’s me again!

Okay, I had the site running earlier but the database was a bit of a mess, so I re-did the upgrade instructions, and everything looks great however it’s now very very slow to load.  To stress, it was not slow before with a borked up database, it is slow now.

Upgraded from 1.5.2 to 1.6.4 and the EEDF to 2.1.0.

The old site is here.  Note that you can’t click around, or it will take you to the new site. 

Average time for page load on the old site is 1.6 seconds.  Average time for the new page to load is 5.8 seconds.

New site.

CP load averages:  New site - 5 seconds, Old site - 0.4 seconds.

I have checked out the data caching page, and nothing has helped so far.

Since it was running perfectly a few hours ago, on the same server, it leads me to believe it must have something to do with the upgrade itself.

Is there somewhere that might be looking for the old database information, that I need to change?  Any ideas?

Greetings,

A few things we would like to checkout…

• Which environment is your server running in? (PHP - Shared/Static/CGI)
• Verify your file permission on your cache folder (Make sure you are able to write to that directory)
• Verify your path settings are correct for things like themes/member signatures/poto/avatar, CAPTCHA, etc…
• Enable PHP errors. (Admin -> System Preferences -> Output and Debugging)

Greetings,

A few things we would like to checkout…

• Which environment is your server running in? (PHP - Shared/Static/CGI)
• Verify your file permission on your cache folder (Make sure you are able to write to that directory)
• Verify your path settings are correct for things like themes/member signatures/poto/avatar, CAPTCHA, etc…
• Enable PHP errors. (Admin -> System Preferences -> Output and Debugging)

Shared.  File perms on the cache folder are fine, I can see the cache fill (via FTP), and it empties correctly via the CP.

Member upload paths were incorrect, they have now been corrected.

Themes are fine.

Captcha was incorrect, has been corrected.  (I don’t use it)

I’ve turned on debugging, so what exactly am I looking for.

Checked after things above were corrected, loaded in 6 seconds.

Just to clarify, PHP is running as a shared module, not CGi?

Just to clarify, PHP is running as a shared module, not CGi?

Is this what you mean?

Server API   CGI/FastCGI

We recommend putting in a tick with your host to have them look at the long load times issue. Let us know what you find out, or if you have any questions. =)

We recommend putting in a tick with your host to have them look at the long load times issue. Let us know what you find out, or if you have any questions. =)

Excuse me.  This is a site that was put on this server and ran beautifully, mere hours ago.  I did a fresh setup because I had a botched database install.  There were no changes to the server, none.

This started after I upgraded to the most recent EE.

Astro, we can’t see the first site since it’s turned off.

I’m seeing load times of 3.67 seconds.. but I’m not logged in.

Also it looks like you have SiteMeter in there.

If SiteMeter is having problems, your load times will get worse.

Justin’s not trying to shift the blame to the host, but it’s an important step in the troubleshooting process.  Your control panel should never be slow.  The fact that you are experiencing site-wide slow down on both the front end and back end is indication that processes on the server might be at fault for the slowness.  There doesn’t necessarily have to be a change on the server to trigger this.  It could be a product of traffic the server you are on is receiving, including email and database activity if this host runs servers for these things on the same machine as the file server.  If it’s a shared hosting environment, the number of users on the particular machine, or activity of another account unrelated to yours could be responsible for the slowdown.  1.6.4, if anything, would have a minor speed increase over 1.5.2, and certainly not a global slow-down.  Since you are the only user having reported a speed issue, and you had issues on this server already, the solution is most likely external and beyond our control.  Having them simultaneously look for potential issues is the reasonable thing to do at this point.

On our end, though, please elaborate on the database problems that you having, i.e. how was it “botched”?  And what precisely did you do to fix it?  Step us through it please, so that if there is any component of EE at fault for the speed change, we can help you identify it.

Feeling that there was a “crossover” going on, I changed the db login info on the OLD db.

It killed the new site. 

So checking the config.php, it was still pointing to the OLD db.

I followed the instructions here:

Do NOT overwrite the path.php or config.php files you backed up in step one.

I’ve fixed the config.php and it’s still not working.

Justin’s not trying to shift the blame to the host, but it’s an important step in the troubleshooting process.  Your control panel should never be slow.  The fact that you are experiencing site-wide slow down on both the front end and back end is indication that processes on the server might be at fault for the slowness.  There doesn’t necessarily have to be a change on the server to trigger this.  It could be a product of traffic the server you are on is receiving, including email and database activity if this host runs servers for these things on the same machine as the file server.  If it’s a shared hosting environment, the number of users on the particular machine, or activity of another account unrelated to yours could be responsible for the slowdown.  1.6.4, if anything, would have a minor speed increase over 1.5.2, and certainly not a global slow-down.  Since you are the only user having reported a speed issue, and you had issues on this server already, the solution is most likely external and beyond our control.  Having them simultaneously look for potential issues is the reasonable thing to do at this point.

On our end, though, please elaborate on the database problems that you having, i.e. how was it “botched”?  And what precisely did you do to fix it?  Step us through it please, so that if there is any component of EE at fault for the speed change, we can help you identify it.

The previous database issue doesn’t matter.  The site was updated (updated EE) with the backed up working database early today, which worked fine, except it was horridly slow.

Has your provider switched you to a different box, or anything like that?

As Derek said earlier, your problems could be related to other sites on the same server.

MySQL ERROR:

Error Number: 1054

Description: Unknown column ‘g.site_id’ in ‘where clause’

Query: SELECT m.weblog_id, m.tmpl_group_id, m.username, m.screen_name, m.member_id, m.email, m.url, m.location, m.join_date, m.last_visit, m.last_activity, m.total_entries, m.total_comments, m.total_forum_posts, m.total_forum_topics, m.last_forum_post_date, m.language, m.timezone, m.daylight_savings, m.time_format, m.profile_theme, m.forum_theme, m.private_messages, m.accept_messages, m.last_view_bulletins, m.last_bulletin_date, m.display_signatures, m.display_avatars, m.last_email_date, m.notify_by_default, m.ignore_list, g.* FROM exp_members AS m, exp_member_groups AS g WHERE g.site_id = ‘1’ AND unique_id = ‘0a631974cc6147d7473524070a1ef5dccdf44fcb’ AND password = ‘ef015f399f6c65efb5a9960b65ad08cae43d0c69’ AND m.group_id = g.group_id

Is what I get now.

Astro, when you replaced your database with an older version, you need to manually back down the value in config.php to the version you were at earlier. Then you’ll need to rerun update.php.

Does that make sense?

Has your provider switched you to a different box, or anything like that?

As Derek said earlier, your problems could be related to other sites on the same server.

Nope, all server info is the same.  I can see the server name in CPanel.

This thing is totally dead in the water, again.