Thread

Hi,

Any tips on speeding-up saves (blog posts, template updates/edits, other…) via the EE1 admin?

Seems like since we upgraded to (1.6.8 to 1.7.0), the EE admin is (usually) slow to save anything to the DB. The time ranges anywhere from 10 seconds to minutes.

I am trying to figure out if it is our server setup and/or the EE installation (or both?)

The IS department thinks we should purge a bunch of old entries.

Any tips would be greatly appreciated.

Cheers,
Micky

Hi, Micky.

How many entries do you have? What about members, comments, trackbacks, etc.?

It goes without saying to optimize all the dbs regularly (weekly?)......
As to whether it is the server, one way of looking would be to see if the server load seems relatively high before you do the insert. Inserts do seem to take longer (no matter what) than most other actions, so if you are straining the server in the first place it would definitely matter.

10 seconds is almost OK. Minutes?  crazy!

I did not notice any difference in the upgrade in terms of speed.

Another hint might be to look at the EE page load stats if you have those at the bottom of the page. That shows (I think) only the timing of the DB queries needed to build the page. If that is low, but the time to load a page is high…..then it might be the apache part of the server (load, number of children spawned, etc.) slowing it down - that is, the server is putting the request in line.

I’m not EE support (obviously).....just someone who has run into speed problems myself and fixed them in one way or another! Usually, the server load in a terminal will tell you a lot…...or at least give you the first hints.

Hey all!!!

Thanks so much for the help, I really appreciate it!

@Sue:

Entries: 10039
Members: 73 (Not all are active)
Comments: 75891
Trackbacks: Turned off.

@Craig

Oooh, great tips! Thanks!

We definitely do not optimize dbs weekly. I hate to say it, but we typically only repair/optimize via the admin when there are issues with comments on the front end or something.

I will talk with the IS dept. about how we can automate optimization of the db.

Yah, sometimes it takes a minute or longer to save an entry and/or template changes… I think I have noticed it speed up after the first time saving, but it is pretty random.

I am just now making a test entry to a test blog, and I lost count after a minute and 30 seconds; the posting definitely took at least 3 minutes to think.

After the next screen popped up, here is what I saw at the bottom of the page:

ExpressionEngine 1.7.0 - © Copyright 2003 - 2010 - EllisLab, Inc.
Script executed in 0.0898 seconds   17 SQL queries used
Build:  20101018

Hrmmm, .09 seconds sounds pretty fast to me. Based on the above stats, could we assume that this is a server issue instead of an EE issue?

Fortunately, the front end of the site (the public facing end) is pretty sporty.

Thanks again for all the help Sue and Craig! Much appreciated!

Have an excellent day. 😊

Cheers,
Micky

If you get a sub-second script execution time and still see a slow site it’s safe to assume some server issue, yes, I think.

You can optimize the DB through phpmyadmin or even EE’s control panel…and weekly does not really matter in a db of that size - as long as you do it every once in a while you should be OK.

Yes, the EE scripting is happening quickly, so it seems not to be a back-end thing. There are so many variables that guessing is tough, but there are things to look at:

1. DNS on your computer and network - use googles DNS if possible - 8.8.8.8 and 8.8.4.4.
2. The actual web serving app on the server - usually Apache.

If the server is truly waiting that long to process your request, something is way off in terms of (probably) the apache or php part of the deal -IMHO.

But if you really want to troubleshoot staring from scratch, use the old process of elimination! That is, first rule out certain parts:
1. DNS
2. Server total load. Ask your admin if you don’t have terminal access…have them do a “top” or similar command to see what the server load is - that will also show them how much of the CPU each process is using and allow you to see if mysql is the culprit or more likely php-apache.
3. Optimize the DBs…
4. Have your admin run a mysql testing script (there are a few on the web - perl programs, etc. which will tell you if your cnf file for mysql is set right.
If all of those show OK, then next look at the apache conf file(s), usually called httpd.conf

This tells the server how many web page requests it can work with at one time…..if none are available or if too little memory is allocated to each (or to the whole server), then delays will occur.

There are settings in that file which look something like this:
StartServers     20
MinSpareServers   20
MaxSpareServers   25
ServerLimit     800
MaxClients     800
MaxRequestsPerChild 1000
———————————-

Your admin should check them - the settings are based on a lot of things, including available RAM…..etc.

One thing you did not mention was whether your site is heavy traffic…or is it a dedicated server or shared, etc.? This should be reflected in the load numbers.

Sorry for all the tech talk, but these things can be tough to track down.

Also, it’s not a bad idea to restart apache (graceful) every once in a while…also mysql.

If you do find out it is the load, there are a lot of ways to slightly reduce server load….everything from turning off logging in apache to slowing down the rate at which google crawls your pages, etc. etc. - you will find those hints at various other threads here.

Wow! Thanks for the help everyone! I really appreciate the pro assistance. 😊

Craig… YOU ROCK! Thanks for all of the great tips!

You know, that is a great idea to test/check the DNS.

Also, the site traffic varies depending on the season, but overall, I would say it is low to moderate traffic.

We are on a dedicated Amazon cloud instance… EC2 server (I think it is called).

Well, I am going to get the IS department involved at this point… The more I think about it, the more I think it could be related to DNS—We have had some problems in the past.

Thanks so much Craig, Sue and Ingmar! Much appreciated. 😊

Cheers,
Micky

Micky,

2 other things to check would be your PHP memory and how much is allocated. The other one is do you have any third-party extensions installed?

Let us know how you get on

Micky,

2 other things to check would be your PHP memory and how much is allocated. The other one is do you have any third-party extensions installed?

Thanks John! I am still waiting for the IS dept. to get back to me on the memory allocation. We do have several third-party extensions installed:

Multi Drop-down List (v.1.1.1)
Comment Spam Prevention (v.1.1)
Fresh Variables (v.1.1)
Radio (v.1.0.2)
Multi Text (v.110)
Clone Entries (v.1.1)
Checkbox (v.1.0.1)
jQuery for the Control Panel (v.1.1.1)
FieldFrame (v.1.4.3)
File, by Mark Huot (v.3.1.1)

Within an entry, the only things being used via the custom fields are “File” and “WygWam”.

Part of me wonders if WygWam could be could be the problem… On all of our blogs, we have WygWam installed on the “Body” field… By default, I have SCAYT spell checking turned on.

The strange thing is I just tested a new blog entry on a test blog, with and without WYGWAM, and every time the blog entries posted within an acceptable amount of time.

Like I said before, the slowness can be random.

I think we have plenty of info to work with for now! Thanks to everyone for the help! I really appreciate it! 😊

Feel free to close this sucker out.

Have a great day!

Cheers,
Micky

Memory allocation:

Directive: memory_limit
Local Value: 128M
Master Value: 128M

Thanks again!

Cheers,
Micky

Thanks for following up. Closing this one out. Feel free to start a new thread if you have any more questions.