WEBVTT 00:04.490 --> 00:11.060 An engine X my Croque ASH is a symbol server side cash that allows us to store dynamic language responses 00:11.120 --> 00:18.230 in order to avoid or at least minimize server side language processing for websites relying heavily 00:18.230 --> 00:24.240 on server side languages and database access such as P. HP and miniscule. 00:24.290 --> 00:29.640 This cash can provide incredible performance benefits and drastically reduce server load. 00:29.810 --> 00:30.500 Simply put. 00:30.500 --> 00:37.550 Then let's say a user makes a request for dynamic content engine X passes that request to be a b f be 00:37.550 --> 00:37.860 m. 00:37.880 --> 00:44.340 In our case which process is set and possibly even include some database queries here. 00:44.370 --> 00:50.000 B f P. M. then returns their processed response to engine x most likely in the form of H. 00:50.000 --> 00:57.730 Dear Mal at which point engine X using a micro cache can write that response to dusk meaning next time 00:57.770 --> 00:59.750 a user makes the same request. 00:59.760 --> 01:03.910 There's no need at all to even contest p p f p. m.. 01:03.980 --> 01:06.130 The response can be read from desk. 01:06.140 --> 01:10.370 As with any other static ressource and sent to the client. 01:10.370 --> 01:15.470 Of course it's not always going to be quite the straight forward as Dynamic Content is dynamic for a 01:15.470 --> 01:21.890 reason but in this case and we'll see how to configure a micro cache for Patch be using engine X as 01:21.890 --> 01:25.070 fast CGI cache as before. 01:25.070 --> 01:32.570 I'll clear some of this previously since code remove all of the Jesus directives and the static ressource 01:32.570 --> 01:33.400 location. 01:33.410 --> 01:42.230 Implementing geezer then to an able and configure fast CGI caching in the htb context making this available 01:42.230 --> 01:44.610 to all our server contexts. 01:44.660 --> 01:54.860 Start by setting fast CGI cache path which as the name suggests takes a filesystem location to which 01:54.890 --> 01:57.500 these cash increase can be written. 01:57.500 --> 02:02.550 I prefer to use the slash TMB directory for this as it gets emptied on boot. 02:02.660 --> 02:09.680 For most Linux distributions but feel free to create this cache elsewhere should you wish slash engine 02:09.680 --> 02:11.800 X underscore cache. 02:12.140 --> 02:16.880 Then on the same directive add a parameter called levels. 02:17.060 --> 02:25.320 Setting that to one calon to like so now the levels parameter is a very poorly documented parameter. 02:25.490 --> 02:31.250 But essentially what it allows us to configure is the depth of directory's to split the cash increase 02:31.310 --> 02:32.420 in two. 02:32.510 --> 02:37.770 If you leave this out engine X will simply write every cash entry directly to this cash path at the 02:37.770 --> 02:44.780 rectory which is fine for smaller sites but setting that to this means storing the cache entry in a 02:44.780 --> 02:52.160 directory equal to one character off the end of the cache entry name and then again in another directories 02:52.190 --> 02:57.370 equal to two characters off the end of the cache injury name and so on. 02:57.560 --> 03:02.600 This cache entry name will discuss in a second but it will look something like this. 03:03.130 --> 03:12.700 Next still on this directive add another parameter keys underscore zone equals the name of this cache. 03:12.730 --> 03:15.430 This can be any descriptive name you choose. 03:15.430 --> 03:25.520 For example my cash or zone 1 etc. followed by a colon character and the size of this cache. 03:25.550 --> 03:30.590 Zone 100 megabytes which should be ample for most sites. 03:30.730 --> 03:37.810 And finally an optional parameter in active which sets how long to keep a cache entry after the last 03:37.810 --> 03:39.480 time it's accessed. 03:39.490 --> 03:42.600 This defaults to 10 minutes if admitted but Al. 03:42.610 --> 03:44.710 Up to 60 minutes. 03:44.710 --> 03:51.100 That's all I'll sit on the cash bath directive although a no more optional parameters does exist. 03:51.130 --> 03:53.430 These just being the key ones. 03:53.470 --> 04:01.380 The second directive we need to configure our cash is fast CGI underscore cash key a standard directive 04:01.420 --> 04:06.280 that takes a string format from which to create cache entries for example. 04:06.310 --> 04:16.430 I'll make this a very common format of scheme so H T T P or htb s request methot get post etc.. 04:16.750 --> 04:19.540 Post the domain and request. 04:19.540 --> 04:20.530 You are right. 04:20.980 --> 04:31.090 Meaning a typical cash entry will be identified as for example h.t. dp s get dumaine dot com slash blog 04:31.240 --> 04:33.030 slash article. 04:33.220 --> 04:38.050 This being the way engine X identifies a request to a cash entry. 04:38.110 --> 04:44.920 So let's say your entire website is accessible over both a tdp and H T T P S. 04:44.920 --> 04:46.770 No changes whatsoever. 04:46.960 --> 04:54.940 You could leave out the scheme variable to have both htb Domain dot com slash blog slash article and 04:55.040 --> 05:02.410 hgt B S domain dot com slash blog slash article served from the same cache entry wares. 05:02.440 --> 05:10.330 Adding this scheme as we did will create to increase one for each GDP and one for hgt B s an important 05:10.330 --> 05:12.040 concept to understand. 05:12.280 --> 05:13.170 Generally though. 05:13.170 --> 05:17.470 Going with this format is a safe albeit overly specific form. 05:17.890 --> 05:24.010 Another important point to mention in regard to this cash key format is that this string is hashed or 05:24.010 --> 05:31.050 more specifically m.d. five hashed to create the entry name I referenced earlier when setting the levels. 05:31.310 --> 05:33.440 Okay that's how a microcap configured. 05:33.670 --> 05:37.980 Next then we have to implement this where we want dynamic content to be cached. 05:38.080 --> 05:45.870 In our case being this BHP location where to enable caching we can say fast CGI cache. 05:46.580 --> 05:50.570 Zone 1 the cache name or identifier. 05:50.570 --> 05:55.240 And secondly to fine tune the validity of these cash responses. 05:55.250 --> 06:03.590 We can also add fast CGI cash valid and then specify how long a cash response should be valid for based 06:03.620 --> 06:12.980 on the response code or multiple code to hundreds and foro force for example is valid for 60 Minutes. 06:12.980 --> 06:20.330 As per this value here or alternatively this being an array directive said forro forth to only be valid 06:20.330 --> 06:23.020 for 10 minutes and so on. 06:23.150 --> 06:28.870 I'll stick with 200 for now save this and before I reload the configuration. 06:28.880 --> 06:33.010 Let's test the current performance with out our new micro cache. 06:33.200 --> 06:39.700 Now to test this we can use a number of tools but the simplest and prefered one for me is a patchy bench. 06:39.860 --> 06:48.290 A simple HTP benchmarking tool from the Apache organization to install apache bench run apt get install 06:48.610 --> 06:58.550 apache to utils or if you're using yarm on centaurs you can do the same by running yum install HTP de 06:58.700 --> 06:59.620 tools. 07:01.750 --> 07:03.120 That's all done. 07:03.310 --> 07:03.610 Check. 07:03.610 --> 07:10.960 We have the tool available a B being the Apache bench command and there we get the help out but so this 07:10.960 --> 07:12.570 is ready at the moment. 07:12.570 --> 07:19.570 We only have the default indexed iph P request available which if I curlett gives us this h.t. email 07:19.570 --> 07:25.960 heading with the date not the best example as there's hardly anything for BHB FP him to process but 07:25.960 --> 07:34.240 nonetheless we'll test this by creating 100 requests to this page in lots of 10 so 10 connections at 07:34.240 --> 07:44.020 a time 10 times using a patchy bench then we can do this by running a B with it n flag one hundred for 07:44.020 --> 07:45.750 100 requests. 07:46.000 --> 07:54.490 See flag 10 meaning with a concurrency of 10 connections to that I P enter and done. 07:54.670 --> 08:00.220 The two most significant numbers here being this thousand six hundred sixty two requests per second 08:00.640 --> 08:04.720 and the average time a single request took to receive a response. 08:04.720 --> 08:08.510 Also keep in mind that this test was run on the host server. 08:08.620 --> 08:13.360 So providing an even faster response but we can change this. 08:13.390 --> 08:21.200 I'll open that indexed iph file for editing slash sites slash demo slash index or BHB. 08:22.030 --> 08:26.800 And right before the script responds I'll add a 1 second sleep. 08:26.800 --> 08:33.440 So basically simulating a long running process like a database request or even a large loop etc.. 08:33.610 --> 08:41.020 Write that out exit the editor and now when I run this test again we should get a drastically slower 08:41.020 --> 08:42.040 test. 08:42.160 --> 08:49.840 I'll skip through the waiting and there we're down from sixty requests per second to only four point 08:49.840 --> 08:54.610 six with the average time per request being 2 seconds. 08:54.610 --> 08:58.000 Those concurrent connections already backing each other up then. 08:58.360 --> 09:04.600 Meaning that on a typical request like this engine X can now cache the first response and then serve 09:04.630 --> 09:08.420 the remaining 99 from that cache almost immediately. 09:08.470 --> 09:18.130 So let's see that I'll reload this configuration enabling o a new micro cache same test again done even 09:18.130 --> 09:21.280 faster than the first test with out the sleep function. 09:21.280 --> 09:26.890 A two thousand five hundred and fifty requests per second and only three point nine milliseconds on 09:26.950 --> 09:30.580 average per request a massive increase in server performance. 09:30.580 --> 09:36.850 Then with the added benefit of the server not having to use nearly as many resources at the moment. 09:36.850 --> 09:41.890 However we still have no way other than these really fast response times to know whether the request 09:41.890 --> 09:44.050 was actually served from the cache. 09:44.290 --> 09:50.050 Luckily the fast cji Cache module allows us to check the status of a response meaning whether it was 09:50.050 --> 09:53.710 served from cash or not by means of a variable. 09:54.290 --> 10:02.420 Upstream cash status which we can pass with the response as a header will add this to all responses. 10:02.450 --> 10:06.870 So in that HTP context say add header. 10:07.100 --> 10:15.910 I'll call this X cash x being a naming convention for custom headers upstream cash status. 10:16.220 --> 10:23.350 Save this reload the configuration and now do akol request for the headers enter. 10:23.480 --> 10:31.580 And there we have it x cache hit meaning this was served from the cache so to see a cache Merse we can 10:31.580 --> 10:33.350 simply change the U R L. 10:33.500 --> 10:37.370 Making it explicit by adding indexed or patch B. 10:37.430 --> 10:37.810 So. 10:37.820 --> 10:39.000 Same request. 10:39.050 --> 10:43.580 But remember that fast cji Cache key format it includes the request. 10:43.580 --> 10:44.470 You are right. 10:44.680 --> 10:50.830 Meaning this is now a new cache entry enter and as expected MS.. 10:51.800 --> 10:56.900 The last important part of the Nemi contain caching is adding cache exceptions. 10:56.900 --> 11:00.780 First let's create a variable with which to track hash exceptions. 11:00.950 --> 11:03.830 Starting by default with no exceptions. 11:03.830 --> 11:06.320 So just cash set. 11:06.350 --> 11:07.380 Call this variable. 11:07.400 --> 11:09.730 No cash zero. 11:11.040 --> 11:15.080 Then as an example condition add an if statement. 11:15.950 --> 11:21.710 A very common condition on which to disable caching being if the request method is a post request meaning 11:21.710 --> 11:23.580 a form submission etc.. 11:23.870 --> 11:26.210 Or for the sake of demonstrating here. 11:26.390 --> 11:34.650 If a query parameter dollar sign ARG with the name skip cash is one set. 11:34.660 --> 11:36.440 No cash to one. 11:36.590 --> 11:42.800 Or in other words true then to actually have caching disabled on the condition of this variable being 11:42.820 --> 11:47.130 0 or 1 in the cached location set fast. 11:47.140 --> 11:54.600 E.g. I cash bypass to the value of the no cash variable and the same for fast CGI. 11:54.650 --> 11:55.770 No cash. 11:58.570 --> 12:05.860 Meaning if this very Bilis one by serving this from the keusch and don't write the response to the cash 12:05.890 --> 12:06.600 either. 12:07.310 --> 12:08.570 Save this. 12:08.690 --> 12:14.300 And now we should be able to completely bypass the cash by setting this Skip cash query parameter to 12:14.300 --> 12:18.460 one on any BHP request over to the terminal. 12:19.320 --> 12:20.610 Reload. 12:22.250 --> 12:24.910 Cole as before to ensure we get a hit. 12:25.690 --> 12:29.360 There it is at the skip cash query however. 12:31.120 --> 12:35.000 And this time we get an explicit bypass of the cash. 12:35.260 --> 12:42.200 So an easy way to add exceptions for anything like lobbed in areas of your site life data etc.. 12:42.700 --> 12:44.460 That's where we'll leave micro caching. 12:44.470 --> 12:50.080 But be sure to have a good understanding of this lesson from start to finish as caching server side 12:50.080 --> 12:54.470 content will be the single biggest performance enhancement you can add to your site. 12:54.700 --> 12:59.210 Given you serve dynamic content or handle many generic database queries.