1
00:00:04,490 --> 00:00:11,060
An engine X my Croque ASH is a symbol server side cash that allows us to store dynamic language responses

2
00:00:11,120 --> 00:00:18,230
in order to avoid or at least minimize server side language processing for websites relying heavily

3
00:00:18,230 --> 00:00:24,240
on server side languages and database access such as P. HP and miniscule.

4
00:00:24,290 --> 00:00:29,640
This cash can provide incredible performance benefits and drastically reduce server load.

5
00:00:29,810 --> 00:00:30,500
Simply put.

6
00:00:30,500 --> 00: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

7
00:00:37,550 --> 00:00:37,860
m.

8
00:00:37,880 --> 00:00:44,340
In our case which process is set and possibly even include some database queries here.

9
00:00:44,370 --> 00:00:50,000
B f P. M. then returns their processed response to engine x most likely in the form of H.

10
00:00:50,000 --> 00:00:57,730
Dear Mal at which point engine X using a micro cache can write that response to dusk meaning next time

11
00:00:57,770 --> 00:00:59,750
a user makes the same request.

12
00:00:59,760 --> 00:01:03,910
There's no need at all to even contest p p f p. m..

13
00:01:03,980 --> 00:01:06,130
The response can be read from desk.

14
00:01:06,140 --> 00:01:10,370
As with any other static ressource and sent to the client.

15
00:01:10,370 --> 00:01:15,470
Of course it's not always going to be quite the straight forward as Dynamic Content is dynamic for a

16
00:01:15,470 --> 00: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

17
00:01:21,890 --> 00:01:25,070
fast CGI cache as before.

18
00:01:25,070 --> 00:01:32,570
I'll clear some of this previously since code remove all of the Jesus directives and the static ressource

19
00:01:32,570 --> 00:01:33,400
location.

20
00:01:33,410 --> 00:01:42,230
Implementing geezer then to an able and configure fast CGI caching in the htb context making this available

21
00:01:42,230 --> 00:01:44,610
to all our server contexts.

22
00:01:44,660 --> 00:01:54,860
Start by setting fast CGI cache path which as the name suggests takes a filesystem location to which

23
00:01:54,890 --> 00:01:57,500
these cash increase can be written.

24
00:01:57,500 --> 00:02:02,550
I prefer to use the slash TMB directory for this as it gets emptied on boot.

25
00:02:02,660 --> 00:02:09,680
For most Linux distributions but feel free to create this cache elsewhere should you wish slash engine

26
00:02:09,680 --> 00:02:11,800
X underscore cache.

27
00:02:12,140 --> 00:02:16,880
Then on the same directive add a parameter called levels.

28
00:02:17,060 --> 00:02:25,320
Setting that to one calon to like so now the levels parameter is a very poorly documented parameter.

29
00:02:25,490 --> 00:02:31,250
But essentially what it allows us to configure is the depth of directory's to split the cash increase

30
00:02:31,310 --> 00:02:32,420
in two.

31
00:02:32,510 --> 00:02:37,770
If you leave this out engine X will simply write every cash entry directly to this cash path at the

32
00:02:37,770 --> 00:02:44,780
rectory which is fine for smaller sites but setting that to this means storing the cache entry in a

33
00:02:44,780 --> 00:02:52,160
directory equal to one character off the end of the cache entry name and then again in another directories

34
00:02:52,190 --> 00:02:57,370
equal to two characters off the end of the cache injury name and so on.

35
00:02:57,560 --> 00:03:02,600
This cache entry name will discuss in a second but it will look something like this.

36
00:03:03,130 --> 00:03:12,700
Next still on this directive add another parameter keys underscore zone equals the name of this cache.

37
00:03:12,730 --> 00:03:15,430
This can be any descriptive name you choose.

38
00:03:15,430 --> 00:03:25,520
For example my cash or zone 1 etc. followed by a colon character and the size of this cache.

39
00:03:25,550 --> 00:03:30,590
Zone 100 megabytes which should be ample for most sites.

40
00:03:30,730 --> 00:03:37,810
And finally an optional parameter in active which sets how long to keep a cache entry after the last

41
00:03:37,810 --> 00:03:39,480
time it's accessed.

42
00:03:39,490 --> 00:03:42,600
This defaults to 10 minutes if admitted but Al.

43
00:03:42,610 --> 00:03:44,710
Up to 60 minutes.

44
00:03:44,710 --> 00:03:51,100
That's all I'll sit on the cash bath directive although a no more optional parameters does exist.

45
00:03:51,130 --> 00:03:53,430
These just being the key ones.

46
00:03:53,470 --> 00:04:01,380
The second directive we need to configure our cash is fast CGI underscore cash key a standard directive

47
00:04:01,420 --> 00:04:06,280
that takes a string format from which to create cache entries for example.

48
00:04:06,310 --> 00: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..

49
00:04:16,750 --> 00:04:19,540
Post the domain and request.

50
00:04:19,540 --> 00:04:20,530
You are right.

51
00:04:20,980 --> 00:04:31,090
Meaning a typical cash entry will be identified as for example h.t. dp s get dumaine dot com slash blog

52
00:04:31,240 --> 00:04:33,030
slash article.

53
00:04:33,220 --> 00:04:38,050
This being the way engine X identifies a request to a cash entry.

54
00:04:38,110 --> 00:04:44,920
So let's say your entire website is accessible over both a tdp and H T T P S.

55
00:04:44,920 --> 00:04:46,770
No changes whatsoever.

56
00:04:46,960 --> 00:04:54,940
You could leave out the scheme variable to have both htb Domain dot com slash blog slash article and

57
00:04:55,040 --> 00:05:02,410
hgt B S domain dot com slash blog slash article served from the same cache entry wares.

58
00:05:02,440 --> 00: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

59
00:05:10,330 --> 00:05:12,040
concept to understand.

60
00:05:12,280 --> 00:05:13,170
Generally though.

61
00:05:13,170 --> 00:05:17,470
Going with this format is a safe albeit overly specific form.

62
00:05:17,890 --> 00:05:24,010
Another important point to mention in regard to this cash key format is that this string is hashed or

63
00:05:24,010 --> 00:05:31,050
more specifically m.d. five hashed to create the entry name I referenced earlier when setting the levels.

64
00:05:31,310 --> 00:05:33,440
Okay that's how a microcap configured.

65
00:05:33,670 --> 00:05:37,980
Next then we have to implement this where we want dynamic content to be cached.

66
00:05:38,080 --> 00:05:45,870
In our case being this BHP location where to enable caching we can say fast CGI cache.

67
00:05:46,580 --> 00:05:50,570
Zone 1 the cache name or identifier.

68
00:05:50,570 --> 00:05:55,240
And secondly to fine tune the validity of these cash responses.

69
00:05:55,250 --> 00:06:03,590
We can also add fast CGI cash valid and then specify how long a cash response should be valid for based

70
00:06:03,620 --> 00:06:12,980
on the response code or multiple code to hundreds and foro force for example is valid for 60 Minutes.

71
00:06:12,980 --> 00:06:20,330
As per this value here or alternatively this being an array directive said forro forth to only be valid

72
00:06:20,330 --> 00:06:23,020
for 10 minutes and so on.

73
00:06:23,150 --> 00:06:28,870
I'll stick with 200 for now save this and before I reload the configuration.

74
00:06:28,880 --> 00:06:33,010
Let's test the current performance with out our new micro cache.

75
00:06:33,200 --> 00: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.

76
00:06:39,860 --> 00:06:48,290
A simple HTP benchmarking tool from the Apache organization to install apache bench run apt get install

77
00:06:48,610 --> 00: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

78
00:06:58,700 --> 00:06:59,620
tools.

79
00:07:01,750 --> 00:07:03,120
That's all done.

80
00:07:03,310 --> 00:07:03,610
Check.

81
00:07:03,610 --> 00: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

82
00:07:10,960 --> 00:07:12,570
is ready at the moment.

83
00:07:12,570 --> 00:07:19,570
We only have the default indexed iph P request available which if I curlett gives us this h.t. email

84
00:07:19,570 --> 00:07:25,960
heading with the date not the best example as there's hardly anything for BHB FP him to process but

85
00:07:25,960 --> 00:07:34,240
nonetheless we'll test this by creating 100 requests to this page in lots of 10 so 10 connections at

86
00:07:34,240 --> 00: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

87
00:07:44,020 --> 00:07:45,750
100 requests.

88
00:07:46,000 --> 00:07:54,490
See flag 10 meaning with a concurrency of 10 connections to that I P enter and done.

89
00:07:54,670 --> 00:08:00,220
The two most significant numbers here being this thousand six hundred sixty two requests per second

90
00:08:00,640 --> 00:08:04,720
and the average time a single request took to receive a response.

91
00:08:04,720 --> 00:08:08,510
Also keep in mind that this test was run on the host server.

92
00:08:08,620 --> 00:08:13,360
So providing an even faster response but we can change this.

93
00:08:13,390 --> 00:08:21,200
I'll open that indexed iph file for editing slash sites slash demo slash index or BHB.

94
00:08:22,030 --> 00:08:26,800
And right before the script responds I'll add a 1 second sleep.

95
00:08:26,800 --> 00:08:33,440
So basically simulating a long running process like a database request or even a large loop etc..

96
00:08:33,610 --> 00:08:41,020
Write that out exit the editor and now when I run this test again we should get a drastically slower

97
00:08:41,020 --> 00:08:42,040
test.

98
00:08:42,160 --> 00:08:49,840
I'll skip through the waiting and there we're down from sixty requests per second to only four point

99
00:08:49,840 --> 00:08:54,610
six with the average time per request being 2 seconds.

100
00:08:54,610 --> 00:08:58,000
Those concurrent connections already backing each other up then.

101
00:08:58,360 --> 00:09:04,600
Meaning that on a typical request like this engine X can now cache the first response and then serve

102
00:09:04,630 --> 00:09:08,420
the remaining 99 from that cache almost immediately.

103
00:09:08,470 --> 00:09:18,130
So let's see that I'll reload this configuration enabling o a new micro cache same test again done even

104
00:09:18,130 --> 00:09:21,280
faster than the first test with out the sleep function.

105
00:09:21,280 --> 00:09:26,890
A two thousand five hundred and fifty requests per second and only three point nine milliseconds on

106
00:09:26,950 --> 00:09:30,580
average per request a massive increase in server performance.

107
00:09:30,580 --> 00:09:36,850
Then with the added benefit of the server not having to use nearly as many resources at the moment.

108
00:09:36,850 --> 00:09:41,890
However we still have no way other than these really fast response times to know whether the request

109
00:09:41,890 --> 00:09:44,050
was actually served from the cache.

110
00:09:44,290 --> 00:09:50,050
Luckily the fast cji Cache module allows us to check the status of a response meaning whether it was

111
00:09:50,050 --> 00:09:53,710
served from cash or not by means of a variable.

112
00:09:54,290 --> 00:10:02,420
Upstream cash status which we can pass with the response as a header will add this to all responses.

113
00:10:02,450 --> 00:10:06,870
So in that HTP context say add header.

114
00:10:07,100 --> 00:10:15,910
I'll call this X cash x being a naming convention for custom headers upstream cash status.

115
00:10:16,220 --> 00:10:23,350
Save this reload the configuration and now do akol request for the headers enter.

116
00:10:23,480 --> 00: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

117
00:10:31,580 --> 00:10:33,350
simply change the U R L.

118
00:10:33,500 --> 00:10:37,370
Making it explicit by adding indexed or patch B.

119
00:10:37,430 --> 00:10:37,810
So.

120
00:10:37,820 --> 00:10:39,000
Same request.

121
00:10:39,050 --> 00:10:43,580
But remember that fast cji Cache key format it includes the request.

122
00:10:43,580 --> 00:10:44,470
You are right.

123
00:10:44,680 --> 00:10:50,830
Meaning this is now a new cache entry enter and as expected MS..

124
00:10:51,800 --> 00:10:56,900
The last important part of the Nemi contain caching is adding cache exceptions.

125
00:10:56,900 --> 00:11:00,780
First let's create a variable with which to track hash exceptions.

126
00:11:00,950 --> 00:11:03,830
Starting by default with no exceptions.

127
00:11:03,830 --> 00:11:06,320
So just cash set.

128
00:11:06,350 --> 00:11:07,380
Call this variable.

129
00:11:07,400 --> 00:11:09,730
No cash zero.

130
00:11:11,040 --> 00:11:15,080
Then as an example condition add an if statement.

131
00:11:15,950 --> 00:11:21,710
A very common condition on which to disable caching being if the request method is a post request meaning

132
00:11:21,710 --> 00:11:23,580
a form submission etc..

133
00:11:23,870 --> 00:11:26,210
Or for the sake of demonstrating here.

134
00:11:26,390 --> 00:11:34,650
If a query parameter dollar sign ARG with the name skip cash is one set.

135
00:11:34,660 --> 00:11:36,440
No cash to one.

136
00:11:36,590 --> 00:11:42,800
Or in other words true then to actually have caching disabled on the condition of this variable being

137
00:11:42,820 --> 00:11:47,130
0 or 1 in the cached location set fast.

138
00:11:47,140 --> 00:11:54,600
E.g. I cash bypass to the value of the no cash variable and the same for fast CGI.

139
00:11:54,650 --> 00:11:55,770
No cash.

140
00:11:58,570 --> 00:12:05,860
Meaning if this very Bilis one by serving this from the keusch and don't write the response to the cash

141
00:12:05,890 --> 00:12:06,600
either.

142
00:12:07,310 --> 00:12:08,570
Save this.

143
00:12:08,690 --> 00:12:14,300
And now we should be able to completely bypass the cash by setting this Skip cash query parameter to

144
00:12:14,300 --> 00:12:18,460
one on any BHP request over to the terminal.

145
00:12:19,320 --> 00:12:20,610
Reload.

146
00:12:22,250 --> 00:12:24,910
Cole as before to ensure we get a hit.

147
00:12:25,690 --> 00:12:29,360
There it is at the skip cash query however.

148
00:12:31,120 --> 00:12:35,000
And this time we get an explicit bypass of the cash.

149
00:12:35,260 --> 00:12:42,200
So an easy way to add exceptions for anything like lobbed in areas of your site life data etc..

150
00:12:42,700 --> 00:12:44,460
That's where we'll leave micro caching.

151
00:12:44,470 --> 00:12:50,080
But be sure to have a good understanding of this lesson from start to finish as caching server side

152
00:12:50,080 --> 00:12:54,470
content will be the single biggest performance enhancement you can add to your site.

153
00:12:54,700 --> 00:12:59,210
Given you serve dynamic content or handle many generic database queries.