This issue is long overdue but...

Pantheon isn’t running WP LCache in production because we’ve discovered a problem with APCu’s memory allocation algorithm. If your configuration gets to a point where APCu is >95% full and heavily sharded, then APCu can cause your PHP processes to lock up and your web node to stop serving requests. This is a problem specific to APCu, and not LCache, so you could see it manifest with any APCu-based object cache drop-in.

[...]

At a high level, the memory allocation problem manifests itself when the APCu is heavily fragmented and close to full (> 99% utilization). It reproduces consistently if you can mock the environment correctly. The symptom of the issue is that PHP processes begin to lock up when APCu can no longer write new cache entries. One process locking causes all of the other processes to lock because APCu becomes inaccessible.

Here’s a script you can use to reproduce the issue in a test environment: https://gist.github.com/danielbachhuber/e0b39ae91a6a2b7ab79232df145f8b5a

From https://wordpress.org/support/topic/heavy-iops-and-database-use/

WordPress database error Specified key was too long; max key length is 1000 bytes for query CREATE TABLE IF NOT EXISTS

From https://wordpress.org/support/topic/lcache-database-tables-not-created/

When the plugin is active but object-cache.php isn't in place, we should alert the end user.

We look a bit bleak:

WP Redis is quite nice:

We can expose them in WordPress as cache groups. It should work similarly to how WP Redis has enabled cache groups.

In all my testing, the lcache_tags table appears to be unused.

Should it be removed from the project?

Seeing this with wp_debug set to on

Notice: Trying to get property of non-object in /var/www/woocommerce/wp-content/plugins/wp-lcache/vendor/lcache/lcache/src/APCuL1.php on line 43

On my site I benchmarked some object caches (median of ~500 continuous requests):

As you can see wp-lcache actually slows down.

And I benchmarked wp-lcache interface (single request):

I did not stick into the code. It looks like get() has a minimum latency during the request

PHP Version 7.0.23-1+ubuntu16.04.1+deb.sury.org+1

Is it wp-lcache or anything wrong with my APCu?

The query produces:

[Index column size too large. The maximum column size is 767 bytes.]

Including ROW_FORMAT=DYNAMIC in the query fixes the issue. We need to figure out whether this is safe to introduce in all queries, or whether it should be conditionally appended to the query.

On multisite, we need a table_prefix specific to the target site. The $table_prefix global is incorrect.

From lcache/lcache#85

Garbage collection: we need it.

Related lcache/lcache#11

Could you refer upstream and add this to the readme?

LCache is a module that applies the tiered caching model of multi-core processors (with local L1 and central L2 caches) to web applications. The current production implementation uses APCu as L1 and the database as L2.

It took me minutes to figure out what "L" cache is.

It seems that CLI mode is not recommended on production, and it's also disabled by default.

apc.enable_cli

Mostly for testing and debugging. Setting this enables APC for the CLI version of PHP. Under normal circumstances, it is not ideal to create, populate and destroy the APC cache on every CLI request, but for various test scenarios it is useful to be able to enable APC for the CLI version of PHP easily.

Yet enabling it is the only way to rid the WP LCache warning (#103):

Warning: Warning! Missing APCu extension enabled, which is required by WP LCache object cache. See "Installation" for more details: https://wordpress.org/plugins/wp-lcache/installation/

#We just tried out wp-lcache with our production sites and we noticed that it makes page loads 20-30% slower than without any object cache. Xdebug cachegrind profiles show that the time is spend in WP_Object_Cache->get_alloptions().

To test out I basically reverted PR #97 (Split alloptions into separate cache keys) and the issue goes away. Our page loads were 20-30% faster! It of course reintroduced the race condition bug which is not good.

Are you aware of this? I have an idea how to fix this. So if you are not working on it can work on it and send a PR with an alternative alloptions implementation with cachegrind profiling data backing it up.

Pinned in #116

PHP 7.0.17 and PHP 7.1.2 both cause inexplicable build failures: https://travis-ci.org/lcache/wp-lcache/builds/213057669

In 7.0.15, Composer's autoloader works and the LCache library is available. In 7.0.17, the LCache library is no longer available. I'm not sure at what point in the stack the LCache class isn't being loaded anymore though.

Might be related to: wp-cli/wp-cli#3888

Once PHP 7.0 decides to stop segfaulting, we should revert dd59326

We might want to make sure the tables are added with a prefix, to ensure two WordPress installs can share the same database.

Hi first of all thanks for open source this plugin.

I could use some help with troubleshooting activating this plugin on our WooCommerce site (nginx, php7.0, mysql 5.7, everything on AWS).

I've installed wp-lcache according to the installation guide (e.g. installed apcu, created object-cache.php file, activated the plugin). From what I can see the plugin is definitely running (no error message in backend).

Shortly after I've done above (3~5min), the website become unresponsive, even with low to moderate public traffic. Here are my observations when this happened:

• CPU load on web server (on php-fpm processes) is high but not too high to handle the traffic
• CPU load on mysql server (I'm on Amazon RDS, mysql 5.7) is stable to low
• DB connections on mysql server shoot thru the roof (connection increased from 3~5 to 200, probably capped by RDS itself)
• I can connect to the database via command line fine, the wp_lcache_tags table is empty, and wp_lcache_events table has around 37k rows in about 5min after activated the plugin
• Here is the screenshot of the database server load around the time I tried to activate the plugin:
  

I rebooted the database server, again the db connection shoot up (this time capped at 100) but still unresponsive.

I removed the object-cache.php and rebooted both web and db server, everything went back to normal.

With redis backed object caching plugins having various problems, I'd really like to take the advantage that this plugin offers, but I'm not sure what exactly is causing this problem. My best guess is wp-lcache tries to "warm up" its cache table but due to the amount of data we have (again, WooCommerce site, with about 4000+ products, 40k+ orders, 25k+ media files and negligible amount of posts/pages), the plugin caused some problem with database and made the whole website unresponsive.

Any suggestions on how to pin down the problem?

If you deploy this plugin to a new environment, it will come inclusive of the object-cache.php symlink, but it will not be enabled in that new environment. This can cause a flood of errors about the LCache DB table not existing. We should handle this gracefully with a nice admin message.

Kind of the inverse of #50

Currently blocked by pantheon-systems/terminus#1219

Previously #73

Renaming object-cache.php resolves the issue.

Nothing is visible in error logs or mysql.err. How would you recommend I debug this?

I've had one issue with wp-lcache before, where had to fine tune innodb_data_file_path = ibdata1:10M:autoextend:max:512M where max:128M had to be increased to max:512M. Not sure if related.

Other subsites load fine.

EDIT restarting php-fpm resolved the deadlock. But why would this happen? Before restart:

$ [-] wp cache flush
Error: One or more database tables are unavailable. The database may need to be repaired.

EDIT I also now updated pecl-apcu-5.1.5 -> 5.1.7. Maybe some bug involved there. Will monitor for future re-occurrence.

From #89

We should make sure the tables are truncated, and APCu is emptied, just to be safe.

Similar to #52

I think it would be swell to see your LCache hits/misses/calls from inside Query Monitor:

See output of $GLOBALS['wp_object_cache]->stats();

This will need to be done on WP Cron.

From lcache/lcache#11

Hello, I get a Missing APCU extension enabled and I have the extension enabled.

wp plugin activate wp-lcache
Warning: Warning! Missing APCu extension enabled, which is required by WP LCache object cache. See "Installation" for more details: https://wordpress.org/plugins/wp-lcache/installation/
Success: Plugin 'wp-lcache' activated.

I am on shared hosting and I can active apcu extension in cpanel. I tried with php5.6 and php 7.0 . I get the same warning message.
Note : I have access to server with ssh, I can use php cli and composer but no root. I use wordpress under bedrock from roots

Any idea ?

Here is phpconfig output :

In my phpconfig() I have for php 5.4 :

apc

APC support | Emulated

apcu

In my phpconfig() I have for php 7.0

PHP Version => 7.0.12

apcu

I'm experimenting with LCache on our high traffic site. This is either a question or a feature request.

Are there any performance gains when using igbinary as the APCu serializer? It is easy to install and enable igbinary in place of the PHP serializer. However, when I did so, it brought the database server to its knees with 100% CPU usage.

In theory, igbinary should improve performance and lower memory usage, though I'm not familiar enough with APCu to know how it stores/compacts cached keys.

Curious to know if anyone has tried this configuration.

Related to #62 - user reported doing cache flush as part of their debugging process and not having success until they directly dumped APCu cache from apc.php.

We should validate that we are correctly dumping all caches on the cache_flush or reset_cache action.

We should run the test suite against just the L2 cache, to ensure it behaves in the same way as the L1 cache.

There was a problem reported on a php 7 site using this module related to the port specification for the PDO constructor.

The Mysql PDO constructor documentation doesn't appear to say anything about requirements changes for php 7.

Related to https://github.com/pantheon-cookbooks/drush/pull/32

I'm switching some repos to use Terminus 1 to serve as examples for the forthcoming launch of Terminus 1.

Working list of tasks to complete:

• Mention plugin activation (for db table creation) before symlinking.
• Mention required PHP version 5.6

When the plugin is active, we should include an APCu status page in the WordPress admin so the end user easily knows whether the plugin is working or not.

From https://wordpress.org/support/topic/how-install-how-i-know-its-working/

Because LCache requires PHP 5.5 or greater, we should warn the end user when they aren't running the minimum required PHP version.

• Set STRICT_ALL_TABLES #67
• Use LONGBLOB column type for lcache_event values #66

Hello,
I just managed to install the plugin and tested the speed to see if it works.
I desactive cloudflare and run the tests on www.webpagetest.org .
When the plugin is not active the first bite takes 0.220s
When the plugin is enabled, the first bite takes 0.799s
I don't know why ..

First Byte Time:

• Applicable Objects : Time to First Byte for the page (back-end processing + redirects)
• What is checked : The target time is the time needed for the DNS, socket and SSL negotiations + 100ms. A single letter grade will be deducted for every 100ms beyond the target.

Please note that I use bedrock wordpress boilerplate and it has different directory structure than normal wordpress installation.
So the path in object-cache.php :
$lcache_path = dirname( realpath( __FILE__ ) ) . '../../app/plugins/wp-lcache/object-cache.php';

If you need more info, please let me know.

See lcache/lcache#14

This work can follow pantheon-systems/solr-power#15

Just like we have for the other Pantheon plugins, we should integration tests against Pantheon.

• Set up Circle CI (Steve Persch will make Pantheon test user/site, Terminus Token, SSH keys, etc)
• Run plugin specific tests
• Run upstream tests (See https://github.com/pantheon-systems/solr-power/pull/107/files for an example)

@danielbachhuber any objection to me moving this repo now?

In Circle or Travis.

Report from the field that a user was locked out of wp-admin when performing the core update. It would say "you need to update your db", which would succeed, but then the users were bounced to the homepage. Returning to wp-admin bounced them to the same warning about needing to run the database updates.

The eventual solution was to flush apc via apc.php.

We should see if this is replicable.

Follow up from #8

The following no longer works because Terminus now returns 0 for logged out too:

terminus whoami > /dev/null
if [ $? -ne 0 ]; then
	echo "Terminus unauthenticated; assuming unauthenticated build"
	exit 0
fi

@greg-1-anderson @stevector Suggestions on what we might be able to use instead?

From #115 (comment)

We should make sure synchronization works as expected.

Great idea on using a high speed APCu L1 cache with a shared L2 cache, but I think your choice of MySQL for L2 IS suboptimal. Of all the datastores in our server stack, MySQL is by far the slowest and has the highest latency.

Wouldn't it make more sense to use Redis, Memcache, or the like for the L2 cache? You'd get all the benefits of a shared L2 cache but at a much lower latency and a higher speed. You'd also avoid gunking up your database or slowing down other database transactions while warming the L1 cache(s).

When LCache is available, wp_cache_delete_group() currently always returns true, even when the group doesn't exist. It would be more correct for this function to return false when the group doesn't exist. However, this would require an API improvement to the LCache library.

daniel [12:40] when I call LCacheIntegrated->delete( LCacheAddress( 'foo', null ) );, I always get true, regardless of whether the bin exists
[12:41] Redis supports returning false when the hash doesn't exist
[12:41] does that seem possible to implement?
dts [12:42 PM] That's pretty hard to implement.
[12:42] There's no stable concept of a bin existing in LCache.
[12:42] What does a memcached cache for WP do?
[12:43](Which would have a similar issue, I'd imagine.)
danielbachhuber [12:43 PM] no group concept in memcached as far as I'm aware of
[12:43] everything ends up in memcached as key:group
dts [12:43 PM] Hmm. Is it a problem if we just do what we would do if the bin is assumed to exist?
danielbachhuber [12:44 PM] certainly not a huge problem
dts [12:44 PM] I mean, there's no operation to create a bin, so I'm not sure what would be necessary if, say, a bin didn't exist.
danielbachhuber [12:44 PM] I'll file an issue as a bug for now, and we can decide later whether it's wontfix

From #15

When we're displaying an admin notice to the end user, we should link to the installation documentation on the WordPress.org repo to ensure they know where to find an answer: https://wordpress.org/plugins/wp-lcache/installation/

LCache has currently been committed directly to lib. Instead, we should use Composer to incorporate the library.

Fatal error: Uncaught PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column ‘address’ at row 1 in /srv/bindings/e39874a9dbab0539/code/wp-content/plugins/wp-lcache/vendor/lcache/lcache/src/DatabaseL2.php:242 Stack trace: #0 /srv/bindings/e39874a9dbab0539/code/wp-content/plugins/wp-lcache/vendor/lcache/lcache/src/DatabaseL2.php(242): PDOStatement->execute() #1 /srv/bindings/e39874a9dbab0539/code/wp-content/plugins/wp-lcache/vendor/lcache/lcache/src/Integrated.php(56): LCache\DatabaseL2->set(‘10.223.192.153:…’, Object(LCache\Address), ‘s:25851:”a:12:{…’, 1486928148, Array) #2 /srv/bindings/e39874a9dbab0539/code/wp-content/plugins/wp-lcache/object-cache.php(1001): LCache\Integrated->set(Object(LCache\Address), ‘a:12:{i:0;O:8:”…’, 300) #3 /srv/bindings/e39874a9dbab0539/code/wp-content/plugins/wp-lcache/object-cache.php(710): WP_Object_Cache->call_lcache(‘set’, Array, ‘a:12:{i:0;O:8:”…’, 300) #4 /srv/bind in /srv/bindings/e39874a9dbab0539/code/wp-content/plugins/wp-lcache/vendor/lcache/lcache/src/DatabaseL2.php on line 242

Problem: address column is too short for the data being inserted.

From https://wordpress.org/support/topic/error-with-formidable-forms/