FastCGI Cache takes the rendered output of a page -- i.e. what you'd see when viewing the source of the page -- and caches it to a static file on disk, or, if configured, to RAM (
When a request comes through that matches the same URI, the cached page is served instead of the normal page that would be rendered by your script (i.e. WordPress).
Setting the cache to 100 MB isn't necessarily a bad thing -- it won't affect performance or change the way things work, it just tells NGINX that the max size that the cache can be is 100 MB.
That said, it'd take quite a few cached pages to total 100 MB. When you run tests to check the page size of your page, that's not the same size that's getting cached as NGINX isn't caching images and media to the cache. It's caching the rendered page output (which links to images, media, and assets, such as your CSS, JS, etc).
While your page size in those tests may be, for example, 1-2MB or more, you're cached page may only be a small fraction of that since all those other items are not cached by FastCGI Cache. Those items are cached by the users' browser(s).
Think of FastCGI Cache as turning a dynamic page that has to hit the database on each page load in to a basic HTML file. Performance is multitudes better when it comes to serving static content, which is why a dynamic page load of 1-2 seconds may be reduced to 1/10th of that when serving a static page.
In terms of how FastCGI handles objects that are expired, that all depends on what you have set in the configuration.
inactive defines the time it takes for an object to be removed from the cache after not being accessed for the defined time. If you set this to 30 minutes (for example), for an object to be removed from cache, it can not be accessed in that period of time. If an object is accessed between 1 second and 29 minutes and 59 seconds, it stays in the cache. This, of course, includes if you access it as FastCGI cache doesn't differentiate between you or a visitor, nor are the settings to configure such caching.
To actually purge the cache, you'd want to look in to
That defines a method that can be used to purge or flush the cache. Of course, you'd have to set up your own code to send a PURGE request
Of course, using just that configuration, anyone could send a PURGE request and clear your cache, so you'd need to do some level of verification to make sure the request is coming from a certain IP or locally.