Forum Replies Created

Viewing 15 replies - 1 through 15 (of 17 total)
  • Hi Friend – we are on AWS with wordpress and about to do a 3.6 upgrade.

    AWS is very WordPress friendly however I’ve not used the bitnami image. We created our own LAMP server configurations.

    I noticed several things in your apache log:

    You are getting SSL warnings – you need to check your certificate setup
    You are getting mpm_prefork errors – this is an apache configuration issue and you may need to check the settings in the httpd.conf file. It appears as though you may not have enough memory or there’s another configuration out of place.

    What size EC2 did you choose? Where is the database, is it local to EC2 or is it on RDS?

    Alex – are you using APC Cache?

    Important to understand what environment you’re operating in.

    https://bugs.php.net/bug.php?id=59298

    Hi Mark –
    If you’ve removed the ../wp-content/plugins/wp-super-cache directory and you’ve removed the advanced-cache.php and wp-cache-config.php files from wp-content, also make sure that ../wp-content/cache directory is fully removed.

    Then, check in your root webserver folder to ensure that .htaccess doesn’t have the old rules in it from wp super cache. Also check ../wp-content/cache/.htaccess to make sure it’s been removed.

    The database itself can’t decide you’re still using the plugin if the plugin is removed. I am tending to think you still have rules in .htaccess, and the ../wp-content/cache directory still exists with some content in it. If all of that is removed, WordPress *should* generate your content dynamically and on-the-fly with no caching.

    Hi Michel
    You can do something similar to this with the Preload feature of WP Super Cache. It can pre-build the cache for all your posts in advance.

    Hope this helps!

    Thread Starter DeeJay176

    (@deejay176)

    No Hiarlen I don’t think we are ‘non standard’ – I think that WPSC is not a pure solution, especially for active sites. It is free, so I’m not complaining just stating the facts.

    W3TC is an alternative but has it’s own glitches, we use many different solutions on many different sites all trying to find the perfect strategy. The answer is it’s all experimentation, and that’s not really a strategy.

    Apache vs. Nginx, W3TC vs WPSC vs Batcache vs. whatever, Xcache vs. APC vs Memcached. The realization becomes that WP is not really suited for most active environments unless heavily customized, and this is contrary to how it’s advertised. As you grow, the weaknesses will jump out of the corners and challenge you at every level.

    A classic example of caching problems just occurred with my above post. WordPress.org has not updated the forum index page to show my latest post, yet it still appears here in the comments. This is a *notorious and pervasive problem* with this CMS solution and certain types of caching. I suspect in some timeframe (or TTL), things will get updated and everything will again align.

    Is that what you want to present to your visitors? Imagine in WPSC that your taxonomies may not update for a minimum of 6 hours (if you preload) or you will be required to turn of caching of categories. At that point, what is the benefit? You already have to disable feed caching if you’re to have anything going out to the real world.

    Caching can quickly break your site or cause it to serve up stale material. I would tread very cautiously. There’s a reason your host is disabling your account up front – they believe things you’ve deployed will cause conflicts with APC. APC, Xcache, etc. are all very good solutions but are very fragile in a WordPress environment and it depends on how much activity you have on your site, how things are displayed, and literally how often you want or need material to be fresh.

    WP Super Cache can break instantly with the deployment of APC or Xcache on a heavily accessed site. I have had experiences with both, and recently both appear unstable with the latest releases of WordPress (3.4.2 especially, a little less with 3.4). If you use Buddypress, it’s much much worse.

    Opcode caching is generally ok, but database caching can be a disaster with WordPress on active sites. Make some backups, prepare for the worst, and hope for the best. The problem for me is “hoping” is not a strategy.

    Thread Starter DeeJay176

    (@deejay176)

    Hi Hiarlen thanks for responding! If you are referring to the domain mapping setting – I’m not using it. We use the Sitewide Tags solution to create the primary blog.

    I did find the problem late last night forgot to update this thread. There’s a checkbox on the Advanced screen for Extra Homepage checks. I found a comment deep inside a forum post where Donncha suggested that sometimes this could cause Homepage caching to stop. Well, that was the ticket – it stopped homepage caching on some (but apparently not all) subsites for us.

    I also think in doing all this that I found a solution for the occasional post showing up as a homepage, and it’s related to the complexity of one’s .htaccess file. If you have significant rewrite conditions outside of the standard WP MU .htaccess entries, it’s impossible to tell from the instructions where the WP Super Cache .htaccess modifications should reside.

    I’ve tried the WPSC entries both BEFORE the rewrites and AFTER. Our current config has WPSC BEFORE the rewrites and the site is a bit quirkier than when they were AFTER the rewrites — but before the standard WP MU entries.

    Overall the plugin works but there are definitely quirks and bugs. My favorite is when you try and install supplemental caching (like xcache or APC) and it either (1) scrambles the database until removed, or (2) interrupts the GC routine and causes actual WP-CRON ‘code’ to appear on all the sites and dashboards, even to logged out viewers, as the WP-CRON job gets fouled and the only way to fix it is to ssh into the server and manually delete the WPSC directory. Had that happen twice so far.

    controler,

    We are using WP Super Cache and did not need to activate the plugin on each sub-blog – as a matter of fact the installation instructions for WP Super Cache suggest this is not necessary at all.

    Thread Starter DeeJay176

    (@deejay176)

    Gurumark, you may not be able to run the last step (install) from the directory indicated… I recall now I had to run the install from inside the mysql/scripts directory

    Thread Starter DeeJay176

    (@deejay176)

    Hi Gurumark
    The problem is the base AMI’s from AWS don’t have the correct base compile to work with ClouSE. You need to pull down the original MySQL libraries and compile them locally. Then the .so files recognize the fastmutex symbol.

    I’m not using ubuntu, but similar to:

    Got MySQL 5.5.20 tar from mysql.com:
    wget http://downloads.mysql.com/archives/mysql-5.5/mysql-5.5.20-linux2.6-x86_64.tar.gz
    Followed the instructions in the INSTALL-BINARY file:

    tar xzf mysql-5.5.20-linux2.6-x86_64.tar.gz
    sudo mv mysql-5.5.20-linux2.6-x86_64 /usr/local/
    cd /usr/local/
    sudo chown -R mysql:mysql mysql-5.5.20-linux2.6-x86_64
    sudo ln -s mysql-5.5.20-linux2.6-x86_64 mysql
    sudo mysql/scripts/mysql_install_db –user=mysql

    If you do this procedure, make sure you’re then running the correct MySQL and are using the correct plugin directory. It will most likely change.

    Let me know if this helps, the rest of the config should be more or less same as before.

    Thread Starter DeeJay176

    (@deejay176)

    mysql> install plugin clouse soname ‘ha_clouse-5.5.20.so’;
    ERROR 1126 (HY000): Can’t open shared library ‘/usr/lib64/mysql/plugin/ha_clouse-5.5.20.so’ (errno: 2 undefined symbol: my_pthread_fastmutex_init)

    Still get this after following your instructions to the letter except for 1 step. Step #9 required I cd into the mysql directory and execute the command from there (omitting the mysql/)

    All steps worked up until the plugin install.

    Thread Starter DeeJay176

    (@deejay176)

    Thank you Artem I will have a chance to try this over the weekend. I believe I used the standard yum install packages. Very much appreciated that you spent the time to do this. +1

    Thread Starter DeeJay176

    (@deejay176)

    I tried the 1.0b.1.0 version as well, same error, my_pthread_fast_mutex_init error when trying to install the plugin for MySQL.

    Oblaksoft offers an ami binary with ClouSE already installed, but how could I know that configuration? In other words, when I build a server instance, I know everything I’ve loaded and every tweak I’ve made. How can I ensure that the ami from this group is in the proper condition for a production site? Does the fact that amazon stores the ami lend credibility to it?

    Thread Starter DeeJay176

    (@deejay176)

    mysql> install plugin clouse soname ‘ha_clouse-5.5.20.so’;
    ERROR 1126 (HY000): Can’t open shared library ‘/usr/lib64/mysql/plugin/ha_clouse-5.5.20.so’ (errno: 13 undefined symbol: my_pthread_fastmutex_init)

    This is a more detailed error message (the original got cut off)

    I was thinking of trying an earlier version of the x64 linux binary

Viewing 15 replies - 1 through 15 (of 17 total)