Nginx Technology (1) Nginx High Concurrent introduction and Nginx installation

Nginx Introduction and Installation

One, why does nginx support high concurrency? The difference between Epoll and select

When developing high-performance Web programs, Windows developers will say that iocp,linux developers say they will epoll. Nginx is written in this way. We all know that Epoll is an IO multiplexing technology that can handle millions of socket handles very efficiently, compared to previous select and poll efficiencies. We use the epoll to feel very good, really fast, then, in the end why it can be high-speed processing so many concurrent connections?

Let's briefly review how to use the 3 Epoll system calls in the C library package.

Intepoll_create (intsize);
    
Intepoll_ctl (intepfd,intop,intfd,structepoll_event*event);
    
Intepoll_wait (Intepfd,structepoll_event*events,intmaxevents,inttimeout)

It is very clear to use, first call epoll_create to build a Epoll object. The size of the parameter is the maximum number of handles that the kernel guarantees to handle correctly, and the kernel does not guarantee the effect when more than this maximum number.

Epoll_ctl can manipulate the epoll created above, for example, add a socket that you just created to the Epoll to monitor it, or move a socket handle epoll is monitoring out of epoll, stop monitoring it, and so on.

Epoll_wait when invoked, returns the process of a user state within a given timeout time when an event occurs in all of the handles in the monitor.

You can see from the above how Epoll is superior to Select/poll: Because the latter passes all the sockets you want to monitor for select/poll system calls each time it is invoked, this means that you need to copy the socket list of the user state to the kernel state. It is very inefficient to copy a few Baisi KB of memory to the kernel state each time if the handle of the million is created. When we call epoll_wait, it's equivalent to calling Select/poll, but instead of passing the socket handle to the kernel, the kernel has already got a list of handles to monitor in Epoll_ctl.
Since the user state information has been saved to the kernel state while executing epoll_create and Epoll_ctrl
, and then even repeated calls to Epoll_wait will not duplicate the parameters, scan the file descriptor,
Repeatedly put the current process into/out of the waiting queue. This avoids the above three shortcomings.

So, in fact, after you call Epoll_create, the kernel is already in the kernel state ready to help you store the handles you want to monitor, and every time you call epoll_ctl you just plug in the new socket handle into the kernel's data structure.

In the kernel, everything is a document. Therefore, Epoll registers a file system with the kernel for storing the above monitored sockets. When you call Epoll_create, you create a file node in the virtual Epoll file system. Of course this file is not an ordinary document, it only serves the epoll.

Epoll when initialized by the kernel (operating system), and will open up the epoll of their own core high-speed cache, for each of us want to monitor the socket, these sockets will be in the form of red and black trees stored in the kernel cache, to support the rapid search, insert, delete. This kernel high speed cache area is to establish a continuous physical memory page, and then build the slab layer on top, simply put, is the physical allocation of the size you want the memory object, each time using the idle allocated objects.

Staticint__initeventpoll_init (void)
    
{
    
...
    
/*allocatesslabcacheusedtoallocate "Structepitem" items*/
    
epi_cache=kmem_cache_create ("Eventpoll_epi", sizeof (Structepitem),
    
0,slab_hwcache_align| Epi_slab_debug| Slab_panic,
    
null,null);
    
/*allocatesslabcacheusedtoallocate "Structeppoll_entry" * *
    
pwq_cache=kmem_cache_create ("Eventpoll_pwq",
    
sizeof (Structeppoll_entry), 0,
    
epi_slab_debug| Slab_panic,null,null);
    
......

The high efficiency of epoll is that when we call Epoll_ctl to cram in millions of handles, epoll_wait can still return quickly and effectively handle the handlers of the events that occur to our users. This is because we call the epoll_create, the kernel in addition to help us in the Epoll file system built a filename node, in the kernel cache built a red-black tree for storage after the epoll_ctl came from the socket, but also to create a list of lists, Used to store prepared events, and when Epoll_wait calls, just look at the list and see if there is any data. There is data to return, no data on the sleep, wait until timeout time, even if the list has no data to return. So, epoll_wait is very efficient.

And, usually even if we want to monitor the millions of handles, most of the time only return a very small number of prepared handle only, so, epoll_wait only need from the kernel copy a small number of handles to the user state, how can not be efficient?!

So, how do you maintain this list of ready lists? When we perform epoll_ctl, in addition to placing the socket in the red and black tree corresponding to the file object in the Epoll filesystem, a callback function is registered with the kernel interrupt handler, telling the kernel that if the handle is interrupted, it is placed in the list of Ready lists. So, when there is data on a socket, the kernel inserts the socket into the ready chain after the data on the network card is copy to the kernel.

So, a red-black tree, a ready handle linked list, a small number of kernel cache, to help us solve the large concurrent socket processing problems. When the epoll_create is executed, a red-black tree and a ready-list are created, and if you increase the socket handle when you execute the EPOLL_CTL, check for the presence of the red-black tree, the presence of immediate return, the absence of it, add to the trunk, and then register the callback function with the kernel. Used to insert data temporarily into the ready-ready list When an interrupt event occurs. Returns the data in the ready-to-ready chain as soon as the epoll_wait is executed.

Finally look at Epoll's unique two modes of LT and ET. Both the LT and ET modes are applicable to the process described above. The difference is that in LT mode, as long as the event on one handle is not finished once, the handle is returned at a later time when the epoll_wait is called, and the ET mode returns only the first time.

How did this happen? When there is an event on a socket handle, the kernel inserts the handle into the list of Ready lists listed above, and when we call epoll_wait, we copy the ready socket to the user state memory, then empty the Ready list, and finally, Epoll_ Wait to do a thing, is check these sockets, if not the ET mode (is the LT mode of the handle), and these sockets do have an unhandled event, then put the handle back to just empty the ready-ready linked list. So, non-et handles, as long as there are events above it, Epoll_wait will return every time. And the handle of the ET pattern, unless there is a new interrupt to, even if the event on the socket is not finished, it will not be returned from the epoll_wait again.

More Wonderful content: http://www.bianceng.cnhttp://www.bianceng.cn/Servers/web/