Changes in / [67a1c67:9d67a6d]

File:

• doc/theses/thierry_delisle_PhD/thesis/text/eval_macro.tex (modified) (4 diffs)

doc/theses/thierry_delisle_PhD/thesis/text/eval_macro.tex

@@ -180 +180 @@
 
 \subsection{NGINX threading}
+NGINX is an high-performance, \emph{full-service}, event-driven webserver.
+It can handle both static and dynamic web content, as well as serve as a reverse proxy and a load balancer~\cite{reese2008nginx}.
+This wealth of features comes with a variety of potential configuration, dictating both available features and performance.
+The NGINX server runs a master process that performs operations such as reading configuration files, binding to ports, and controlling worker processes.
+When running as a static webserver, uses an event driven architecture to server incoming requests.
+Incoming connections are assigned a \emph{statckless} HTTP state-machine and worker processes can potentially handle thousands of these state machines.
+For the following experiment, NGINX was configured to use epoll to listen for events on these state machines and have each worker process independently accept new connections.
+Because of the realities of Linux, see Subsection~\ref{ononblock}, NGINX also maintains a pool of auxilary threads to handle block \io.
+The configuration can be used to set the number of worker processes desired, as well as the size of the auxilary pool.
+However, for the following experiments NGINX was configured to let the master process decided the appropriate number of threads.
+
+
 % Like memcached, NGINX can be made to use multiple \glspl{kthrd}.
 % It has a very similar architecture to the memcached architecture described in Section~\ref{memcd:thrd}, where multiple \glspl{kthrd} each run a mostly independent network logic.
@@ -185 +197 @@
 % Each worker thread handles multiple connections exclusively, effectively dividing the connections into distinct sets.
 % Again, this is effectively the \emph{event-based server} approach.
-% 
+%
 % \cit{https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/}
 
-NGINX 1.13.7 is an high-performance, \emph{full-service}, event-driven, with multiple operating-system processes or multiple kernel-threads within a process to handle blocking I/O.
-It can also serve as a reverse proxy and a load balancer~\cite{reese2008nginx}.
-Concurrent connections are handled using a complex event-driven architecture.
-The NGINX server runs a master process that performs operations such as reading configuration files, binding to ports, and controlling worker processes.
-NGINX uses a disk-based cache for performance, and assigns a dedicated process to manage the cache.
-This process, known as the \textit{cache manager}, is spun-off by the master process.
-Additionally, there can be many \textit{worker processes}, each handling network connections, reading and writing disk files, and communicating with upstream servers, such as reverse proxies or databases.
-
-A worker is a single-threaded process, running independently of other workers.
-The worker process handles new incoming connections and processes them.
-Workers communicate using shared memory for shared cache and session data, and other shared resources.
-Each worker assigns incoming connections to an HTTP state-machine.
-As in a typical event-driven architecture, the worker listens for events from the clients, and responds immediately without blocking.
-Memory use in NGINX is very conservative, because it does not spin up a new process or thread per connection, like Apache~\cite{apache} or \CFA.
-All operations are asynchronous -- implemented using event notifications, callback functions and fine-tuned timers.
+% NGINX 1.13.7 is an high-performance, \emph{full-service}, event-driven, with multiple operating-system processes or multiple kernel-threads within a process to handle blocking I/O.
+% It can also .
+% Concurrent connections are handled using a complex event-driven architecture.
+% The NGINX server runs a master process that performs operations such as reading configuration files, binding to ports, and controlling worker processes.
+% NGINX uses a disk-based cache for performance, and assigns a dedicated process to manage the cache.
+% This process, known as the \textit{cache manager}, is spun-off by the master process.
+% Additionally, there can be many \textit{worker processes}, each handling network connections, reading and writing disk files, and communicating with upstream servers, such as reverse proxies or databases.
+
+% A worker is a single-threaded process, running independently of other workers.
+% The worker process handles new incoming connections and processes them.
+% Workers communicate using shared memory for shared cache and session data, and other shared resources.
+% Each worker assigns
+% As in a typical event-driven architecture, the worker listens for events from the clients, and responds immediately without blocking.
+% Memory use in NGINX is very conservative, because it does not spin up a new process or thread per connection, like Apache~\cite{apache} or \CFA.
+% All operations are asynchronous -- implemented using event notifications, callback functions and fine-tuned timers.
 
 \subsection{\CFA webserver}
@@ -227 +239 @@
 This effect results in a negative feedback where more timeouts lead to more @sendfile@ calls running out of resources.
 
-Normally, this problem is address by using @select@/@epoll@ to wait for sockets to have sufficient resources.
+Normally, this problem is addressed by using @select@/@epoll@ to wait for sockets to have sufficient resources.
 However, since @io_uring@ does not support @sendfile@ but does respects non\-blocking semantics, marking all sockets as non-blocking effectively circumvents the @io_uring@ subsystem entirely:
 all calls simply immediately return @EAGAIN@ and all asynchronicity is lost.
@@ -363 +375 @@
 However, I felt this kind of modification moves too far away from my goal of evaluating the \CFA runtime, \ie it begins writing another runtime system;
 hence, I decided to forgo experiments on low-memory performance.
-% The implementation of the webserver itself is simply too impactful to be an interesting evaluation of the underlying runtime.