1
00:00:04,310 --> 00:00:09,680
In the previous lesson we learned how to configure our engineers processes for the best performance.

2
00:00:09,740 --> 00:00:15,170
So in this lesson we'll take a slightly more detailed look at optimizing those processes by configuring

3
00:00:15,170 --> 00:00:17,550
buffer sizes and time.

4
00:00:17,810 --> 00:00:23,060
This time around instead of adding these configurations during the lesson I've added them in advance

5
00:00:23,090 --> 00:00:25,450
as there's nothing really to demonstrate.

6
00:00:25,550 --> 00:00:31,050
If you want to copy these into your own configuration as a starting point the filas Linked In the resources.

7
00:00:31,070 --> 00:00:37,760
As with previous lessons now before I start explaining the function of these additions Please note that

8
00:00:37,790 --> 00:00:44,270
whilst configuring process this is fairly easy and measurable task buffer sizes and time out is the

9
00:00:44,270 --> 00:00:45,800
complete opposite.

10
00:00:45,890 --> 00:00:51,650
This being as they are not so much dependent on the server but more the nature of the requests to the

11
00:00:51,650 --> 00:00:52,450
server.

12
00:00:52,670 --> 00:00:55,730
In fact I'd suggest leaving these as they default values.

13
00:00:55,730 --> 00:01:01,100
If you're unsure about why you're tweaking them at all nonetheless it's very important to understand

14
00:01:01,100 --> 00:01:05,090
the important ones and know how to change them should you ever need to.

15
00:01:05,450 --> 00:01:09,730
First up then let's discuss in brief what a buffer is.

16
00:01:09,860 --> 00:01:18,020
Buffering is when a process or an engine X worker in this case reads data into memory or RAM before

17
00:01:18,020 --> 00:01:20,490
writing it to its next destination.

18
00:01:20,600 --> 00:01:27,840
For example engine X receives a request which it reads from ATC tcap Bought port 80 in this case writes

19
00:01:27,860 --> 00:01:31,580
that request data to memory which is buffering.

20
00:01:31,580 --> 00:01:37,790
Or if the buffer is too small for the amount of data being read write some of it to disk.

21
00:01:38,480 --> 00:01:44,870
The opposite of this then is that engine X response to a request with say a static file which it reads

22
00:01:44,870 --> 00:01:51,860
from disk into memory so buffering the file and send that data to the client from memory.

23
00:01:52,160 --> 00:01:58,310
This happens as the name implies to create a buffer or layer of protection between reading and writing

24
00:01:58,310 --> 00:01:59,270
of data.

25
00:01:59,420 --> 00:02:05,480
A process which can get extremely complicated but for the purposes of configuring engine X just have

26
00:02:05,480 --> 00:02:07,250
an understanding of what it is.

27
00:02:07,250 --> 00:02:12,980
In order to better understand configuring these directives timeouts are pretty self-explanatory.

28
00:02:12,980 --> 00:02:16,420
They simply suggest a cut off time for a given event.

29
00:02:16,730 --> 00:02:17,430
Or example.

30
00:02:17,450 --> 00:02:23,930
If receiving a request from a client stop after a certain number of seconds thus preventing a client

31
00:02:23,930 --> 00:02:28,110
from sending an endless stream of data and eventually breaking the server.

32
00:02:28,990 --> 00:02:29,180
OK.

33
00:02:29,180 --> 00:02:35,890
The first directive we have here then in the HTP context so essentially applying to our entire configuration

34
00:02:36,370 --> 00:02:39,560
is the client body buffer size.

35
00:02:39,610 --> 00:02:45,760
This directive then setting the amount of memory to allocate for buffering the post data from a client

36
00:02:46,060 --> 00:02:53,260
post data most likely coming from a form submission which in this case is set to 10 k or 10 kilobits

37
00:02:53,830 --> 00:02:55,160
for data sizes.

38
00:02:55,180 --> 00:03:03,070
Engine X support a plane number for example one hundred which would equate to bytes 10 k as we have

39
00:03:03,070 --> 00:03:10,690
it year which equates to killer bytes or 10 m for megabytes these can be written as either upper or

40
00:03:10,690 --> 00:03:11,880
lower case.

41
00:03:11,920 --> 00:03:18,010
I've linked to the documentation for these units in Texas in the resources so why 10 k then.

42
00:03:18,070 --> 00:03:23,860
Well in this case no reason other than a basic form submission should be well under that.

43
00:03:23,860 --> 00:03:29,650
Increasing this number to more than what we need will allocate and essentially waste memory on our server

44
00:03:30,130 --> 00: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

45
00:03:36,400 --> 00:03:37,950
than writing it to memory.

46
00:03:38,140 --> 00:03:43,480
Your website might very well rely on much larger form submissions in which case you'll definitely want

47
00:03:43,480 --> 00:03:44,800
to increase this.

48
00:03:44,800 --> 00:03:50,350
Again very specific to the nature of requests your server is likely to receive.

49
00:03:50,440 --> 00:03:56,400
Second Then we have client Max body size set to 8 megabytes.

50
00:03:56,470 --> 00:04:00,530
Meaning don't accept post requests of more than 8 megabytes.

51
00:04:00,670 --> 00: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.

52
00:04:08,830 --> 00:04:14,530
Again this being a safety measure to ensure a user doesn't mistakenly or maliciously send a very large

53
00:04:14,530 --> 00:04:18,040
post request which could cause the server to slow down.

54
00:04:18,040 --> 00:04:20,430
Use up a lot of disk space etc..

55
00:04:20,710 --> 00:04:25,960
8 meg being a fairly safe element that should still allow most standard images to be uploaded and so

56
00:04:25,960 --> 00:04:26,660
on.

57
00:04:26,830 --> 00:04:33,280
Those two directives dealing with post requests the next one is the client header buffer size as the

58
00:04:33,280 --> 00:04:37,920
name suggests the amount of memory to allocate to reading request headers.

59
00:04:38,110 --> 00:04:41,980
One killer by being more than enough for 99 percent of requests.

60
00:04:42,100 --> 00:04:44,650
It is typically being a small amount of data.

61
00:04:45,070 --> 00:04:48,330
Then still fine tuning incoming requests.

62
00:04:48,400 --> 00:04:55,750
We have the two major client timeouts client body time out and client header time out both of which

63
00:04:55,780 --> 00:04:59,130
I have set to a very short 12 milliseconds.

64
00:04:59,160 --> 00:05:04,720
Importantly in this case the body timeout does not refer to the time it takes to transmit the entire

65
00:05:04,720 --> 00:05:09,310
request body but rather the time between consecutive read operations.

66
00:05:09,490 --> 00:05:11,830
Those reads that happen to the buffer.

67
00:05:11,830 --> 00:05:18,040
Both of these default to 60 seconds which in my opinion is way too long but again feel free to adjust

68
00:05:18,070 --> 00:05:20,650
as you see fit as before.

69
00:05:20,650 --> 00:05:27,850
Engine X allows us to sit times as either a number only like this which indicates milliseconds with

70
00:05:27,850 --> 00:05:35,200
an S for seconds all the way up to years which will obviously not ever be applicable to DirecTV such

71
00:05:35,200 --> 00:05:37,190
as these timeouts.

72
00:05:37,210 --> 00:05:40,720
Next we have the very important keep life time out.

73
00:05:40,960 --> 00:05:46,840
This directive sets the amount of time engineers should keep a connection to a clear and open for in

74
00:05:46,840 --> 00:05:49,140
case more data is on the way.

75
00:05:49,150 --> 00:05:54,670
This is extremely useful when say a client is requesting a number of files and keeping a connection

76
00:05:54,730 --> 00:05:58,350
open reduces the time it takes to open another new connection.

77
00:05:58,570 --> 00:06:04,810
Equally not wanting to leave connections open for too long as this can result in a pool of max connections

78
00:06:04,860 --> 00:06:05,590
this time.

79
00:06:05,620 --> 00:06:07,850
This being used up.

80
00:06:07,900 --> 00:06:09,910
Unlikely but quite disastrous.

81
00:06:09,910 --> 00:06:12,130
Should it happen for the most part.

82
00:06:12,130 --> 00:06:16,980
There's no reason a connection would have to stay open beyond a few milliseconds before continuing.

83
00:06:17,080 --> 00:06:22,300
And most clients will close connections properly meaning this time out won't even apply.

84
00:06:22,450 --> 00:06:24,370
But giving you have the server resources.

85
00:06:24,370 --> 00:06:28,080
Feel free to increase this number to even a couple of seconds.

86
00:06:28,240 --> 00:06:32,760
And our last time out being the all important send time out.

87
00:06:32,770 --> 00:06:38,860
Meaning if a client does not receive any of the response data in this amount of time doesn't have to

88
00:06:38,860 --> 00:06:40,190
be all of the response data.

89
00:06:40,210 --> 00:06:41,710
But none offered at all.

90
00:06:41,710 --> 00:06:44,120
A boughts ending the response all together.

91
00:06:45,020 --> 00:06:47,890
The last two directives I have here is somewhat unique.

92
00:06:48,080 --> 00:06:52,900
And for the vast majority of web service will provide a decent increase in performance.

93
00:06:53,150 --> 00:06:57,350
Send file meaning we're sending a client data from dusk.

94
00:06:57,380 --> 00:07:00,710
So typically a static fire like an image etc..

95
00:07:00,920 --> 00:07:02,650
Don't use a buffer.

96
00:07:02,690 --> 00:07:06,990
Read their data from the desk and write it directly to the response.

97
00:07:07,250 --> 00:07:14,790
With dcb no push enabling engine X to optimize the size of those data packets being sent to the client.

98
00:07:14,830 --> 00:07:20,300
Two very simple but incredibly valuable directives that will especially help optimize site with a large

99
00:07:20,300 --> 00:07:22,400
number of static resources.

100
00:07:22,910 --> 00:07:26,040
That wraps up the basics of buffers and time outs.

101
00:07:26,180 --> 00:07:31,810
And whilst this might be the most difficult aspect of an engine configuration to really fine tune I'd

102
00:07:31,820 --> 00:07:35,690
encourage you to give it a go but not worry about it too much.

103
00:07:35,690 --> 00:07:41,210
Most clients will open and close connections correctly without the need to be timed out or reject it.