I have been organizing the WordPress server environment recently.
The website homepage previously experienced obvious dynamic response performance issues. The related troubleshooting and optimization process has been documented separately:
After resolving the issue, I went through the main performance configurations of the current server from start to finish. I wanted to confirm which parameters actually needed adjustment, which were already reasonably set, and which issues should be left as-is for observation.
The main runtime environment of the website currently includes:
- WordPress 7.0.3
- Twenty Twenty-Five 1.5
- Nginx 1.30.4
- PHP 8.5.9
- Redis 8.10.0
- MySQL 5.7.32-log
- Alibaba Cloud RDS
- Alibaba Cloud ECS
- 2 CPU cores
- Approx. 3.6 GiB memory
- 2 GiB Swap
- Chinese site uses EdgeOne
- English site uses Cloudflare
This time, I mainly checked Nginx, PHP-FPM, OPcache, Redis, W3 Total Cache, RDS / MySQL, and the WordPress application layer.
In the end, not many parameters were actually modified.
Although many configurations initially seemed to have room for adjustment, after further cross-referencing with logs, memory, cache hit rates, and actual load, I ultimately decided to keep them as they were.
1. Nginx: Overall configuration is healthy
The current main Nginx parameters include:
worker_processes auto
worker_connections 51200
worker_rlimit_nofile 51200
sendfile on
tcp_nopush on
tcp_nodelay on
keepalive_timeout 120
Based on the current server load, connections, and file descriptor limits, no obvious bottlenecks were found.
Therefore, these parameters remain unchanged.
No additional rate limiting enabled at the origin for now
The Nginx global configuration already defines rate limiting zones, such as:
limit_req_zone
limit_conn_zone
However, the frontend site does not currently have the corresponding rate limiting rules actually enabled.
The Chinese site already has EdgeOne in front, and the English site has Cloudflare in front, while the origin server has not yet fully restored the real visitor IPs behind the CDN.
If rate limiting were applied directly based on the source IPs currently seen by Nginx, it might end up limiting CDN nodes rather than actual end visitors.
Therefore, the current approach remains:
- EdgeOne handles frontend protection and rate limiting for the Chinese site;
- Cloudflare handles frontend protection and rate limiting for the English site;
- The origin Nginx does not add a redundant set of rate limiting rules based on the current source IPs.
2. PHP-FPM: pm.max_children=10 has hit an actual bottleneck
The original PHP-FPM configuration was:
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 500
The PHP-FPM logs have repeatedly shown:
server reached pm.max_children setting (10)
This indicates that during certain periods, all 10 PHP-FPM worker processes were indeed occupied.
Further inspection of the access logs at that time revealed numerous requests from search engine and SEO crawlers, including:
- Sogou
- Bingbot
- Googlebot
- AhrefsBot
- MJ12bot
Meanwhile, I am currently batch processing historical articles via SlyTranslate.
Some AI translation requests can last for tens of seconds or even minutes, occupying PHP-FPM worker processes for extended periods during execution.
Ultimately, the configuration was adjusted to:
pm = dynamic
pm.max_children = 14
pm.start_servers = 3
pm.min_spare_servers = 3
pm.max_spare_servers = 6
pm.max_requests = 500
Why increase only to 14?
This ECS instance has a total memory of only about 3.6 GiB.
Redis itself has long been using around 800 MiB of memory, and a single PHP-FPM worker process actually consumes about 100 MiB.
Therefore, I did not directly increase:
pm.max_children
to 20 or 30, but instead first increased it from:
10
to:
14
After the modification, the server memory status is:
Total memory: approx. 3.6 GiB
Used: approx. 1.2 GiB
Available: approx. 2.1 GiB
Swap:
Total approx. 2.0 GiB
Used approx. 54 MiB
There is currently no obvious memory pressure.
Therefore:
pm.max_children = 14
This serves as the new operational baseline for now.
If the following occurs frequently in the future:
server reached pm.max_children setting (14)
and there is still enough available memory at that time, I will consider increasing it further.
3. PHP-FPM slow log remains at 3 seconds
PHP-FPM is currently also configured with:
request_slowlog_timeout = 3s
AI translation of historical articles itself may run for a minute or two, so the slow log frequently shows:
- SlyTranslate
- WordPress AI Client
curl_exec()- External AI API requests
These long-running requests do not necessarily indicate a performance anomaly in the WordPress pages themselves.
However, I ultimately did not raise the slow log threshold to 60 seconds or even 120 seconds just to reduce these entries.
The reason is:
The more important role of the slow log is to promptly detect ordinary web requests that should not be slow.
If the threshold were raised to 120 seconds, then an ordinary WordPress request that suddenly takes 5, 10, or even 20 seconds to complete would not be logged either.
Therefore, the following remains unchanged:
request_slowlog_timeout = 3s
When encountering slow log entries that clearly belong to AI translation in the future, I can directly determine them as expected behavior based on the call stack.
4. OPcache: Running state is very good, but memory was reallocated
After checking the OPcache actually used by PHP-FPM, I found:
OPcache hit rate: approx. 99.997%
Cached PHP scripts: approx. 2982
Restarts: 0
This indicates that OPcache itself does not have obvious capacity issues or frequent invalidations.
The original main configuration was:
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=100000
opcache.jit=0
The runtime status showed:
- Regular OPcache was using about 93 MiB;
- Interned Strings usage was close to 89%;
- JIT was actually disabled.
However, under the current runtime state of PHP 8.5, even if:
opcache.jit=0
the JIT Buffer still has a default space of about 64 MiB.
For this WordPress website, the main overhead comes more from:
- Database;
- Redis;
- WordPress plugins;
- Network I/O;
- External APIs.
There is no obvious CPU-intensive PHP computation scenario, so there is currently no practical need to enable JIT.
Ultimately, it was modified to:
opcache.memory_consumption=192
opcache.interned_strings_buffer=32
opcache.jit=0
opcache.jit_buffer_size=0
While continuing to keep:
opcache.max_accelerated_files=100000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
After the modification, the actual loaded values for PHP-FPM were also confirmed to have changed to:
opcache.interned_strings_buffer => 32
opcache.jit => 0
opcache.jit_buffer_size => 0
opcache.memory_consumption => 192
The focus of this adjustment was not to expect a noticeable single-request performance boost for WordPress, but rather to:
Disable the currently useless JIT Buffer, while allocating more ample long-term space for regular OPcache and Interned Strings.
5. Redis: Current metrics are excellent, so it remains unchanged
Redis currently primarily handles the WordPress object cache.
The actual memory usage at the time was roughly:
Used: approx. 810 MiB
RSS: approx. 826 MiB
Peak: approx. 884 MiB
Main configuration:
maxmemory = 1G
maxmemory-policy = allkeys-lru
Persistence is disabled:
AOF: Disabled
RDB auto-save: Disabled
This is because Redis is currently used primarily as a cache, rather than for storing business data that must be persisted long-term.
Long-term metrics are approximately:
Cache hit rate: approx. 99.05%
Cache evictions: 0
Rejected connections: 0
The memory fragmentation rate is approximately:
1.02
Based on these figures, the current Redis state is very healthy.
Therefore, I did not adjust:
maxmemory = 1G
I neither increased it to 1.5 GiB just because over 800 MiB was already in use, nor decreased it to 512 MiB to save ECS memory.
The current 1 GiB:
- Has not experienced cache evictions;
- Still has some room for growth;
- Is still acceptable for the total memory of the current server.
So it remains unchanged.
6. W3 Total Cache: Keeping current parameters for now
Upon further inspection of W3 Total Cache, the total size of the disk cache directory reached approximately:
1.5 GiB
Of which:
page_enhanced approx. 1.4 GiB
object approx. 104 MiB
db approx. 20 KiB
Historical disk object cache
cache/object/ still has about:
104 MiB
However, the timestamp of the latest file has remained stalled in May 2026.
The object cache currently in actual use is already Redis, so this part can basically be judged as residual historical disk cache.
Historical database cache
cache/db/ currently has no actual valid cache files.
The W3TC database cache has also been disabled.
There is likewise no need to process this part right now.
Large amount of _old page cache
What is truly worth noting is:
cache/page_enhanced/
After further statistics, it is approximately:
Current valid page cache: approx. 133 MiB
_old old cache: approx. 1.25 GiB
The current page cache is roughly configured as:
Page cache lifetime: 4 days
Garbage collection cycle: 3600 seconds
Cache preloading: Enabled
Preload 7 URLs every 300 seconds
The website is currently undergoing continuous batch modifications to a large number of historical articles.
The article update process itself may continuously cause:
- Homepage cache invalidation;
- Category page cache invalidation;
- Tag page cache invalidation;
- Article page cache invalidation;
- Related page cache regeneration.
Therefore, it is temporarily impossible to determine whether the current large number of _old files actually belong to:
- Normal results of batch updates to historical articles;
- A temporary state produced by the page cache clearing mechanism;
- Or a genuine long-term anomaly in W3TC garbage collection.
Currently, I have not modified:
- Page cache lifetime;
- Cache preloading;
- Page cache clearing rules;
- Garbage collection parameters.
After all historical articles have been processed, I will let the website run normally for 24 to 48 hours, and then re-observe the page cache and _old file changes.
7. Alibaba Cloud RDS: Most MySQL parameters are already quite healthy
The current total size of the WordPress database is approximately:
830.80 MiB
The main tables include:
wp_posts approx. 497.80 MiB
wp_postmeta approx. 208.58 MiB
wp_post_views approx. 32.33 MiB
wp_options approx. 14.48 MiB
InnoDB Buffer Pool
Current configuration:
innodb_buffer_pool_size = 768M
The actual logical cache hit rate is approximately:
99.99987%
This indicates that the vast majority of data reads can be served directly from the InnoDB buffer pool.
Therefore, there is no need to increase 768 MiB further for now.
Max connections
Currently:
max_connections = 2532
This looks very large.
However, the historical actual maximum number of connections is only:
Max_used_connections = 29
At the time of inspection:
Threads_connected = 10
Threads_running = 1
In other words, database connections are not a bottleneck at all right now.
Although:
2532
is significantly higher than the current actual needs of the website, since it has not caused any actual resource issues, I did not adjust it just to make the parameter look “more reasonable”.
Thread Cache
The database has accumulated over 14 million connections over the long term, but only a few dozen new threads were actually created.
This indicates that:
thread_cache_size
is working very well.
Table Cache
The table cache has likewise not shown any overflow.
Therefore, the following parameters all remain unchanged:
- InnoDB Buffer Pool;
max_connections;thread_cache_size;table_open_cache;table_definition_cache;innodb_flush_log_at_trx_commit;innodb_flush_method;- Slow query log.
8. tmp_table_size=2M looks small, but was not directly increased
During the database inspection, one parameter that easily attracts attention is:
tmp_table_size = 2M
Meanwhile:
max_heap_table_size = 64M
In long-term statistics, the proportion of disk temporary tables is approximately:
27.43%
Looking solely at these numbers, it is easy to directly conclude:
tmp_table_size=2Mis too small.
And then adjust it to:
16M
32M
64M
However, whether MySQL creates disk temporary tables is not entirely determined by this parameter.
When a query involves certain field types, grouping methods, and sorting structures, even increasing:
tmp_table_size
may not necessarily avoid disk temporary tables.
Therefore, I did not modify the parameter solely based on the:
27.43%
ratio.
For now, the following remains unchanged:
tmp_table_size = 2M
If slow query logs clearly show in the future that a large number of actual slow queries are indeed affected by the memory temporary table limit, I will make targeted adjustments then.
9. wp_options is 14 MiB, but the actually autoloaded data is not large
The total size of the wp_options table is approximately:
14.48 MiB
After further breaking down the different autoload statuses, it was found to be roughly:
autoload=off approx. 10.88 MiB
autoload=auto-off approx. 0.62 MiB
autoload=yes approx. 0.26 MiB
autoload=auto approx. 0.18 MiB
autoload=on approx. 0.07 MiB
In other words, the data that is actually autoloaded with WordPress requests is only about:
0.5 MiB
This size is not large.
The Options taking up more space mainly belong to:
- Transients;
- Site Transients;
- Feed cache;
- Remote data cache;
- Plugin temporary data.
Therefore, I did not manually delete a large amount of data just to shrink:
wp_options
directly.
10. Discovered that Gutenberg real-time collaboration was always enabled
During the database inspection, an unexpected situation was also discovered.
wp_postmeta contained a large amount of _crdt_document related data, totaling about 1,870 entries and taking up about 148.69 MiB of space; additionally, there was wp_sync_storage related data.
In the backend access logs, a large number of /wp-json/wp-sync/v1/updates requests could also be seen.
Upon further inspection of WordPress Settings → Writing, I found that Gutenberg’s Collaboration was always enabled.
This feature is part of Gutenberg’s real-time collaborative editing functionality.
However, this WordPress instance actually has only one user, so there is no need for multiple people to edit the same article simultaneously.
As a result, it was generating extra:
- Real-time collaboration REST API requests;
- PHP-FPM requests;
wp_sync_storagedata;_crdt_documentdata;
without bringing any actual benefit to the current use case.
Ultimately, it was disabled directly.
After disabling it, confirmation via WordPress functions showed:
Real-time collaboration: Disabled
The existing approximately:
149 MiB
of historical collaboration data was not deleted for now.
I will consider cleaning it up all at once after the processing of historical articles is completely finished.
11. Article revisions have already taken up about 262 MiB
After further breaking down wp_posts, I found:
revision 5514 entries approx. 262.45 MiB
post 2791 entries approx. 160.04 MiB
In other words, the content space occupied by article revisions has already exceeded that of officially published articles.
However, it is currently configured with:
WP_POST_REVISIONS = 3
So there is no issue of saving revisions indefinitely.
Moreover, a large number of historical articles are still being modified at this stage.
Retaining a certain number of revisions during this phase also adds a layer of recovery protection against accidental modifications.
Therefore, I did not clean them up immediately.
I will consider uniformly deleting old revision data after all historical articles have been processed.
12. WordPress cron task configuration is normal
WordPress is currently configured with:
DISABLE_WP_CRON = true
The server also has Linux Cron configured:
*/5 * * * * cd /data/wwwroot/www.shuijingwanwq.com && /usr/local/php/bin/php wp-cron.php >/dev/null 2>&1
This means:
Linux actively executes WordPress cron tasks once every 5 minutes.
This eliminates the need to rely on random visitor hits to trigger:
wp-cron.php
Further inspection of the current WordPress cron tasks showed:
Total cron tasks: 23
Different hooks: 23
No large number of plugin tasks executing every minute or every 5 minutes were found.
The shortest normal cycle currently is only:
Once per hour
Most others are:
- Every 12 hours;
- Daily;
- Weekly;
- Monthly.
Therefore, the following configurations remain unchanged:
DISABLE_WP_CRON = true
WP_POST_REVISIONS = 3
AUTOSAVE_INTERVAL = 60
EMPTY_TRASH_DAYS = 30
WP_MEMORY_LIMIT = 256M
WP_MAX_MEMORY_LIMIT = 512M
13. SlyTranslate debug log had grown to 864 MiB
Currently, for historical article translation and exception troubleshooting, the following are still retained:
WP_DEBUG = true
WP_DEBUG_DISPLAY = false
The debug log is written to:
wp-content/slytranslate-debug.log
Upon inspection, this file had grown to:
864 MiB
After further analyzing the latest 20,000 lines of the log, the vast majority of the content consisted of repeated PHP Notices, Deprecated messages, and command-line prompts.
These included:
- Nimble Page Builder;
- PublishPress Series;
- SyntaxHighlighter;
- Yoast SEO;
- Polylang;
- WP-CLI.
However, this part of the log contains a large amount of historical records.
The previous day, a focused troubleshooting session had already been conducted for plugin compatibility issues after the PHP 8.5 upgrade:
At that time, the following were respectively handled:
- Nimble Page Builder: Disabled;
- SyntaxHighlighter: Minimal local fix completed and verified;
- Yoast SEO: Could not be reliably reproduced on common production pages, so it was not modified;
- PublishPress Series: Compatibility issue confirmed, and feedback submitted upstream.
Therefore, a considerable portion of this 864 MiB log file is merely historical records accumulated during previous debugging, WP-CLI operations, and plugin compatibility troubleshooting.
What truly needs to be resolved now is:
The debug log has no size control and can grow indefinitely over time.
14. Adding log rotation for the SlyTranslate debug log
The processing of historical articles is not yet complete, so there is still a need to keep:
WP_DEBUG = true
Ultimately, instead of turning off debug mode directly, I added log rotation for:
slytranslate-debug.log
.
Current policy:
Rotate after file exceeds approx. 100 MiB
Keep 5 copies
Old logs automatically compressed
Additionally, via Linux Cron:
Check once per hour
The final generated log rotation configuration has successfully passed inspection.
Before the first execution of log rotation:
slytranslate-debug.log
864 MiB
After rotation:
slytranslate-debug.log
0
slytranslate-debug.log.1.gz
approx. 6.5 MiB
The 864 MiB plain text log was only about 6.5 MiB after compression.
This allows retaining debugging capability without worrying about the log growing indefinitely to several GiB.
After all historical articles have been processed, I will consider disabling:
WP_DEBUG
15. PublishPress Series PHP 8.5 warnings still appear
After a smooth reload of PHP-FPM, PHP 8.5 deprecation warnings for PublishPress Series can still be seen in the new logs:
SplObjectStorage::attach() is deprecated
SplObjectStorage::contains() is deprecated
This issue was previously confirmed, and feedback has been submitted to the plugin upstream.
Records of the related PHP 8.5 plugin compatibility troubleshooting:
For now, I will just wait for an upstream version fix.
16. Final modifications executed via uploaded script
When actually modifying PHP-FPM and OPcache this time, I also encountered an operational issue.
Initially, I planned to combine:
- Backup;
- Modification;
- Configuration check;
- Smooth reload;
- Log rotation;
- Final verification;
into one long Shell command and paste it directly into the SSH terminal for execution.
In practice, however, I found that pasting an overly long script directly into an interactive terminal is unreliable.
During one execution, the SSH session was directly terminated due to the Shell’s error exit behavior.
Fortunately, it was still in the configuration pre-check phase at the time, and PHP-FPM and OPcache had not actually been modified.
Later, I changed the approach to:
- First generate a
.shscript file; - Download it locally;
- Upload it to the server using
scp; - Then execute it from the server.
For example:
scp ~/下载/swq-final-tune-20260807-v2.sh aliyun:/root/
After uploading, execute:
chmod 700 /root/swq-final-tune-20260807-v2.sh
bash /root/swq-final-tune-20260807-v2.sh
The script will automatically complete:
- Checking PHP-FPM configuration;
- Checking OPcache configuration;
- Creating a pre-modification backup;
- Modifying PHP-FPM;
- Modifying OPcache;
- Configuring log rotation;
- Checking PHP-FPM configuration;
- Checking log rotation configuration;
- Smoothly reloading PHP-FPM;
- Verifying actual effective OPcache parameters;
- Checking server memory;
- Testing the dynamic homepages in both Chinese and English.
Final backup directory:
/root/swq-final-tune-backup-20260807-195609
Full execution log:
/root/swq-final-tune-20260807-195609.log
For server modification commands spanning dozens or even hundreds of lines, generating a script first and then uploading it for execution is clearly more reliable than pasting it directly into an interactive SSH terminal.
17. Main configurations after modification
PHP-FPM
pm = dynamic
pm.max_children = 14
pm.start_servers = 3
pm.min_spare_servers = 3
pm.max_spare_servers = 6
pm.max_requests = 500
The final modified values have been written to the configuration.
OPcache
opcache.memory_consumption=192
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=100000
opcache.jit=0
opcache.jit_buffer_size=0
opcache.validate_timestamps=1
opcache.revalidate_freq=60
The four parameters modified this time have successfully taken effect.
Redis
Continuing to keep:
maxmemory = 1G
maxmemory-policy = allkeys-lru
WordPress
Continuing to keep:
DISABLE_WP_CRON = true
WP_POST_REVISIONS = 3
AUTOSAVE_INTERVAL = 60
EMPTY_TRASH_DAYS = 30
WP_MEMORY_LIMIT = 256M
WP_MAX_MEMORY_LIMIT = 512M
Additionally, Gutenberg real-time collaboration has been disabled.
18. Dynamic page testing after modification
The final script also tested the dynamic homepage after bypassing the CDN and W3 Total Cache page cache.
Three tests for the Chinese site:
0.909243 seconds
1.175537 seconds
0.907528 seconds
English site:
1.008783 seconds
1.426391 seconds
1.155351 seconds
All returned:
HTTP 200
These tests were conducted immediately after the smooth reload of PHP-FPM.
Based on the results, dynamic requests are running normally after the PHP-FPM and OPcache parameter adjustments, with no abnormal responses or obvious performance degradation.
19. Configurations explicitly not modified this time
After completing the full inspection, a large number of parameters ultimately remained unchanged.
Nginx
Continuing to keep the current:
worker_processes;worker_connections;worker_rlimit_nofile;keepalive_timeout;- Main FastCGI parameters.
Frontend rate limiting continues to be handled by EdgeOne and Cloudflare.
Redis
Continuing to keep:
1 GiB
allkeys-lru
RDS / MySQL
Continuing to keep:
innodb_buffer_pool_size;max_connections;thread_cache_size;table_open_cache;table_definition_cache;innodb_flush_log_at_trx_commit;innodb_flush_method;tmp_table_size.
Among them:
tmp_table_size = 2M
Although it looks small, there is currently insufficient evidence to prove that increasing it would solve actual performance issues.
WordPress
Continuing to keep:
WP_POST_REVISIONS = 3
AUTOSAVE_INTERVAL = 60
EMPTY_TRASH_DAYS = 30
WP_MEMORY_LIMIT = 256M
WP_MAX_MEMORY_LIMIT = 512M
W3 Total Cache
Currently not modifying:
- Page cache lifetime;
- Page cache preloading;
- Page cache clearing rules;
- Garbage collection parameters.
I will re-observe these after the historical articles have been processed and the website has been running normally for a while.
20. Some data to be cleaned up later
There are still a few categories of data temporarily retained at present.
Gutenberg historical real-time collaboration data
Approximately:
149 MiB
Real-time collaboration has been disabled, but existing data such as _crdt_document is not being deleted for now.
WordPress historical revisions
Approximately:
262 MiB
The historical articles are still in the batch processing phase, so they are temporarily retained.
W3TC historical disk cache
Including:
cache/object/
cache/db/
To be processed alongside W3 Total Cache later.
WP_DEBUG
There is still a need for:
slytranslate-debug.log
to help troubleshoot historical article translation exceptions.
After all this work is finished, I will consider:
WP_DEBUG = false
21. Summary: Server tuning is not about changing every single parameter
After this complete inspection, the items actually modified mainly consist only of:
- Increasing PHP-FPM max worker processes from 10 to 14;
- Increasing PHP-FPM start worker processes from 2 to 3;
- Increasing min idle worker processes from 2 to 3;
- Increasing max idle worker processes from 4 to 6;
- Increasing OPcache memory from 128 MiB to 192 MiB;
- Increasing Interned Strings from 16 MiB to 32 MiB;
- Disabling the currently useless JIT Buffer;
- Disabling Gutenberg real-time collaboration;
- Adding log rotation for the SlyTranslate debug log.
On the other hand, many parameters that initially seemed like they “could be optimized” were ultimately not modified.
Including:
- Nginx worker process and connection parameters;
- Redis 1 GiB memory limit;
- RDS 768 MiB InnoDB Buffer Pool;
- MySQL max connections;
- MySQL thread cache;
- MySQL table cache;
tmp_table_size=2M;- WordPress revision count;
- WordPress autosave interval;
- W3 Total Cache page cache lifetime.
After this inspection, I increasingly feel that:
The most important aspect of server tuning is not finding how many parameters can be modified, but being able to judge which parameters have no need to be touched at all.
If a configuration has:
- Normal current runtime metrics;
- No corresponding error logs;
- No resource exhaustion;
- No clear slow queries;
- No actual performance bottlenecks;
then keeping it as is is a reasonable conclusion in itself.
Compared to blindly applying various so-called “best parameters” from the internet, deciding whether to make modifications based on your own server’s:
- Actual traffic;
- Memory usage;
- PHP-FPM logs;
- Redis hit rate;
- MySQL status;
- WordPress workload;
is obviously more reliable.
This current set of PHP-FPM, OPcache, Redis, RDS, and WordPress configurations will serve as the new operational baseline for now.
Later, I will only re-evaluate if similar situations occur, such as:
- PHP-FPM frequently hitting the 14 worker process limit again;
- A significant long-term increase in memory or Swap usage;
- Redis starting to experience cache evictions;
- A noticeable increase in RDS slow queries;
- Continued substantial growth in WordPress data scale;
- An ECS upgrade or change in server specifications;
- Re-auditing W3 Total Cache after the historical article migration is complete.
Before these conditions undergo significant changes, there is no need to repeatedly tinker with the server just to adjust a few parameters.