WARNING: This article may be obsoleteThis post was published in 2022-07-29. Obviously, expired content is less useful to users if it has already pasted its expiration date.
This article is categorized as "Garbage" . It should NEVER be appeared in your search engine's results.Table of Contents
结论（2022）
本测试基于Wordpress 6.0版本。
据Wordpress官方更新日志，Wordpress 6.1对object cache进行了重大优化和改革，有机会用6.1版本再测试一次，希望能得到更好的结果。
preload.py：🔗 [Wordpress cache preload code (python3) - Truxton's blog] https://truxton2blog.com/wordpress-cache-preload-code-example-python3/
没有任何新发现，都是老一套结论，浪费时间。
最终结论：
unix socket > TCP
redis > memcached
任何配置下打开mariadb query cache都会获得显著性能提升
使用redis/memcached的目的是 彻底关闭mariadb query cache ，但目前看来query cache是不可取代的，而redis/memcached是可有可无的（甚至拖后腿）
仅就我的情况而言，单独用mariadb query cache依旧是最优选择
使用插件：🔗 [Memcached Object Cache – WordPress plugin | WordPress.org] https://wordpress.org/plugins/memcached/
🔗 [Redis Object Cache – WordPress plugin | WordPress.org] https://wordpress.org/plugins/redis-cache/
memcached和redis（以及对应的php扩展）均使用最新版
测试（2022）
以下测试结果的数据均为 preload.py生成全站缓存所用的时间 ：
memcached unix socket + mariadb query cache(30M，没有low mem prune)
50.051682233810425
48.17083978652954
49.513153076171875
48.38247299194336
50.81668043136597
49.70982003211975
51.675721406936646
48.566386461257935
50.013890981674194
57.27725839614868memcached tcp + mariadb query cache(30M，没有low mem prune)
53.50589871406555
49.81916403770447
49.97934412956238
50.32324004173279
50.68235182762146
50.06493282318115
49.184303522109985
51.466094970703125
51.914294481277466
58.447693824768066暂时认定unix socket比tcp略快
memcached unix socket + mariadb NO query cache
55.20757818222046
56.35809111595154
58.02772378921509
57.575324296951294
56.81274151802063
56.385968923568726
56.41894745826721
57.627382040023804
55.88711881637573
57.54135322570801没有memcached + mariadb query cache(30M，没有low mem prune)
50.708728551864624
49.15826058387756
46.52391004562378
49.56967067718506
49.25907278060913
45.579962491989136
44.21191620826721
43.60449290275574
43.39982509613037
47.492321252822876接下来跑redis
值得注意的是，memcached和redis对 sql query count 的优化次数都是一样多的：
同一篇文章：https://truxton2blog.com/til-some-dns-server-block-macos-update/
不使用memcached、不使用redis：137次查询
使用memcached：第一次访问48次查询，第二次以及后续访问：33次查询
使用redis：第一次访问48次查询，第二次以及后续访问：33次查询
redis TCP + mariadb query cache(30M，没有low mem prune)
48.82993817329407
46.60698747634888
48.296932220458984
49.24925637245178
49.50781774520874
48.63967180252075
47.0571084022522
46.15655279159546
46.55781531333923
54.488096952438354redis unix socket + mariadb query cache(30M，没有low mem prune)
45.039599657058716
45.887028217315674
46.18762993812561
46.953168869018555
45.16604256629944
46.09203600883484
45.67312240600586
48.60983467102051
49.50845718383789
53.14913535118103还是老样子，unix socket比tcp快
redis unix socket + NO mariadb query cache
53.44927668571472
54.32791805267334
52.92724108695984
54.29958701133728
54.221851110458374
53.66926622390747
52.70887351036072
51.90546107292175
53.462000131607056
52.93445682525635还是相同结论，sql query cache是一定要用的
最后再跑一遍mariadb query cache（不用memcached，不用redis）
46.85679817199707
45.553794622421265
46.1456573009491
46.048454999923706
45.9069037437439
46.62075090408325
46.60566449165344
46.886351108551025
46.44221019744873
47.79344296455383新想法（2024）
随着本站发表文章的越来越多，想要在preload过程中不触发low memory prune就要是不是提高query cache size. 从2022年到2024年，query cache size从30M提升到40M，然后又提升到50M.
突然就想到一个问题：实际上在preload的过程中，占用query cache的大头是整篇文章内容的LONGTEXT，这些LONGTEXT内容只会query一次。而那些对preload性能有帮助的（我推测应该是那些category/tag/metadata）占用query cache的空间应该很小。干脆把当前的50M query cache size一次性减到10M怎么样？
开始实验！这是修改10M设置前的最后5次preload（也就是50M query cache size），以及preload结束时的query cache占用
66.82394194602966 36.06MB / 50MB
65.47529435157776 36.41MB / 50MB
65.37553787231445 35.91MB / 50MB
65.32917189598083 35.68MB / 50MB
66.02449083328247 35.63MB / 50MB这是开启后的几次preload：
64.5185534954071 8.86MB / 10MB
65.458651304245 8.65MB / 10MB
65.25190711021423 8.84MB / 10MB
67.59903907775879 8.85MB / 10MB
66.17681455612183 8.84MB / 10MB当然我又开始手痒了，看看设置为1M会怎么样（就跑了一次）：
68.87241983413696 0.38MB / 1MB然后索性再看看query cache size = 0:
77.7976644039154 0MB / 0MB没了。结果也挺符合我的预期：
- query cache size一定要>0
- query cache size在>0的基础上：设置为1M, 10M, 30M, 40M, 50M的差别不是很大（或者说基本没区别，因为preload.py本身就有2~3秒的运行时间误差）
但到了最后query cache size又设置回了50M，原因是---服务器分配的内存完全没必要在这几十MB上面纠结。
