1
00:00:05,230 --> 00:00:12,140
Throughout this course when checking their engineers processor status via either system D or B S we've

2
00:00:12,160 --> 00:00:17,690
seen this differentiation between a Master process and a worker process.

3
00:00:17,710 --> 00:00:24,010
So in this case and we'll cover what we're seeing here and how to optimize these engine X processors.

4
00:00:24,070 --> 00:00:31,000
First off know that the master process is the actual engine ex service or software instance which we

5
00:00:31,010 --> 00:00:34,920
started that Master process or engine IX itself.

6
00:00:35,110 --> 00:00:41,360
Then Spawn's work processes which listens for and respond to client requests.

7
00:00:41,620 --> 00:00:47,980
The default number of worker processes for engine X being one which is what we are seeing here to change

8
00:00:47,980 --> 00:00:50,360
the number of worker processes engine exported.

9
00:00:50,360 --> 00:00:56,810
Then we can use the worker underscore processes directive over the engine next of kin.

10
00:00:57,100 --> 00:01:03,130
We'll discuss how to configure this correctly in a second but to demonstrate in the main context we

11
00:01:03,130 --> 00:01:10,770
can set worker processes to save this reload the configuration.

12
00:01:12,900 --> 00:01:20,100
And check engine Xist status again which confirms engine exist now running to work processes list this

13
00:01:20,100 --> 00:01:25,800
via the process command as well be s filtering for engine X only.

14
00:01:25,800 --> 00:01:28,440
And the same although this way round.

15
00:01:28,440 --> 00:01:30,930
We also get to see the process owner.

16
00:01:30,930 --> 00:01:35,940
W w w dashed data as we configured it in the previous lesson.

17
00:01:36,360 --> 00:01:42,910
Now increasing the number of workers engineers Spawn's doesn't necessarily equate to better performance.

18
00:01:42,930 --> 00:01:48,690
If you recall from earlier in the course when we discussed the architecture of engine X and engine x

19
00:01:48,690 --> 00:01:56,100
process specifically these worker process S handling requests is asynchronous meaning they will handle

20
00:01:56,130 --> 00:02:02,850
incoming requests as fast as the hardware is capable of and creating a second worker process simply

21
00:02:02,850 --> 00:02:05,760
does not increase the hardaway's ability.

22
00:02:05,790 --> 00:02:12,540
That said without going into too much detail of how C B use work when we have more than one C B You

23
00:02:12,570 --> 00:02:13,430
core.

24
00:02:13,620 --> 00:02:21,750
So a dual core quad core or even OK to core those cores cannot share processes meaning a single engine

25
00:02:21,750 --> 00:02:26,590
X worker process can only ever run on a single c b you call.

26
00:02:26,760 --> 00:02:29,480
And with that basic knowledge then we can.

27
00:02:29,490 --> 00:02:35,920
99 percent of the time configure engine X to run the exact number of processes as the server see you

28
00:02:35,940 --> 00:02:36,350
has.

29
00:02:36,380 --> 00:02:39,390
Cause it's just that simple.

30
00:02:39,450 --> 00:02:44,400
So if you're tempted to create a higher number of worker processes in the hope that your server will

31
00:02:44,400 --> 00:02:45,750
perform better.

32
00:02:45,780 --> 00:02:52,560
Think of two worker processes on a single core as having two workers capable of only running at 50 percent

33
00:02:52,980 --> 00:02:57,540
instead of one dedicated process running optimally at 100 percent.

34
00:02:57,600 --> 00:03:03,120
A much better alternative which will see demonstrated in the configuration in a second.

35
00:03:03,180 --> 00:03:09,360
At this point you might very well know how many cores your server has but if not we have two basic commands

36
00:03:09,390 --> 00:03:17,880
that will tell us first that the simplest of the two run n proc and I get one as this is a very basic

37
00:03:17,880 --> 00:03:21,000
single core digital ocean virtual machine.

38
00:03:21,060 --> 00:03:26,070
The second command which will give you some more detailed information is Ellis.

39
00:03:26,130 --> 00:03:33,380
CB You and there we have it quite verbose but useful to know with the number of s.p. you caused.

40
00:03:33,380 --> 00:03:36,340
Listed right here as B use.

41
00:03:36,660 --> 00:03:39,420
So knowing this then it's as simple as sitting.

42
00:03:39,420 --> 00:03:45,830
I will work a process this directive to that number for example 2 should I have a dual course.

43
00:03:45,840 --> 00:03:47,130
P U.

44
00:03:47,130 --> 00:03:54,450
But as I mentioned engine X gives us a very simple way of automating this by simply sitting this directive

45
00:03:54,480 --> 00:03:55,730
to auto.

46
00:03:55,950 --> 00:04:02,730
Remember the default is one worker but setting this to auto instead will do exactly what we just discussed

47
00:04:02,970 --> 00:04:11,320
sporn ONE worker for each cpq Core we can see this save reload the configuration.

48
00:04:12,210 --> 00:04:18,990
And when I now check this status engine X is back to one worker as per the number of calls on this machine.

49
00:04:20,670 --> 00:04:27,430
The next related directive will finally jump us into this event context worker connections.

50
00:04:27,450 --> 00:04:29,130
This sets the number of connections.

51
00:04:29,160 --> 00:04:36,090
Each worker process can except again not a number we can simply increase your server has a limit to

52
00:04:36,090 --> 00:04:38,700
how many files can be opened at once.

53
00:04:38,710 --> 00:04:46,730
For again each cpq Core we can again quickly check that open fire limit by running you limit.

54
00:04:46,730 --> 00:04:48,190
Were there any flag.

55
00:04:48,390 --> 00:04:50,610
A thousand and twenty four.

56
00:04:50,610 --> 00:04:55,870
Meaning that we can set this directive to that number in order to really Max out the server.

57
00:04:56,070 --> 00:05:01,200
Very importantly note that we now also have the maximum number of concurrent requests.

58
00:05:01,200 --> 00:05:09,060
Our server should be able to accept work processes times worker connections as each of these worker

59
00:05:09,090 --> 00:05:13,190
processes can open this many connections or requests.

60
00:05:13,290 --> 00:05:18,490
These two directives being the most important to understand in order to really optimize the engineers

61
00:05:18,570 --> 00:05:20,780
process for performance.

62
00:05:20,910 --> 00:05:24,530
The last directive I want to demonstrate is the I.D. directive.

63
00:05:24,750 --> 00:05:30,160
If you recall from the installation section of the Course we set the default location for the engine

64
00:05:30,160 --> 00:05:33,350
next process eidy during the configure step.

65
00:05:33,390 --> 00:05:36,700
What this directive allows us to do then is reconfigure the process.

66
00:05:36,720 --> 00:05:43,760
Eidy location via the configuration file so at the moment our P E file is located at.

67
00:05:43,760 --> 00:05:52,930
Var run check for file starting with N their var run engine next door P R E D as we configured it.

68
00:05:53,040 --> 00:05:58,800
But let's say for whichever reason we need to change this without rebuilding in generics we can use

69
00:05:58,830 --> 00:06:00,110
this directive.

70
00:06:00,180 --> 00:06:08,810
I'll make it slash var slash run so same directory new underscore engine ixtoc B I d save.

71
00:06:11,410 --> 00:06:12,440
Reload.

72
00:06:14,390 --> 00:06:20,770
List everything starting with N again and we get that new process idae file in the next lesson will

73
00:06:20,780 --> 00:06:25,470
take these performance tweaks one step further and look at buffers and time outs.