An engine X my Croque ASH is a symbol server side cash that allows us to store dynamic language responses
in order to avoid or at least minimize server side language processing for websites relying heavily
on server side languages and database access such as P. HP and miniscule.
This cash can provide incredible performance benefits and drastically reduce server load.
Simply put.
Then let's say a user makes a request for dynamic content engine X passes that request to be a b f be
m.
In our case which process is set and possibly even include some database queries here.
B f P. M. then returns their processed response to engine x most likely in the form of H.
Dear Mal at which point engine X using a micro cache can write that response to dusk meaning next time
a user makes the same request.
There's no need at all to even contest p p f p. m..
The response can be read from desk.
As with any other static ressource and sent to the client.
Of course it's not always going to be quite the straight forward as Dynamic Content is dynamic for a
reason but in this case and we'll see how to configure a micro cache for Patch be using engine X as
fast CGI cache as before.
I'll clear some of this previously since code remove all of the Jesus directives and the static ressource
location.
Implementing geezer then to an able and configure fast CGI caching in the htb context making this available
to all our server contexts.
Start by setting fast CGI cache path which as the name suggests takes a filesystem location to which
these cash increase can be written.
I prefer to use the slash TMB directory for this as it gets emptied on boot.
For most Linux distributions but feel free to create this cache elsewhere should you wish slash engine
X underscore cache.
Then on the same directive add a parameter called levels.
Setting that to one calon to like so now the levels parameter is a very poorly documented parameter.
But essentially what it allows us to configure is the depth of directory's to split the cash increase
in two.
If you leave this out engine X will simply write every cash entry directly to this cash path at the
rectory which is fine for smaller sites but setting that to this means storing the cache entry in a
directory equal to one character off the end of the cache entry name and then again in another directories
equal to two characters off the end of the cache injury name and so on.
This cache entry name will discuss in a second but it will look something like this.
Next still on this directive add another parameter keys underscore zone equals the name of this cache.
This can be any descriptive name you choose.
For example my cash or zone 1 etc. followed by a colon character and the size of this cache.
Zone 100 megabytes which should be ample for most sites.
And finally an optional parameter in active which sets how long to keep a cache entry after the last
time it's accessed.
This defaults to 10 minutes if admitted but Al.
Up to 60 minutes.
That's all I'll sit on the cash bath directive although a no more optional parameters does exist.
These just being the key ones.
The second directive we need to configure our cash is fast CGI underscore cash key a standard directive
that takes a string format from which to create cache entries for example.
I'll make this a very common format of scheme so H T T P or htb s request methot get post etc..
Post the domain and request.
You are right.
Meaning a typical cash entry will be identified as for example h.t. dp s get dumaine dot com slash blog
slash article.
This being the way engine X identifies a request to a cash entry.
So let's say your entire website is accessible over both a tdp and H T T P S.
No changes whatsoever.
You could leave out the scheme variable to have both htb Domain dot com slash blog slash article and
hgt B S domain dot com slash blog slash article served from the same cache entry wares.
Adding this scheme as we did will create to increase one for each GDP and one for hgt B s an important
concept to understand.
Generally though.
Going with this format is a safe albeit overly specific form.
Another important point to mention in regard to this cash key format is that this string is hashed or
more specifically m.d. five hashed to create the entry name I referenced earlier when setting the levels.
Okay that's how a microcap configured.
Next then we have to implement this where we want dynamic content to be cached.
In our case being this BHP location where to enable caching we can say fast CGI cache.
Zone 1 the cache name or identifier.
And secondly to fine tune the validity of these cash responses.
We can also add fast CGI cash valid and then specify how long a cash response should be valid for based
on the response code or multiple code to hundreds and foro force for example is valid for 60 Minutes.
As per this value here or alternatively this being an array directive said forro forth to only be valid
for 10 minutes and so on.
I'll stick with 200 for now save this and before I reload the configuration.
Let's test the current performance with out our new micro cache.
Now to test this we can use a number of tools but the simplest and prefered one for me is a patchy bench.
A simple HTP benchmarking tool from the Apache organization to install apache bench run apt get install
apache to utils or if you're using yarm on centaurs you can do the same by running yum install HTP de
tools.
That's all done.
Check.
We have the tool available a B being the Apache bench command and there we get the help out but so this
is ready at the moment.
We only have the default indexed iph P request available which if I curlett gives us this h.t. email
heading with the date not the best example as there's hardly anything for BHB FP him to process but
nonetheless we'll test this by creating 100 requests to this page in lots of 10 so 10 connections at
a time 10 times using a patchy bench then we can do this by running a B with it n flag one hundred for
100 requests.
See flag 10 meaning with a concurrency of 10 connections to that I P enter and done.
The two most significant numbers here being this thousand six hundred sixty two requests per second
and the average time a single request took to receive a response.
Also keep in mind that this test was run on the host server.
So providing an even faster response but we can change this.
I'll open that indexed iph file for editing slash sites slash demo slash index or BHB.
And right before the script responds I'll add a 1 second sleep.
So basically simulating a long running process like a database request or even a large loop etc..
Write that out exit the editor and now when I run this test again we should get a drastically slower
test.
I'll skip through the waiting and there we're down from sixty requests per second to only four point
six with the average time per request being 2 seconds.
Those concurrent connections already backing each other up then.
Meaning that on a typical request like this engine X can now cache the first response and then serve
the remaining 99 from that cache almost immediately.
So let's see that I'll reload this configuration enabling o a new micro cache same test again done even
faster than the first test with out the sleep function.
A two thousand five hundred and fifty requests per second and only three point nine milliseconds on
average per request a massive increase in server performance.
Then with the added benefit of the server not having to use nearly as many resources at the moment.
However we still have no way other than these really fast response times to know whether the request
was actually served from the cache.
Luckily the fast cji Cache module allows us to check the status of a response meaning whether it was
served from cash or not by means of a variable.
Upstream cash status which we can pass with the response as a header will add this to all responses.
So in that HTP context say add header.
I'll call this X cash x being a naming convention for custom headers upstream cash status.
Save this reload the configuration and now do akol request for the headers enter.
And there we have it x cache hit meaning this was served from the cache so to see a cache Merse we can
simply change the U R L.
Making it explicit by adding indexed or patch B.
So.
Same request.
But remember that fast cji Cache key format it includes the request.
You are right.
Meaning this is now a new cache entry enter and as expected MS..
The last important part of the Nemi contain caching is adding cache exceptions.
First let's create a variable with which to track hash exceptions.
Starting by default with no exceptions.
So just cash set.
Call this variable.
No cash zero.
Then as an example condition add an if statement.
A very common condition on which to disable caching being if the request method is a post request meaning
a form submission etc..
Or for the sake of demonstrating here.
If a query parameter dollar sign ARG with the name skip cash is one set.
No cash to one.
Or in other words true then to actually have caching disabled on the condition of this variable being
0 or 1 in the cached location set fast.
E.g. I cash bypass to the value of the no cash variable and the same for fast CGI.
No cash.
Meaning if this very Bilis one by serving this from the keusch and don't write the response to the cash
either.
Save this.
And now we should be able to completely bypass the cash by setting this Skip cash query parameter to
one on any BHP request over to the terminal.
Reload.
Cole as before to ensure we get a hit.
There it is at the skip cash query however.
And this time we get an explicit bypass of the cash.
So an easy way to add exceptions for anything like lobbed in areas of your site life data etc..
That's where we'll leave micro caching.
But be sure to have a good understanding of this lesson from start to finish as caching server side
content will be the single biggest performance enhancement you can add to your site.
Given you serve dynamic content or handle many generic database queries.