Server maintenance questions.

[ddur]

1. Would it be more efficient to store cached responses as zip files? Either as zip of base64 encoded or (maybe more efficient) as a zip of raw response.

2. How many cached responses is too much? Do you need more than one cached response per plugin? How about automatically deleting expired caches?

3. request.log may become quite large even with humble number of clients. Is it possible to rotate logs like Linux OS does. In example, how about zipping current request.log weekly or monthly with year-week/month number and clearing current request log.

[YahnisElsts]

Are you talking about the existing cache which stores parsed plugin metadata, or about some theoretical new cache that would store cached responses?

request.log may become quite large even with humble number of clients. Is it possible to rotate logs like Linux OS does. In example, how about zipping current request.log weekly or monthly with year-week/month number and clearing current request log.

Log rotation is already implemented, but not enabled by default. You can enable it like this:

$updateServer->enableLogRotation(
    self::FILE_PER_MONTH, //One file per month.
    3                     //Keep the last 3 files.
);

[ddur]

Are you talking about the existing cache which stores parsed plugin metadata, or about some theoretical new cache that would store cached responses?

I'm talking about existing metadata in /cache sub-directory. I have 25 of them for single plugin.

Thanks.

[YahnisElsts]

There should be a new cache entry every time the plugin ZIP file is modified. This is usually, but not always, the same as "number of plugins" x "number of versions". Changing something in a ZIP file will produce a new cache file even if you don't change the version number.

It would be nice to automatically clean up old cache files, but that's currently not implemented. If necessary, it should be safe for you to delete all cache files (except .htaccess). The update server will automatically regenerate the cache for the current version when a new request comes in. I don't know how many files are too many; I haven't run into any issues with that in practice.

The purpose of the cache is to save time on having to parse plugin ZIP files, so I think that storing the cached data as ZIP files would somewhat defeat the point.

[ddur]

My guess was that using/sending cache.zip instead base-64.txt would improve server performance. I never meant parsing plugin again, only replacing cache storage format. Parsing & Caching (either as *txt or *.zip) is one time event, that will save server time on many get_metadata events.

Cached files are small, so that is no size issue, I just like not to waste storage by keeping useless data. 😎

🆗 👍 Thank You.