Plugin Author
pepe
(@pputzer)
When does that happen (frontend or backend)? What version did you update from? Also, which option values exactly?
Plugin Author
pepe
(@pputzer)
Hi @jerzyk! Is it possible that you upgraded from a really ancient version? I assume you are seeng calls for the option name typo_cache_keys. This behavior has not changes since version 3.something. However, I do see a way to reduce the number of option updates (which might help very busy with or resource starved sites).
Thread Starter
jerzyk
(@jerzyk)
actually not, site was kept up-to-date, there was a latest (pre-5) version of the plugin, all the problems started after upgrade to 5.x
Plugin Author
pepe
(@pputzer)
@jerzyk, can you tell me which option names you see in your DB logs?
There has been one change in 4.2.2 (the last version before 5.x) that might have a bearing on this, but it’s really weird because the options logic has otherweise not been changed in a very long time.
Thread Starter
jerzyk
(@jerzyk)
At the moment plugin is disabled and will not be enabled on this site as it must stay operatinal. The only thing I’ve got for you is from my diagnostics, but those partial SQLs:
---TRANSACTION 44220701, ACTIVE 22 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 226, OS thread handle 140421858178816, query id 7812 10.80.10.2 wawawp updating
UPDATE <code>wp_options</code> SET <code>option_value</code> = 'a:136403:{s:54:\"typo_CbNJ9z8M7/cynkWgE05WbKb7m3Jc+hJOIvTizr2HfcY=ftE@@\";b:1;s:54:\"typo_X3ZMskpLYi4WYT/Xh/4B26b7m3Jc+hJOIvTizr2HfcY=fsE@@\";b:1;s:53:\"typo_nju+Flcm4XnGY9sDp8ciMKb7m3Jc+hJOIvTizr2HfcY=tE@@\";b:1;s:53:\"typo_M5QyMz9hL8K/33y/XVLKLab7m3Jc+hJOIvTizr2HfcY=tE@@\";b:1;s:53:\"typo_obzHp1wY/3YwZYTvtfdOMKb7m3Jc+hJOIvTizr2HfcY=tE@@\";b:1;s:53:\"typo_1B2M2Y8AsgTpgAmY7PhCfqb7m3Jc+hJOIvTizr2HfcY=tE@@\";b:1;s:53:\"typo_vJZIFLkzTDFBldKMNoblpab7m3Jc+hJOIvTizr2HfcY=tE@@\";b:1;s:53:\"typo_1UURBoFdhVFMXgYHNmkEQqb7m3Jc+hJOIvTizr2HfcY=tE@@\";b:1;s:53:\"typ
------- TRX HAS BEEN WAITING 22 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 174 page no 22 n bits 480 index option_name of table <code>wawawp</code>.<code>wp_options</code> trx id 44220701 lock_mode X locks rec but not gap waiting
Record lock, heap no 261 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 15; hex 7479706f5f63616368655f6b657973; asc typo_cache_keys;;
1: len 8; hex 0000000000026368; asc ch;;
Plugin Author
pepe
(@pputzer)
@jerzyk: That looks like it’s it might be related to the in 4.2.2. I think I might be able to do a quick fix that would reduce the update calls to one per request (when new cache entries are generated). Would that help for your situation? (I have a more thorough solution in mind, but that will take some more work and testing.)
Thread Starter
jerzyk
(@jerzyk)
it will be a partial solution, in my opinion writing to the database on each page view is a huge price – busy sites without cache will be killed
maybe it will be better to set those caches on post/page save?
and if you are writing cache to the one single option – maybe it will be better to store data somewhere else:
– post options (then you eliminate deadlocks)
– memcache/redis – you gain some speed?
Plugin Author
pepe
(@pputzer)
@jerzyk, there won’t be a DB write on each page view if no new cache entries are generated. If you have five requests for the same page, only the first will generate a database write if neither the content nor the wp-Typography settings change between requests (caveat: this is assuming you have persistent object cache installed).
Basically, what you see is not the actual cache fragments being written but a single option that is used to store transient keys and cache keys so that they may be invalidated when you use “Clear Cache” in the settings menu.
Transients are used to store the PHP_Typography objects used for formatting, they will be only generated once, so after the first load, it does not matter. For content caching, the WordPress object cache is used. By default that’s per-request, but any host worth its salt should have a persistent object cache implementation (with APC, memcached or Redis as the backend) installed.
There is a more elegant solution for invalidating a group of cache keys, but that will necessitate some additional testing and it relies regarding garbage collection, it relies entirely on the backend.
-
This reply was modified 8 years, 8 months ago by
pepe.
Plugin Author
pepe
(@pputzer)
I’ve released 5.0.3 as an interim measure. Could you please try if that makes your site usable again (with wp-Typography enabled I mean)? Also, just to triage this correctly, do you have an object cache plugin (drop-in really) enabled? If so, which one? (If not, I highly recommend installing one for much improved WordPress performance.)
Thread Starter
jerzyk
(@jerzyk)
I have w3total cache with memcache and opcache. Will try to enable plugin overnight.
Thread Starter
jerzyk
(@jerzyk)
so far there are no problems with database, there are no pending transactions and no processes waiting for lock release. will be observing this closely – if there will be any issue, I’ll post update.
Plugin Author
pepe
(@pputzer)
@jerzyk: So everything went well so far? wp-Typography 5.1 will contain a revamped caching invalidation scheme that further reduces the number of update_option calls.
Plugin Author
pepe
(@pputzer)
@jerzyk: 5.1.x should work much better in this regard. Caching (including adding transients) is now done without writing the keys to the database.
