Throughout this course when checking their engineers processor status via either system D or B S we've
seen this differentiation between a Master process and a worker process.
So in this case and we'll cover what we're seeing here and how to optimize these engine X processors.
First off know that the master process is the actual engine ex service or software instance which we
started that Master process or engine IX itself.
Then Spawn's work processes which listens for and respond to client requests.
The default number of worker processes for engine X being one which is what we are seeing here to change
the number of worker processes engine exported.
Then we can use the worker underscore processes directive over the engine next of kin.
We'll discuss how to configure this correctly in a second but to demonstrate in the main context we
can set worker processes to save this reload the configuration.
And check engine Xist status again which confirms engine exist now running to work processes list this
via the process command as well be s filtering for engine X only.
And the same although this way round.
We also get to see the process owner.
W w w dashed data as we configured it in the previous lesson.
Now increasing the number of workers engineers Spawn's doesn't necessarily equate to better performance.
If you recall from earlier in the course when we discussed the architecture of engine X and engine x
process specifically these worker process S handling requests is asynchronous meaning they will handle
incoming requests as fast as the hardware is capable of and creating a second worker process simply
does not increase the hardaway's ability.
That said without going into too much detail of how C B use work when we have more than one C B You
core.
So a dual core quad core or even OK to core those cores cannot share processes meaning a single engine
X worker process can only ever run on a single c b you call.
And with that basic knowledge then we can.
99 percent of the time configure engine X to run the exact number of processes as the server see you
has.
Cause it's just that simple.
So if you're tempted to create a higher number of worker processes in the hope that your server will
perform better.
Think of two worker processes on a single core as having two workers capable of only running at 50 percent
instead of one dedicated process running optimally at 100 percent.
A much better alternative which will see demonstrated in the configuration in a second.
At this point you might very well know how many cores your server has but if not we have two basic commands
that will tell us first that the simplest of the two run n proc and I get one as this is a very basic
single core digital ocean virtual machine.
The second command which will give you some more detailed information is Ellis.
CB You and there we have it quite verbose but useful to know with the number of s.p. you caused.
Listed right here as B use.
So knowing this then it's as simple as sitting.
I will work a process this directive to that number for example 2 should I have a dual course.
P U.
But as I mentioned engine X gives us a very simple way of automating this by simply sitting this directive
to auto.
Remember the default is one worker but setting this to auto instead will do exactly what we just discussed
sporn ONE worker for each cpq Core we can see this save reload the configuration.
And when I now check this status engine X is back to one worker as per the number of calls on this machine.
The next related directive will finally jump us into this event context worker connections.
This sets the number of connections.
Each worker process can except again not a number we can simply increase your server has a limit to
how many files can be opened at once.
For again each cpq Core we can again quickly check that open fire limit by running you limit.
Were there any flag.
A thousand and twenty four.
Meaning that we can set this directive to that number in order to really Max out the server.
Very importantly note that we now also have the maximum number of concurrent requests.
Our server should be able to accept work processes times worker connections as each of these worker
processes can open this many connections or requests.
These two directives being the most important to understand in order to really optimize the engineers
process for performance.
The last directive I want to demonstrate is the I.D. directive.
If you recall from the installation section of the Course we set the default location for the engine
next process eidy during the configure step.
What this directive allows us to do then is reconfigure the process.
Eidy location via the configuration file so at the moment our P E file is located at.
Var run check for file starting with N their var run engine next door P R E D as we configured it.
But let's say for whichever reason we need to change this without rebuilding in generics we can use
this directive.
I'll make it slash var slash run so same directory new underscore engine ixtoc B I d save.
Reload.
List everything starting with N again and we get that new process idae file in the next lesson will
take these performance tweaks one step further and look at buffers and time outs.