1
00:00:04,380 --> 00: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

2
00:00:10,730 --> 00:00:11,790
to Apache.

3
00:00:13,290 --> 00:00:14,080
By default.

4
00:00:14,100 --> 00:00:21,000
Apache is configured in what's called pre fork mode meaning that had spawned a set number of processors

5
00:00:21,090 --> 00:00:26,720
each of which can serve a single request at a time regardless of whether that request is for appear

6
00:00:26,740 --> 00:00:28,720
to be script or an image.

7
00:00:29,440 --> 00:00:36,010
Engine X on the other hand deals rutha requests asynchronously meaning that a single engine exe process

8
00:00:36,070 --> 00:00:42,280
can serve multiple requests concurrently with that number basically just depending on the system resources

9
00:00:42,280 --> 00:00:45,230
available to the engine x process.

10
00:00:45,250 --> 00:00:52,150
That said because if there's a synchronous design engine X unlike Apache can't embed server side programming

11
00:00:52,150 --> 00:00:58,630
languages into its own processes meaning that all requests for Dynamic Content has to be dealt with

12
00:00:58,630 --> 00:01:06,550
by a completely separate process like p.h. B if P. M. and then reverse proxy back to the client via

13
00:01:06,580 --> 00:01:08,120
engine X..

14
00:01:08,140 --> 00:01:14,110
Now this might sound somewhat overcomplicated but it's actually fairly simple to set up and will cover

15
00:01:14,110 --> 00:01:15,670
it in depth.

16
00:01:15,700 --> 00:01:21,280
Of course not having to deal directly with embedded programming languages like Apache does makes engine

17
00:01:21,280 --> 00:01:23,580
X a lot less resource hungry.

18
00:01:23,580 --> 00:01:29,050
Now this doesn't mean that the resources used for the processing of server side languages is simply

19
00:01:29,050 --> 00:01:30,210
freed up.

20
00:01:30,250 --> 00: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.

21
00:01:38,470 --> 00:01:45,160
But it does mean that unlike Apache server side language modules don't need to be run for every single

22
00:01:45,160 --> 00:01:47,740
request the server receives instead.

23
00:01:47,770 --> 00:01:52,730
Engine X will handle serving static resources without BHB ever knowing about it.

24
00:01:52,960 --> 00:01:57,200
Whereas Apache will handle every request with that costly overhead.

25
00:01:57,430 --> 00:02:02,510
And this is exactly where the real world savings on system resources come into effect.

26
00:02:02,590 --> 00:02:08,650
So essentially a well configured engine XT web servers serving mixed content meaning both static and

27
00:02:08,650 --> 00:02:15,490
dynamic resources should always be more efficient and less demanding on system resources than a similar

28
00:02:15,490 --> 00:02:17,190
Apache set up.

29
00:02:17,350 --> 00:02:23,380
How does this relate to performance then you most likely read or heard that engine X is faster than

30
00:02:23,380 --> 00:02:24,270
Apache.

31
00:02:24,310 --> 00:02:28,690
After all one of engine Xist Corps develop and focus this was that of performance.

32
00:02:28,870 --> 00:02:33,180
But it's really important to first define what's meant by fast.

33
00:02:33,190 --> 00:02:38,440
Engine X can't magically deliver data to the client any faster than the internet connection will allow.

34
00:02:38,800 --> 00:02:47,770
But it can a serve static resources much faster than Apache and B handle a much larger number of concurrent

35
00:02:47,770 --> 00:02:49,290
requests.

36
00:02:49,300 --> 00:02:54,610
Remember engine X will serve static resources without the need to involve any server side languages.

37
00:02:54,610 --> 00:02:57,500
And this gives it quite an advantage over Apache.

38
00:02:57,580 --> 00:03:03,070
And as for handling concurrent requests engine X can potentially receive thousands of requests on a

39
00:03:03,070 --> 00:03:10,000
single processing thread and respond to them as fast as it can without turning down any of those requests.

40
00:03:10,120 --> 00:03:15,610
Apache on the other hand will accept a request up to the preconfigured number and then simply reject

41
00:03:15,610 --> 00:03:16,770
the rest.

42
00:03:16,780 --> 00:03:23,230
So if we define performance or being fast in terms of how many clients can be served under high load

43
00:03:23,590 --> 00:03:29,830
assuming the usual mix of static and dynamic resources then yes engine exist differently faster than

44
00:03:29,830 --> 00:03:30,850
Apache.

45
00:03:32,460 --> 00:03:37,950
Engine X is configuration also takes a very different approach to have patches in their requests.

46
00:03:37,950 --> 00:03:39,540
I interpret it as you are right.

47
00:03:39,540 --> 00:03:46,540
Locations first whereas Apache default to and highly favours filesystem locations.

48
00:03:46,770 --> 00:03:52,620
This preference for file system locations can also be seen in the use of h.t. access files for overriding

49
00:03:52,620 --> 00:03:55,080
specific directory configurations.

50
00:03:55,170 --> 00:03:57,850
Engine X doesn't offer any similar functionality.

51
00:03:57,900 --> 00:04:03,510
But seeing as apache's h.t. Axis overrides carrière significant performance penalty.

52
00:04:03,510 --> 00:04:06,330
They shouldn't really be considered an advantage.

53
00:04:06,330 --> 00:04:09,620
It's also because of this very design of interpreting requests.

54
00:04:09,660 --> 00:04:16,470
As you are locations that allows engine extra easily function as not only a web server but anything

55
00:04:16,470 --> 00:04:18,970
from a load balancer to a mail server.

56
00:04:19,720 --> 00:04:24,130
That brings us to the end of this video and hopefully you now have a better understanding of what engine

57
00:04:24,130 --> 00: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

58
00:04:30,550 --> 00:04:31,170
X..