Max execution time exceeded on every try

wordpress

#1

Problem: www.tompotika.net is down
Fatal error: Maximum execution time of 30 seconds exceeded in /home/marsum8/tompotika.net/wp-content/plugins/qtranslate/qtranslate_core.php on line 651
or
Fatal error: Maximum execution time of 30 seconds exceeded in /home/marsum8/tompotika.net/wp-includes/option.php on line 91

What now??

I have been adding pages to my new WordPress site, and testing as I go. Suddenly I get this and similar errors, quoting different lines of different code files on separate tries.

My design is done in Headway framework using WP 3.5, and qTranslate plugin, along with a widget for putting small images in the sidebars. Not much else.

WP SuperCache is running.


#2

The site is up for me now. Did you get this fixed or do you still need some help?


#3

Hi Ipstenu!
It makes me feel much less lonely just to hear back from you. Thanks! I do still need help. I’m afraid that if three people visit the site at once, the error will start happening to them.

DreamHost tech support (in a not very friendly message) told me I had exceeded the limit on server memory and that was why I got all those errors. Following that lead, I did things aiming to reduce the memory requirements. One of them takes out parts of my design that my client wants (a soft requirement), but at least I’m not hitting that memory limit any more.

I think I am using my hyper-user-friendly theme framework (Headway) in a less than efficient way (I’m new to it). My bilingual plugin is slow. but I don’t think it uses too much memory because I have very little content in either language yet. I would like to have a better understanding of how my configuration is using memory.

Here is something I’d really like to get your opinion about: When I started to get the errors, I was using three windows: one running the site to view work as I did it, one running the WordPress Pages/Widgets/Menus/Plugins functions, and one the Headway visual design functions. The problem started immediately after I added about 7 new pages, gave each of them a slightly different layout, and added them all to the menu. Given that I was only working in one window at a time, would those simultaneous windows explain the errors? I haven’t been able to reproduce the errors by starting up the three screens again.

Then things started working again when I took out sliders from every possible page, substituting only one image each, and removed many instances of a widget displaying a small image in the sidebar. Headway works by having one layout reference blocks in another layout, except where there is a difference. In my case, every page had its own layout, and in most, the only difference was showing different images outside the content area.

If only I understood what changes would make the most difference!

I appreciate the chance to pick your brain about my issue.


#4

It’s an automated message, don’t worry about the friendliness, it’s just what gets sent when systems poke us. I don’t think the 3 windows at a time matters, since once the page loads, it’s loaded and done.

That said, the sliders may be the issue, if they’re resource intensive. Grab the P3 Profiler - http://wordpress.org/extend/plugins/p3-profiler/ - and see if your plugins are being heavy hitters.

One thing you can do right away is turn on Page Speed Optimization (go to your panel -> Domains, edit the domain, check the box). That will add some dynamic compression.


#5

Done, thanks. I’ll report what I learn, for the common good.
[hr]

[hr]
I got this when I started the P3 scan:
Fatal error: Allowed memory size of 94371840 bytes exhausted (tried to allocate 72 bytes) in /home/marsum8/tompotika.net/wp-content/plugins/p3-profiler/classes/class.p3-profiler.php on line 287.
Ideas?
[hr]
More from that scan: (qTranslate is a pig)
Performance Profile Results for Alliance for Tompotika Conservation:
WordPress Plugin Profile Report

Report date: March 14, 2013
Theme name: Headway Base
Pages browsed: 2
Avg. load time: 1.5218 sec
Number of plugins: 10
Plugin impact: 68.80% of load time
Avg. plugin time: 1.0469 sec
Avg. core time: 0.0839 sec
Avg. theme time: 0.2036 sec
Avg. mem usage: 73.50 MB
Avg. ticks: 65,752
Avg. db queries : 35.50
Margin of error : 0.1873 sec

Plugin list:

P3 (Plugin Performance Profiler) - 0.0082 sec - 0.79%
Akismet - 0.0065 sec - 0.62%
BackupBuddy - 0.0430 sec - 4.11%
Google Xml Sitemaps V3 For Qtranslate - 0.0015 sec - 0.15%
Hotfix - 0.0026 sec - 0.24%
Image Widget - 0.0029 sec - 0.27%
NextGEN Gallery Optimizer - 0.0088 sec - 0.84%
Nextgen Gallery - 0.0376 sec - 3.60%
qTranslate - 0.9164 sec - 87.53%
Wp Super Cache - 0.0194 sec - 1.85%
[hr]
I need some help interpreting these results, a little more detailed than “qTranslate is a pig.” The scan shows 36 mySQL queries in two page visits before the memory error came up. Is that normal?


#6

Well… qTranslate is the problem. If you’re going to keep using it, you’ll need more memory :confused:

Alternately, you can turn it off, turn the sliders back on, and run the scan again. See what changes. That way we can have a comparison.


#7

[hr]
I’ll go back to a backup and turn qT off, and see what the scan says.
Does anyone reading this have experience with how the WPML premium translation plugin performs? It sounds like major overkill for us, but I think there is a plugin that will port what I have in qT over to WPML, and that would be nice.
I might revisit Polylang (free) but its user interface for content entry is labor-intensive. I wish it was easy to load it and run the scans.


#8

Trouble using BackupBuddy and ImportBuddy! Looks like I made a total mess of it.
The good news: I made two backups using Backup Buddy, and have both local and remote copies of them, on Amazon S3.
The bad news: When I followed Import Buddy instructions to delete the existing site before I could import the backup from March 13, it required me to create a new database, and that did not go smoothly.
ImportBuddy gave me certain strings of characters to use in the process. The DreamHost database panel refused all of them, so I made up new ones.
My new database was created.
Again I reached ImportBuddy step 4, and again got error "Warning: fopen() [function.fopen]: Filename cannot be empty in /home/marsum8/tompotika.net/importbuddy/lib/mysqlbuddy/mysqlbuddy.php on line 726. Database import failed. Please use your back button to correct any errors."
I’ve been here before. So I go back to step 3 in Import Buddy, URL & Database Settings.
I’ve lost courage to try to complete this without guidance.
Can someone magically give me back what I had this morning? I have a BackupBuddy backup from then, but will it be usable??If not that, should I try to restore the 3/15 backup using ImportBuddy?
Or should I restore the database from the DreamHost database management pages? Then can I get my files back? From what point? I am very very calm. Calm. Calm.


#9

I’m actually a little afraid to ask why you were doing a backup and restore at this point. Turning off the plugin doesn’t require you to delete anything and I certainly didn’t suggest you do that at this point.

What exactly did you delete and why?

Our SQL backup restore should be able to bring that back, which you should do right away. You can try the files, but they’ve been pretty hit or miss.


#10

What I did:
I deleted all files from my WordPress installation, and also the database. This was according to the instructions in BackupBuddy and its complement, ImportBuddy.

Now I have successfully restored that database from the trash.
What do you recommend for the files? I don’t have a files-only backup.

I am clear that you did not tell me to do what I did. I was trying to to save quite a bit of time–
To get back to the design with the sliders and all the images, to test what happens with qTranslate turned off, I would have had to do a lot of work. I had stripped out a lot, and I have replaced some of that with a better approach. I don’t have a record of all the choices I made to set up the original design. So I thought, I have a backup from before I started taking things out. I’ll just roll back to that. In addition, I wanted to proceed from my latest version when I move on, so I planned to roll forward with that backup after my testing.

If I have to start over, I’ll do it with a different plugin for multilingual.
Does DreamHost back up files?


#11

Next time, just say “It’d be a lot of work to put the sliders back in, how about I just test without that plugin to verify that’s the case?”

We have a server backup, and you can try running a restore from that.

What on earth is BackupBuddy backing up if not the DB and the files!? You need to go talk to them about how to use their plugin correctly if they’re not doing that, cause it’s a waste of your money otherwise.


#12

[hr]
Oh how I wish I had asked you as you suggest.

BackupBuddy does backup databases and files, but I was just unsuccessful in restoring from the older backup, so it seems like I won’t do better with the newer backup. Maybe I’m wrong.

Do you think I should restore DH’s latest backup first, or begin with BackupBuddy for support in restoring the later backup?

Sorry.


#13

I’d start with BackupBuddy, personally. Our backup will probably be from yesterday, at best, versus the backup you just ran before nuking.


#14

The chances of having the DH file restore working are slim to none, but if Backup Buddy actually backs up the files then you should have rather easy access to the files (even if manually unziping something in order to get to them). Is there not an archive you can download?


#15

Ipstenu, sXi,
Thank you for your good advice.
I unzipped my latest BackupBuddy backup, FTP’ed it up, and the site is back. No errors.
(applause, cheering, whistles, dancing)
…back to the original problem, using too much memory for the DreamHost shared server policy.
I resumed P3 testing. While I was testing with qTranslate and P3 running, with design elements removed, I got the out-of-memory error. which suggests I don’t have enough head room in memory to complete my design as planned, until I find a more efficient multilingual plugin.
Then I turned off qTranslate and scanned. The next highest resource user is the theme. Plugins are down to using 12% of memory. Pages are loading but not very fast.
P3 gives me seconds, and I’m currently trying to control memory usage.
Can you assume that if it takes a long time for a component to load, it also uses a lot of memory?

Summary question for this thread: Can I get faster site performance, complete design and bilingual function – everything I want – without upgrading to a VPS?

I do appreciate your support!!


#16

Try increasing your PHP memory to 64M.


#17

PHP memory_limit is 90M by default here at DreamHost. 64M would be a decrease :wink:


#18

phpinfo() says my server memory limit is set to 90M.
Backup recommends minimum 128M or better, 256M

What undesirable thing might happen if I set it that high?


#19

Whoops, brain defaulted to industry standard (which is 32, please don’t ask me why…).

128 would be good. If you set it too high, you might hit procwatch, which means you would have to go to a VPS.