Hi apologies if this has been fixed in a recent version (we are a few behind in production).
On higher traffic production sites, we have been seeing spikes of high traffic directed at the Fishpig Wordpress endpoints briefly for under < 5 minutes at a time, multiple times per day. To note: We run the Wordpress instances on the sites isolated with low resources, since they are not public facing and only serve the fishpig blog.
The current theory for this is Fishpig cache is being lost due to cache lifetime, purge etc. Then a bunch of uncached requests are made consecutively, all triggering separate API requests due to the cache being empty at the time they came in. Once the first request completes and populates cache, the traffic spike subside. Although we still have a bunch of queued WP Api requests that was initiated before the cache was populated.
Potentially introducing some form of locking for the API requests, so that we don't issue duplicate requests.
Then delay the response of additional requests until the first request finishes and use that cached content. (Potential to speed up the following requests as they do not need to make their own HTTP requests now)
Or soft reject any new requests with a exception log message and disable the Fishpig functionality.
Hi apologies if this has been fixed in a recent version (we are a few behind in production).
On higher traffic production sites, we have been seeing spikes of high traffic directed at the Fishpig Wordpress endpoints briefly for under < 5 minutes at a time, multiple times per day. To note: We run the Wordpress instances on the sites isolated with low resources, since they are not public facing and only serve the fishpig blog.
The current theory for this is Fishpig cache is being lost due to cache lifetime, purge etc. Then a bunch of uncached requests are made consecutively, all triggering separate API requests due to the cache being empty at the time they came in. Once the first request completes and populates cache, the traffic spike subside. Although we still have a bunch of queued WP Api requests that was initiated before the cache was populated.
Potentially introducing some form of locking for the API requests, so that we don't issue duplicate requests.
Then delay the response of additional requests until the first request finishes and use that cached content. (Potential to speed up the following requests as they do not need to make their own HTTP requests now)
Or soft reject any new requests with a exception log message and disable the Fishpig functionality.