In the previous lesson we learned how to configure our engineers processes for the best performance.
So in this lesson we'll take a slightly more detailed look at optimizing those processes by configuring
buffer sizes and time.
This time around instead of adding these configurations during the lesson I've added them in advance
as there's nothing really to demonstrate.
If you want to copy these into your own configuration as a starting point the filas Linked In the resources.
As with previous lessons now before I start explaining the function of these additions Please note that
whilst configuring process this is fairly easy and measurable task buffer sizes and time out is the
complete opposite.
This being as they are not so much dependent on the server but more the nature of the requests to the
server.
In fact I'd suggest leaving these as they default values.
If you're unsure about why you're tweaking them at all nonetheless it's very important to understand
the important ones and know how to change them should you ever need to.
First up then let's discuss in brief what a buffer is.
Buffering is when a process or an engine X worker in this case reads data into memory or RAM before
writing it to its next destination.
For example engine X receives a request which it reads from ATC tcap Bought port 80 in this case writes
that request data to memory which is buffering.
Or if the buffer is too small for the amount of data being read write some of it to disk.
The opposite of this then is that engine X response to a request with say a static file which it reads
from disk into memory so buffering the file and send that data to the client from memory.
This happens as the name implies to create a buffer or layer of protection between reading and writing
of data.
A process which can get extremely complicated but for the purposes of configuring engine X just have
an understanding of what it is.
In order to better understand configuring these directives timeouts are pretty self-explanatory.
They simply suggest a cut off time for a given event.
Or example.
If receiving a request from a client stop after a certain number of seconds thus preventing a client
from sending an endless stream of data and eventually breaking the server.
OK.
The first directive we have here then in the HTP context so essentially applying to our entire configuration
is the client body buffer size.
This directive then setting the amount of memory to allocate for buffering the post data from a client
post data most likely coming from a form submission which in this case is set to 10 k or 10 kilobits
for data sizes.
Engine X support a plane number for example one hundred which would equate to bytes 10 k as we have
it year which equates to killer bytes or 10 m for megabytes these can be written as either upper or
lower case.
I've linked to the documentation for these units in Texas in the resources so why 10 k then.
Well in this case no reason other than a basic form submission should be well under that.
Increasing this number to more than what we need will allocate and essentially waste memory on our server
and making a too small will require engine X to write part of this buffer to disk which is a lot slower
than writing it to memory.
Your website might very well rely on much larger form submissions in which case you'll definitely want
to increase this.
Again very specific to the nature of requests your server is likely to receive.
Second Then we have client Max body size set to 8 megabytes.
Meaning don't accept post requests of more than 8 megabytes.
If it is larger than 8 Make the server will respond with a 4 1 3 error which is request entity too large.
Again this being a safety measure to ensure a user doesn't mistakenly or maliciously send a very large
post request which could cause the server to slow down.
Use up a lot of disk space etc..
8 meg being a fairly safe element that should still allow most standard images to be uploaded and so
on.
Those two directives dealing with post requests the next one is the client header buffer size as the
name suggests the amount of memory to allocate to reading request headers.
One killer by being more than enough for 99 percent of requests.
It is typically being a small amount of data.
Then still fine tuning incoming requests.
We have the two major client timeouts client body time out and client header time out both of which
I have set to a very short 12 milliseconds.
Importantly in this case the body timeout does not refer to the time it takes to transmit the entire
request body but rather the time between consecutive read operations.
Those reads that happen to the buffer.
Both of these default to 60 seconds which in my opinion is way too long but again feel free to adjust
as you see fit as before.
Engine X allows us to sit times as either a number only like this which indicates milliseconds with
an S for seconds all the way up to years which will obviously not ever be applicable to DirecTV such
as these timeouts.
Next we have the very important keep life time out.
This directive sets the amount of time engineers should keep a connection to a clear and open for in
case more data is on the way.
This is extremely useful when say a client is requesting a number of files and keeping a connection
open reduces the time it takes to open another new connection.
Equally not wanting to leave connections open for too long as this can result in a pool of max connections
this time.
This being used up.
Unlikely but quite disastrous.
Should it happen for the most part.
There's no reason a connection would have to stay open beyond a few milliseconds before continuing.
And most clients will close connections properly meaning this time out won't even apply.
But giving you have the server resources.
Feel free to increase this number to even a couple of seconds.
And our last time out being the all important send time out.
Meaning if a client does not receive any of the response data in this amount of time doesn't have to
be all of the response data.
But none offered at all.
A boughts ending the response all together.
The last two directives I have here is somewhat unique.
And for the vast majority of web service will provide a decent increase in performance.
Send file meaning we're sending a client data from dusk.
So typically a static fire like an image etc..
Don't use a buffer.
Read their data from the desk and write it directly to the response.
With dcb no push enabling engine X to optimize the size of those data packets being sent to the client.
Two very simple but incredibly valuable directives that will especially help optimize site with a large
number of static resources.
That wraps up the basics of buffers and time outs.
And whilst this might be the most difficult aspect of an engine configuration to really fine tune I'd
encourage you to give it a go but not worry about it too much.
Most clients will open and close connections correctly without the need to be timed out or reject it.