WordPress.org

Ready to get started?Download WordPress

Forums

WP Super Cache
[resolved] Plugin causes Apache to respond with "error 500" (9 posts)

  1. riledhel
    Member
    Posted 2 years ago #

    I'm using Apache/2.2.22 (Ubuntu) with PHP 5.3.10-1ubuntu3.1 with Suhosin-Patch, APC version 3.1.7, WordPress 3.3.2 and WP-Super-Cache v1.0. Sometimes, I can't access the WordPress backend because the server returns an http error 500; but other sites and software running in the same server still work. I can access the cached pages and the static files also.
    My biggest concern is that there are no entries in the apache's error.log that show what's causing this behaviour. I activated the debug option and analyzed the text file, but there are no errors logged there.
    Any ideas? how can I debug this? and more important, how can I fix this? Thanks your your time.

    http://wordpress.org/extend/plugins/wp-super-cache/

  2. Donncha O Caoimh
    Member
    Plugin Author

    Posted 2 years ago #

    It could be anything but try disabling APC first as that is a low level extension that could cause this random problem.

  3. riledhel
    Member
    Posted 2 years ago #

    I enabled the "Use PHP to serve cache files" option (had the mod_rewrite option with the rules in the vhost configuration) and that seems to "fix" my problems so far. You are right about being "almost as fast as the mod_rewrite option". I'll post here if I find the cause of my problems or other news. Thank you.

  4. riledhel
    Member
    Posted 2 years ago #

    Still had problems. Followed your advice, removed APC from the server and installed Xcache. I'll see if that fixes it.

  5. markku
    Member
    Posted 2 years ago #

    Using WP-Super-Cache 1.0, I also get an http error 500 when WP_CACHE is set to true in wp-config.php. I'm running a different system though, it's on Nginx 1.2.0 on Ubuntu 8.04.4, with the latest PHP and WordPress. What makes it strange though is that I have another server with similar specs, but the error does not exist.

  6. Donncha O Caoimh
    Member
    Plugin Author

    Posted 2 years ago #

    markku - it could be anything and I can almost guarantee it's not the same problem riledhel has. Usual advice applies - check your PHP error log.

  7. markku
    Member
    Posted 2 years ago #

    @donncha I can't rule out anything right now nor identify the exact problem. But I'm sure that it manifested after the upgrade to wp-3.3.2 and wp-super-cache 1.0. I've enabled logging in PHP but no clues yet. I'll let you guys know once I discover anything.

  8. riledhel
    Member
    Posted 2 years ago #

    I didn't experience any more WSOD since removing APC and installing Xcache. I assume it has something to do with that, specially because I never had anything written to the php log that could help me trace the problem. Markku, do you have any opcode cache installed in your system? Anything special about your LAMP/LEMP setup?

  9. admintiger
    Member
    Posted 2 years ago #

    APC and the trunk (development) version of WP-Super-Cache run together here without errors on multiple Linux (Ubuntu) and Windows servers. WP-Super-Cache 1.0 fails on all those servers with or without APC, but the problems that cause those failures have been fixed in the trunk version. (Anyone using APC should be sure to use the latest version, because earlier versions had a serious bugs. Some of those bugs cause unrecoverable malfunctions that necessitate server reboots.)

    As you probably know, there are many APC configuration options. APC will fail for a variety of reasons if those options are not set correctly for particular installations. Some settings cause server failures that seem random and also misleadingly occur only when certain PHP scripts, such as WP-Super-Cache scripts, run under certain conditions of available memory and other things. APC works reliably and significantly speeds PHP processing when it is configured right, but finding the best settings for particular installations can be challenging.

    The best way to get APC, Apache, PHP, MySQL and everything else configured to run optimally is to install them on an identical test server that has WordPress/WP-Super-Cache installations mirror-imaged from the normal server and then to use stress-test software that simulates high levels of website traffic to measure speed performance and capacity limits, find causes of failures, and experimentally improve results. That is obviously a lot of work, but the results can be very rewarding, because it is common to find simple configuration changes can greatly increase speed, capacity and reliability.

    Many configuration options in Apache, PHP, APC, MySQL, WordPress, WP-Super-Cache, and other things are complexly interdependent. It is impossible for most people to make reasonable guesses as to what is even approximately best. The interrelationships are so complex that even someone with intimate technical knowledge of the inner-workings of all the components is apt to make selections that testing will prove are not optimal.

    The difference between a server that will crash with a few users and one that will quickly serve thousands without difficulty is often a few configuration settings. Stress-testing is the only way to know the truth about speed-performance and capacity limits. It is lots of work, but where an optimally-configured old desktop computer with WP-Super-Cache can easily outperform a new mega-buck server that is not optimally-configured, stress-testing to find optimal settings is worth the effort.

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic