WEBVTT 00:04.380 --> 00:10.730 In this video we'll take a look at engine exis design as a reverse proxy server and see how it compares 00:10.730 --> 00:11.790 to Apache. 00:13.290 --> 00:14.080 By default. 00:14.100 --> 00:21.000 Apache is configured in what's called pre fork mode meaning that had spawned a set number of processors 00:21.090 --> 00:26.720 each of which can serve a single request at a time regardless of whether that request is for appear 00:26.740 --> 00:28.720 to be script or an image. 00:29.440 --> 00:36.010 Engine X on the other hand deals rutha requests asynchronously meaning that a single engine exe process 00:36.070 --> 00:42.280 can serve multiple requests concurrently with that number basically just depending on the system resources 00:42.280 --> 00:45.230 available to the engine x process. 00:45.250 --> 00:52.150 That said because if there's a synchronous design engine X unlike Apache can't embed server side programming 00:52.150 --> 00:58.630 languages into its own processes meaning that all requests for Dynamic Content has to be dealt with 00:58.630 --> 01:06.550 by a completely separate process like p.h. B if P. M. and then reverse proxy back to the client via 01:06.580 --> 01:08.120 engine X.. 01:08.140 --> 01:14.110 Now this might sound somewhat overcomplicated but it's actually fairly simple to set up and will cover 01:14.110 --> 01:15.670 it in depth. 01:15.700 --> 01:21.280 Of course not having to deal directly with embedded programming languages like Apache does makes engine 01:21.280 --> 01:23.580 X a lot less resource hungry. 01:23.580 --> 01:29.050 Now this doesn't mean that the resources used for the processing of server side languages is simply 01:29.050 --> 01:30.210 freed up. 01:30.250 --> 01:38.470 Rather they are being allocated elsewhere like in the most common case of BHB to the p s p f P. M. process. 01:38.470 --> 01:45.160 But it does mean that unlike Apache server side language modules don't need to be run for every single 01:45.160 --> 01:47.740 request the server receives instead. 01:47.770 --> 01:52.730 Engine X will handle serving static resources without BHB ever knowing about it. 01:52.960 --> 01:57.200 Whereas Apache will handle every request with that costly overhead. 01:57.430 --> 02:02.510 And this is exactly where the real world savings on system resources come into effect. 02:02.590 --> 02:08.650 So essentially a well configured engine XT web servers serving mixed content meaning both static and 02:08.650 --> 02:15.490 dynamic resources should always be more efficient and less demanding on system resources than a similar 02:15.490 --> 02:17.190 Apache set up. 02:17.350 --> 02:23.380 How does this relate to performance then you most likely read or heard that engine X is faster than 02:23.380 --> 02:24.270 Apache. 02:24.310 --> 02:28.690 After all one of engine Xist Corps develop and focus this was that of performance. 02:28.870 --> 02:33.180 But it's really important to first define what's meant by fast. 02:33.190 --> 02:38.440 Engine X can't magically deliver data to the client any faster than the internet connection will allow. 02:38.800 --> 02:47.770 But it can a serve static resources much faster than Apache and B handle a much larger number of concurrent 02:47.770 --> 02:49.290 requests. 02:49.300 --> 02:54.610 Remember engine X will serve static resources without the need to involve any server side languages. 02:54.610 --> 02:57.500 And this gives it quite an advantage over Apache. 02:57.580 --> 03:03.070 And as for handling concurrent requests engine X can potentially receive thousands of requests on a 03:03.070 --> 03:10.000 single processing thread and respond to them as fast as it can without turning down any of those requests. 03:10.120 --> 03:15.610 Apache on the other hand will accept a request up to the preconfigured number and then simply reject 03:15.610 --> 03:16.770 the rest. 03:16.780 --> 03:23.230 So if we define performance or being fast in terms of how many clients can be served under high load 03:23.590 --> 03:29.830 assuming the usual mix of static and dynamic resources then yes engine exist differently faster than 03:29.830 --> 03:30.850 Apache. 03:32.460 --> 03:37.950 Engine X is configuration also takes a very different approach to have patches in their requests. 03:37.950 --> 03:39.540 I interpret it as you are right. 03:39.540 --> 03:46.540 Locations first whereas Apache default to and highly favours filesystem locations. 03:46.770 --> 03:52.620 This preference for file system locations can also be seen in the use of h.t. access files for overriding 03:52.620 --> 03:55.080 specific directory configurations. 03:55.170 --> 03:57.850 Engine X doesn't offer any similar functionality. 03:57.900 --> 04:03.510 But seeing as apache's h.t. Axis overrides carrière significant performance penalty. 04:03.510 --> 04:06.330 They shouldn't really be considered an advantage. 04:06.330 --> 04:09.620 It's also because of this very design of interpreting requests. 04:09.660 --> 04:16.470 As you are locations that allows engine extra easily function as not only a web server but anything 04:16.470 --> 04:18.970 from a load balancer to a mail server. 04:19.720 --> 04:24.130 That brings us to the end of this video and hopefully you now have a better understanding of what engine 04:24.130 --> 04:30.550 X is and why we want to use it in the next section of the Course we'll get started with installing engine 04:30.550 --> 04:31.170 X..