WEBVTT 00:05.230 --> 00:12.140 Throughout this course when checking their engineers processor status via either system D or B S we've 00:12.160 --> 00:17.690 seen this differentiation between a Master process and a worker process. 00:17.710 --> 00:24.010 So in this case and we'll cover what we're seeing here and how to optimize these engine X processors. 00:24.070 --> 00:31.000 First off know that the master process is the actual engine ex service or software instance which we 00:31.010 --> 00:34.920 started that Master process or engine IX itself. 00:35.110 --> 00:41.360 Then Spawn's work processes which listens for and respond to client requests. 00:41.620 --> 00:47.980 The default number of worker processes for engine X being one which is what we are seeing here to change 00:47.980 --> 00:50.360 the number of worker processes engine exported. 00:50.360 --> 00:56.810 Then we can use the worker underscore processes directive over the engine next of kin. 00:57.100 --> 01:03.130 We'll discuss how to configure this correctly in a second but to demonstrate in the main context we 01:03.130 --> 01:10.770 can set worker processes to save this reload the configuration. 01:12.900 --> 01:20.100 And check engine Xist status again which confirms engine exist now running to work processes list this 01:20.100 --> 01:25.800 via the process command as well be s filtering for engine X only. 01:25.800 --> 01:28.440 And the same although this way round. 01:28.440 --> 01:30.930 We also get to see the process owner. 01:30.930 --> 01:35.940 W w w dashed data as we configured it in the previous lesson. 01:36.360 --> 01:42.910 Now increasing the number of workers engineers Spawn's doesn't necessarily equate to better performance. 01:42.930 --> 01:48.690 If you recall from earlier in the course when we discussed the architecture of engine X and engine x 01:48.690 --> 01:56.100 process specifically these worker process S handling requests is asynchronous meaning they will handle 01:56.130 --> 02:02.850 incoming requests as fast as the hardware is capable of and creating a second worker process simply 02:02.850 --> 02:05.760 does not increase the hardaway's ability. 02:05.790 --> 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 02:12.570 --> 02:13.430 core. 02:13.620 --> 02:21.750 So a dual core quad core or even OK to core those cores cannot share processes meaning a single engine 02:21.750 --> 02:26.590 X worker process can only ever run on a single c b you call. 02:26.760 --> 02:29.480 And with that basic knowledge then we can. 02:29.490 --> 02:35.920 99 percent of the time configure engine X to run the exact number of processes as the server see you 02:35.940 --> 02:36.350 has. 02:36.380 --> 02:39.390 Cause it's just that simple. 02:39.450 --> 02:44.400 So if you're tempted to create a higher number of worker processes in the hope that your server will 02:44.400 --> 02:45.750 perform better. 02:45.780 --> 02:52.560 Think of two worker processes on a single core as having two workers capable of only running at 50 percent 02:52.980 --> 02:57.540 instead of one dedicated process running optimally at 100 percent. 02:57.600 --> 03:03.120 A much better alternative which will see demonstrated in the configuration in a second. 03:03.180 --> 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 03:09.390 --> 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 03:17.880 --> 03:21.000 single core digital ocean virtual machine. 03:21.060 --> 03:26.070 The second command which will give you some more detailed information is Ellis. 03:26.130 --> 03:33.380 CB You and there we have it quite verbose but useful to know with the number of s.p. you caused. 03:33.380 --> 03:36.340 Listed right here as B use. 03:36.660 --> 03:39.420 So knowing this then it's as simple as sitting. 03:39.420 --> 03:45.830 I will work a process this directive to that number for example 2 should I have a dual course. 03:45.840 --> 03:47.130 P U. 03:47.130 --> 03:54.450 But as I mentioned engine X gives us a very simple way of automating this by simply sitting this directive 03:54.480 --> 03:55.730 to auto. 03:55.950 --> 04:02.730 Remember the default is one worker but setting this to auto instead will do exactly what we just discussed 04:02.970 --> 04:11.320 sporn ONE worker for each cpq Core we can see this save reload the configuration. 04:12.210 --> 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. 04:20.670 --> 04:27.430 The next related directive will finally jump us into this event context worker connections. 04:27.450 --> 04:29.130 This sets the number of connections. 04:29.160 --> 04:36.090 Each worker process can except again not a number we can simply increase your server has a limit to 04:36.090 --> 04:38.700 how many files can be opened at once. 04:38.710 --> 04:46.730 For again each cpq Core we can again quickly check that open fire limit by running you limit. 04:46.730 --> 04:48.190 Were there any flag. 04:48.390 --> 04:50.610 A thousand and twenty four. 04:50.610 --> 04:55.870 Meaning that we can set this directive to that number in order to really Max out the server. 04:56.070 --> 05:01.200 Very importantly note that we now also have the maximum number of concurrent requests. 05:01.200 --> 05:09.060 Our server should be able to accept work processes times worker connections as each of these worker 05:09.090 --> 05:13.190 processes can open this many connections or requests. 05:13.290 --> 05:18.490 These two directives being the most important to understand in order to really optimize the engineers 05:18.570 --> 05:20.780 process for performance. 05:20.910 --> 05:24.530 The last directive I want to demonstrate is the I.D. directive. 05:24.750 --> 05:30.160 If you recall from the installation section of the Course we set the default location for the engine 05:30.160 --> 05:33.350 next process eidy during the configure step. 05:33.390 --> 05:36.700 What this directive allows us to do then is reconfigure the process. 05:36.720 --> 05:43.760 Eidy location via the configuration file so at the moment our P E file is located at. 05:43.760 --> 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. 05:53.040 --> 05:58.800 But let's say for whichever reason we need to change this without rebuilding in generics we can use 05:58.830 --> 06:00.110 this directive. 06:00.180 --> 06:08.810 I'll make it slash var slash run so same directory new underscore engine ixtoc B I d save. 06:11.410 --> 06:12.440 Reload. 06:14.390 --> 06:20.770 List everything starting with N again and we get that new process idae file in the next lesson will 06:20.780 --> 06:25.470 take these performance tweaks one step further and look at buffers and time outs.