Hope you are doing well.
MWG will only cache items under specific circumstances, the following at a minimum are required:-
-Response MUST contain at least one of the three header types: Cache-control, Expires or ETag
Yes caching of an object depends on server side.
Unfortunately their is no way to see contents of web cache partition at this moment .It's handled automatically by MWG. Currently there is no way the customer can influence it.
It is also to inform you that we also have a feature request regarding the same for viewing contents of web cache and deleting particular contents of web cache as per requirement.
This will be implemented in future releases MWG versions as per the decision taken by our product management team.
If I am not wrong in version 7.7.x support for caching of HTTPS traffic is available. You can check if the response delivered to client from MWG has TCP_HIT which means content is delivered from cache ( Example :- X-Cache: HIT from 10.54.173.220 can be seen in response being delievered to client) and if you see TCP_MISS which means content is not delivered from cache.
MWG's web cache (if enabled) will write all content to the cache that is "cacheable", i.e., HTTP headers do allow caching, the request does not contain URL parameters, etc.
If you want to use advanced criteria (e.g. media type, size, url), use the policy rules to enable cache only for some requests.
Disk writing is done by OS, we currently use the deadline scheduler of Linux in MLOS.
The cache cleanup process is more advanced:
- if cache partition usage is < 70% => do not delete anything
- if usage is > 70%, read last usage of entries, for each chunk of found entries, remove the oldest ones.
As this strategy might be too slow for deletion in high performance environments, two addition strategies are applied:-
First, if cache usage is between 70% and 80%, we will bypass cache stores with probability 0-100% to prevent disk-full.
Second, if disk usage is too high, we will not look at least recently used time anymore, but just delete all entries we found.
This might look strange, but if you have millions of entries and delete some of them chosen uniformly at random, it is unlikely that you delete entries that were used recently.
Furthermore, we have some bypass options for the Web Cache if the IO load is too high, e.g., we limit the number of working threads doing IO simultaneously.