WEBVTT 00:04.310 --> 00:09.680 In the previous lesson we learned how to configure our engineers processes for the best performance. 00:09.740 --> 00:15.170 So in this lesson we'll take a slightly more detailed look at optimizing those processes by configuring 00:15.170 --> 00:17.550 buffer sizes and time. 00:17.810 --> 00:23.060 This time around instead of adding these configurations during the lesson I've added them in advance 00:23.090 --> 00:25.450 as there's nothing really to demonstrate. 00:25.550 --> 00:31.050 If you want to copy these into your own configuration as a starting point the filas Linked In the resources. 00:31.070 --> 00:37.760 As with previous lessons now before I start explaining the function of these additions Please note that 00:37.790 --> 00:44.270 whilst configuring process this is fairly easy and measurable task buffer sizes and time out is the 00:44.270 --> 00:45.800 complete opposite. 00:45.890 --> 00:51.650 This being as they are not so much dependent on the server but more the nature of the requests to the 00:51.650 --> 00:52.450 server. 00:52.670 --> 00:55.730 In fact I'd suggest leaving these as they default values. 00:55.730 --> 01:01.100 If you're unsure about why you're tweaking them at all nonetheless it's very important to understand 01:01.100 --> 01:05.090 the important ones and know how to change them should you ever need to. 01:05.450 --> 01:09.730 First up then let's discuss in brief what a buffer is. 01:09.860 --> 01:18.020 Buffering is when a process or an engine X worker in this case reads data into memory or RAM before 01:18.020 --> 01:20.490 writing it to its next destination. 01:20.600 --> 01:27.840 For example engine X receives a request which it reads from ATC tcap Bought port 80 in this case writes 01:27.860 --> 01:31.580 that request data to memory which is buffering. 01:31.580 --> 01:37.790 Or if the buffer is too small for the amount of data being read write some of it to disk. 01:38.480 --> 01:44.870 The opposite of this then is that engine X response to a request with say a static file which it reads 01:44.870 --> 01:51.860 from disk into memory so buffering the file and send that data to the client from memory. 01:52.160 --> 01:58.310 This happens as the name implies to create a buffer or layer of protection between reading and writing 01:58.310 --> 01:59.270 of data. 01:59.420 --> 02:05.480 A process which can get extremely complicated but for the purposes of configuring engine X just have 02:05.480 --> 02:07.250 an understanding of what it is. 02:07.250 --> 02:12.980 In order to better understand configuring these directives timeouts are pretty self-explanatory. 02:12.980 --> 02:16.420 They simply suggest a cut off time for a given event. 02:16.730 --> 02:17.430 Or example. 02:17.450 --> 02:23.930 If receiving a request from a client stop after a certain number of seconds thus preventing a client 02:23.930 --> 02:28.110 from sending an endless stream of data and eventually breaking the server. 02:28.990 --> 02:29.180 OK. 02:29.180 --> 02:35.890 The first directive we have here then in the HTP context so essentially applying to our entire configuration 02:36.370 --> 02:39.560 is the client body buffer size. 02:39.610 --> 02:45.760 This directive then setting the amount of memory to allocate for buffering the post data from a client 02:46.060 --> 02:53.260 post data most likely coming from a form submission which in this case is set to 10 k or 10 kilobits 02:53.830 --> 02:55.160 for data sizes. 02:55.180 --> 03:03.070 Engine X support a plane number for example one hundred which would equate to bytes 10 k as we have 03:03.070 --> 03:10.690 it year which equates to killer bytes or 10 m for megabytes these can be written as either upper or 03:10.690 --> 03:11.880 lower case. 03:11.920 --> 03:18.010 I've linked to the documentation for these units in Texas in the resources so why 10 k then. 03:18.070 --> 03:23.860 Well in this case no reason other than a basic form submission should be well under that. 03:23.860 --> 03:29.650 Increasing this number to more than what we need will allocate and essentially waste memory on our server 03:30.130 --> 03:36.400 and making a too small will require engine X to write part of this buffer to disk which is a lot slower 03:36.400 --> 03:37.950 than writing it to memory. 03:38.140 --> 03:43.480 Your website might very well rely on much larger form submissions in which case you'll definitely want 03:43.480 --> 03:44.800 to increase this. 03:44.800 --> 03:50.350 Again very specific to the nature of requests your server is likely to receive. 03:50.440 --> 03:56.400 Second Then we have client Max body size set to 8 megabytes. 03:56.470 --> 04:00.530 Meaning don't accept post requests of more than 8 megabytes. 04:00.670 --> 04:08.830 If it is larger than 8 Make the server will respond with a 4 1 3 error which is request entity too large. 04:08.830 --> 04:14.530 Again this being a safety measure to ensure a user doesn't mistakenly or maliciously send a very large 04:14.530 --> 04:18.040 post request which could cause the server to slow down. 04:18.040 --> 04:20.430 Use up a lot of disk space etc.. 04:20.710 --> 04:25.960 8 meg being a fairly safe element that should still allow most standard images to be uploaded and so 04:25.960 --> 04:26.660 on. 04:26.830 --> 04:33.280 Those two directives dealing with post requests the next one is the client header buffer size as the 04:33.280 --> 04:37.920 name suggests the amount of memory to allocate to reading request headers. 04:38.110 --> 04:41.980 One killer by being more than enough for 99 percent of requests. 04:42.100 --> 04:44.650 It is typically being a small amount of data. 04:45.070 --> 04:48.330 Then still fine tuning incoming requests. 04:48.400 --> 04:55.750 We have the two major client timeouts client body time out and client header time out both of which 04:55.780 --> 04:59.130 I have set to a very short 12 milliseconds. 04:59.160 --> 05:04.720 Importantly in this case the body timeout does not refer to the time it takes to transmit the entire 05:04.720 --> 05:09.310 request body but rather the time between consecutive read operations. 05:09.490 --> 05:11.830 Those reads that happen to the buffer. 05:11.830 --> 05:18.040 Both of these default to 60 seconds which in my opinion is way too long but again feel free to adjust 05:18.070 --> 05:20.650 as you see fit as before. 05:20.650 --> 05:27.850 Engine X allows us to sit times as either a number only like this which indicates milliseconds with 05:27.850 --> 05:35.200 an S for seconds all the way up to years which will obviously not ever be applicable to DirecTV such 05:35.200 --> 05:37.190 as these timeouts. 05:37.210 --> 05:40.720 Next we have the very important keep life time out. 05:40.960 --> 05:46.840 This directive sets the amount of time engineers should keep a connection to a clear and open for in 05:46.840 --> 05:49.140 case more data is on the way. 05:49.150 --> 05:54.670 This is extremely useful when say a client is requesting a number of files and keeping a connection 05:54.730 --> 05:58.350 open reduces the time it takes to open another new connection. 05:58.570 --> 06:04.810 Equally not wanting to leave connections open for too long as this can result in a pool of max connections 06:04.860 --> 06:05.590 this time. 06:05.620 --> 06:07.850 This being used up. 06:07.900 --> 06:09.910 Unlikely but quite disastrous. 06:09.910 --> 06:12.130 Should it happen for the most part. 06:12.130 --> 06:16.980 There's no reason a connection would have to stay open beyond a few milliseconds before continuing. 06:17.080 --> 06:22.300 And most clients will close connections properly meaning this time out won't even apply. 06:22.450 --> 06:24.370 But giving you have the server resources. 06:24.370 --> 06:28.080 Feel free to increase this number to even a couple of seconds. 06:28.240 --> 06:32.760 And our last time out being the all important send time out. 06:32.770 --> 06:38.860 Meaning if a client does not receive any of the response data in this amount of time doesn't have to 06:38.860 --> 06:40.190 be all of the response data. 06:40.210 --> 06:41.710 But none offered at all. 06:41.710 --> 06:44.120 A boughts ending the response all together. 06:45.020 --> 06:47.890 The last two directives I have here is somewhat unique. 06:48.080 --> 06:52.900 And for the vast majority of web service will provide a decent increase in performance. 06:53.150 --> 06:57.350 Send file meaning we're sending a client data from dusk. 06:57.380 --> 07:00.710 So typically a static fire like an image etc.. 07:00.920 --> 07:02.650 Don't use a buffer. 07:02.690 --> 07:06.990 Read their data from the desk and write it directly to the response. 07:07.250 --> 07:14.790 With dcb no push enabling engine X to optimize the size of those data packets being sent to the client. 07:14.830 --> 07:20.300 Two very simple but incredibly valuable directives that will especially help optimize site with a large 07:20.300 --> 07:22.400 number of static resources. 07:22.910 --> 07:26.040 That wraps up the basics of buffers and time outs. 07:26.180 --> 07:31.810 And whilst this might be the most difficult aspect of an engine configuration to really fine tune I'd 07:31.820 --> 07:35.690 encourage you to give it a go but not worry about it too much. 07:35.690 --> 07:41.210 Most clients will open and close connections correctly without the need to be timed out or reject it.