Changeset 4ab54c9 for doc/theses/thierry_delisle_PhD/thesis
- Timestamp:
- Sep 12, 2022, 4:05:28 PM (2 years ago)
- Branches:
- ADT, ast-experimental, master, pthread-emulation
- Children:
- 1c334d1
- Parents:
- 5548175
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/thierry_delisle_PhD/thesis/text/eval_macro.tex
r5548175 r4ab54c9 2 2 The previous chapter demonstrated the \CFA scheduler achieves its equivalent performance goal in small and controlled \at-scheduling scenarios. 3 3 The next step is to demonstrate performance stays true in more realistic and complete scenarios. 4 Therefore, this chapter exercises both \at and I/O scheduling using two flavours of web servers that demonstrate \CFA performs competitively withproduction environments.5 6 Web servers are chosen because they offer fairly simple applications that perform complex I/O, both network and disk, and are useful as standalone products.7 Furthermore, web servers are generally amenable to parallelization since their workloads are mostly homogeneous.8 Therefore, web servers offer a stringent performance benchmark for \CFA.9 Indeed, existing web servers have close to optimal performance, while the homogeneity of the workload means fairness may not be a problem.4 Therefore, this chapter exercises both \at and I/O scheduling using two flavours of web servers that demonstrate \CFA performs competitively compared to web servers used in production environments. 5 6 Web servers are chosen because they offer fairly simple applications that perform complex I/O, both network and disk, and are useful as standalone products. 7 Furthermore, web servers are generally amenable to parallelization since their workloads are mostly homogeneous. 8 Therefore, web servers offer a stringent performance benchmark for \CFA. 9 Indeed, existing web servers have close to optimal performance, while the homogeneity of the workload means fairness may not be a problem. 10 10 As such, these experiments should highlight the overhead due to any \CFA fairness cost in realistic scenarios. 11 11 12 12 \section{Memcached} 13 13 Memcached~\cite{memcached} is an in-memory key-value store used in many production environments, \eg \cite{atikoglu2012workload}. 14 In fact, the Memcached server is so popular there exists a full-featured front-end for performance testing, called @mutilate@~\cite{GITHUB:mutilate}.14 The Memcached server is so popular there exists a full-featured front-end for performance testing, called @mutilate@~\cite{GITHUB:mutilate}. 15 15 Experimenting on Memcached allows for a simple test of the \CFA runtime as a whole, exercising the scheduler, the idle-sleep mechanism, as well the \io subsystem for sockets. 16 Note , this experiment does not exercise the \io subsystem with regardsto disk operations because Memcached is an in-memory server.16 Note that this experiment does not exercise the \io subsystem with regard to disk operations because Memcached is an in-memory server. 17 17 18 18 \subsection{Benchmark Environment} … … 51 51 This implementation can lead to increased CPU \gls{load} as threads wake from sleep to potentially process the request. 52 52 \end{itemize} 53 Here, Memcached is based on an event-based web server architecture~\cite{Pai99Flash}, using \gls{kthrd}ing to run multiple largely independent event engines, and if needed, spinning up additional kernel threads to handle blocking I/O.54 Alternative web server architectureare:53 Here, Memcached is based on an event-based web server architecture~\cite{Pai99Flash}, using \gls{kthrd}ing to run multiple largely independent event engines, and if needed, spinning up additional kernel threads to handle blocking I/O. 54 Alternative web server architectures are: 55 55 \begin{itemize} 56 56 \item … … 74 74 \item \emph{vanilla}: the official release of Memcached, version~1.6.9. 75 75 \item \emph{fibre}: a modification of vanilla using the thread-per-connection model on top of the libfibre runtime. 76 \item \emph{cfa}: a modification of the fibre web server that replaces the libfibre runtime with \CFA.76 \item \emph{cfa}: a modification of the fibre web server that replaces the libfibre runtime with \CFA. 77 77 \end{itemize} 78 78 … … 80 80 This experiment is done by having the clients establish 15,360 total connections, which persist for the duration of the experiment. 81 81 The clients then send read and write queries with only 3\% writes (updates), attempting to follow a desired query rate, and the server responds to the desired rate as best as possible. 82 Figure~\ref{fig:memcd:rate:qps} shows the 3 server versions at different client rates, ``Target \underline{Q}ueries \underline{P}er \underline{S}econd'', and the actual rate, ``Actual QPS'', for all three web servers.83 84 Like the experimental setup in Chapter~\ref{microbench}, each experiment is run 15 times, and for each client rate, the measured web server rate is plotted.82 Figure~\ref{fig:memcd:rate:qps} shows the 3 server versions at different client rates, ``Target \underline{Q}ueries \underline{P}er \underline{S}econd'', and the actual rate, ``Actual QPS'', for all three web servers. 83 84 Like the experimental setup in Chapter~\ref{microbench}, each experiment is run 15 times, and for each client rate, the measured web server rate is plotted. 85 85 The solid line represents the median while the dashed and dotted lines represent the maximum and minimum respectively. 86 For rates below 500K queries per second s, all three webservers match the client rate.87 Beyond 500K, the web servers cannot match the client rate.88 During this interval, vanilla Memcached achieves the highest web server throughput, with libfibre and \CFA slightly lower but very similar throughput.89 Overall the performance of all three web servers is very similar, especially considering that at 500K the servers have reached saturation, which is discussed more in the next section.86 For rates below 500K queries per second, all three web servers match the client rate. 87 Beyond 500K, the web servers cannot match the client rate. 88 During this interval, vanilla Memcached achieves the highest web server throughput, with libfibre and \CFA slightly lower but very similar throughput. 89 Overall the performance of all three web servers is very similar, especially considering that at 500K the servers have reached saturation, which is discussed more in the next section. 90 90 91 91 \begin{figure} 92 92 \centering 93 93 \resizebox{0.83\linewidth}{!}{\input{result.memcd.rate.qps.pstex_t}} 94 \caption[Memcached Benchmark: Throughput]{Memcached Benchmark: Throughput\smallskip\newline Desired vs Actual query rate for 15,360 connections. Target QPS is the query rate that the clients are attempting to maintain and Actual QPS is the rate at which the server is able torespond.}94 \caption[Memcached Benchmark: Throughput]{Memcached Benchmark: Throughput\smallskip\newline Desired vs Actual query rate for 15,360 connections. Target QPS is the query rate that the clients are attempting to maintain and Actual QPS is the rate at which the server can respond.} 95 95 \label{fig:memcd:rate:qps} 96 96 %\end{figure} … … 99 99 \centering 100 100 \resizebox{0.83\linewidth}{!}{\input{result.memcd.rate.99th.pstex_t}} 101 \caption[Memcached Benchmark : 99th Percentile Latency]{Memcached Benchmark: 99th Percentile Latency\smallskip\newline 99th Percentile of the response latency as a function of \emph{desired} query rate for 15,360 connections. }101 \caption[Memcached Benchmark: 99th Percentile Latency]{Memcached Benchmark: 99th Percentile Latency\smallskip\newline 99th Percentile of the response latency as a function of \emph{desired} query rate for 15,360 connections. } 102 102 \label{fig:memcd:rate:tail} 103 103 \end{figure} 104 104 105 105 \subsection{Tail Latency} 106 Another popular performance metric is \newterm{tail} latency, which indicates some notion of fairness among requests across the experiment, \ie do some requests wait longer than other requests for service .106 Another popular performance metric is \newterm{tail} latency, which indicates some notion of fairness among requests across the experiment, \ie do some requests wait longer than other requests for service? 107 107 Since many web applications rely on a combination of different queries made in parallel, the latency of the slowest response, \ie tail latency, can dictate a performance perception. 108 108 Figure~\ref{fig:memcd:rate:tail} shows the 99th percentile latency results for the same Memcached experiment. 109 109 110 110 Again, each experiment is run 15 times with the median, maximum and minimum plotted with different lines. 111 As expected, the latency starts low and increases as the server gets close to saturation, at which point, the latency increases dramatically because the web servers cannot keep up with the connection rate so client requests are disproportionally delayed.112 Because of this dramatic increase, the Y axis is presented using log scale.113 Note that the graph shows \emph{target} query rate, the actual response rate is given in Figure~\ref{fig:memcd:rate:qps} as this is the same underlying experiment.114 115 For all three servers, the saturation point is reached before 500K queries per second, which is when throughput starts to decline among the web servers.116 In this experiment, all three web servers are much more distinguishable than the throughput experiment.117 Vanilla Memcached achieves the lowest latency until 600K, after which all the web servers are struggling to respond to client requests.111 As expected, the latency starts low and increases as the server gets close to saturation, at which point, the latency increases dramatically because the web servers cannot keep up with the connection rate so client requests are disproportionally delayed. 112 Because of this dramatic increase, the Y axis is presented using a log scale. 113 Note that the graph shows the \emph{target} query rate, the actual response rate is given in Figure~\ref{fig:memcd:rate:qps} as this is the same underlying experiment. 114 115 For all three servers, the saturation point is reached before 500K queries per second, which is when throughput starts to decline among the web servers. 116 In this experiment, all three web servers are much more distinguishable than in the throughput experiment. 117 Vanilla Memcached achieves the lowest latency until 600K, after which all the web servers are struggling to respond to client requests. 118 118 \CFA begins to decline at 600K, indicating some bottleneck after saturation. 119 Overall, all three web servers achieve micro-second latencies and the increases in latency mostly follow each other.119 Overall, all three web servers achieve micro-second latencies and the increases in latency mostly follow each other. 120 120 121 121 \subsection{Update rate} 122 Since Memcached is effectively a simple database, the information that is cachedcan be written to concurrently by multiple queries.122 Since Memcached is effectively a simple database, the cache information can be written to concurrently by multiple queries. 123 123 And since writes can significantly affect performance, it is interesting to see how varying the update rate affects performance. 124 124 Figure~\ref{fig:memcd:updt} shows the results for the same experiment as the throughput and latency experiment but increasing the update percentage to 5\%, 10\% and 50\%, respectively, versus the original 3\% update percentage. … … 167 167 } 168 168 \caption[Throughput and Latency results at different update rates (percentage of writes).]{Throughput and Latency results at different update rates (percentage of writes).\smallskip\newline On the left, throughput as Desired vs Actual query rate. 169 Target QPS is the query rate that the clients are attempting to maintain and Actual QPS is the rate at which the server is able torespond.169 Target QPS is the query rate that the clients are attempting to maintain and Actual QPS is the rate at which the server can respond. 170 170 On the right, tail latency, \ie 99th Percentile of the response latency as a function of \emph{desired} query rate. 171 171 For throughput, higher is better, for tail-latency, lower is better. 172 Each series represent 15 independent runs, the dashed lines are maximums of each series while the solid lines are the median and the dotted lines are the minimums.}172 Each series represent 15 independent runs, the dashed lines are the maximums of each series while the solid lines are the median and the dotted lines are the minimums.} 173 173 All runs have 15,360 client connections. 174 174 \label{fig:memcd:updt} … … 183 183 \section{Static Web-Server} 184 184 The Memcached experiment does not exercise two key aspects of the \io subsystem: accept\-ing new connections and interacting with disks. 185 On the other hand, a web server servicing static web-pages does stress both accepting connections and disk \io by accepting tens of thousands of client requests per second where these requests return static data serviced from the file-system cache or disk.\footnote{186 Webservers servicing dynamic requests, which read from multiple locations and construct a response, are not as interesting since creating the response takes more time and does not exercise the runtime in a meaningfully different way.}187 The static web server experiment compares NGINX~\cite{nginx} with a custom \CFA-based webserver developed for this experiment.185 On the other hand, a web server servicing static web pages does stress both accepting connections and disk \io by accepting tens of thousands of client requests per second where these requests return static data serviced from the file-system cache or disk.\footnote{ 186 web servers servicing dynamic requests, which read from multiple locations and construct a response, are not as interesting since creating the response takes more time and does not exercise the runtime in a meaningfully different way.} 187 The static web server experiment compares NGINX~\cite{nginx} with a custom \CFA-based web server developed for this experiment. 188 188 189 189 \subsection{NGINX threading} 190 NGINX is a n high-performance, \emph{full-service}, event-driven webserver.190 NGINX is a high-performance, \emph{full-service}, event-driven web server. 191 191 It can handle both static and dynamic web content, as well as serve as a reverse proxy and a load balancer~\cite{reese2008nginx}. 192 192 This wealth of capabilities comes with a variety of potential configurations, dictating available features and performance. 193 193 The NGINX server runs a master process that performs operations such as reading configuration files, binding to ports, and controlling worker processes. 194 When running as a static web server, it uses an event-driven architecture to service incoming requests.195 Incoming connections are assigned a \emph{stackless} HTTP state -machine and worker processes can handle thousands of these state machines.194 When running as a static web server, it uses an event-driven architecture to service incoming requests. 195 Incoming connections are assigned a \emph{stackless} HTTP state machine and worker processes can handle thousands of these state machines. 196 196 For the following experiment, NGINX is configured to use @epoll@ to listen for events on these state machines and have each worker process independently accept new connections. 197 197 Because of the realities of Linux, see Subsection~\ref{ononblock}, NGINX also maintains a pool of auxiliary threads to handle blocking \io. 198 198 The configuration can set the number of worker processes desired, as well as the size of the auxiliary pool. 199 However, for the following experiments, NGINX is configured to let the master process decide dthe appropriate number of threads.200 201 \subsection{\CFA web server}202 The \CFA web server is a straightforward thread-per-connection webserver, where a fixed number of \ats are created upfront.199 However, for the following experiments, NGINX is configured to let the master process decide the appropriate number of threads. 200 201 \subsection{\CFA web server} 202 The \CFA web server is a straightforward thread-per-connection web server, where a fixed number of \ats are created upfront. 203 203 Each \at calls @accept@, through @io_uring@, on the listening port and handles the incoming connection once accepted. 204 204 Most of the implementation is fairly straightforward; 205 205 however, the inclusion of file \io found an @io_uring@ problem that required an unfortunate workaround. 206 206 207 Normally, web servers use @sendfile@~\cite{MAN:sendfile} to send files over a socket because it performs a direct move in the kernel from the file-system cache to the NIC, eliminating reading/writing the file into the webserver.208 While @io_uring@ does not support @sendfile@, it does support s@splice@~\cite{MAN:splice}, which is strictly more powerful.207 Normally, web servers use @sendfile@~\cite{MAN:sendfile} to send files over a socket because it performs a direct move in the kernel from the file-system cache to the NIC, eliminating reading/writing the file into the web server. 208 While @io_uring@ does not support @sendfile@, it does support @splice@~\cite{MAN:splice}, which is strictly more powerful. 209 209 However, because of how Linux implements file \io, see Subsection~\ref{ononblock}, @io_uring@ must delegate splice calls to worker threads \emph{inside} the kernel. 210 210 As of Linux 5.13, @io_uring@ had no mechanism to restrict the number of worker threads, and therefore, when tens of thousands of splice requests are made, it correspondingly creates tens of thousands of internal \glspl{kthrd}. 211 211 Such a high number of \glspl{kthrd} slows Linux significantly. 212 Rather than abandon the experiment, the \CFA web server was switched to @sendfile@.212 Rather than abandon the experiment, the \CFA web server was switched to @sendfile@. 213 213 214 214 Starting with \emph{blocking} @sendfile@, \CFA achieves acceptable performance until saturation is reached. … … 220 220 The call can block if there is insufficient memory, which can be caused by having too many connections in the CLOSE-WAIT state.\footnote{ 221 221 \lstinline{sendfile} can always block even in nonblocking mode if the file to be sent is not in the file-system cache, because Linux does not provide nonblocking disk I/O.} 222 This effect results in a negative feedback where more timeouts lead to more @sendfile@ calls running out of resources.222 This effect results in a negative feedback loop where more timeouts lead to more @sendfile@ calls running out of resources. 223 223 224 224 Normally, this problem is addressed by using @select@/@epoll@ to wait for sockets to have sufficient resources. 225 However, since @io_uring@ does not support @sendfile@ but does respect snon\-blocking semantics, marking all sockets as non-blocking effectively circumvents the @io_uring@ subsystem entirely:225 However, since @io_uring@ does not support @sendfile@ but does respect non\-blocking semantics, marking all sockets as non-blocking effectively circumvents the @io_uring@ subsystem entirely: 226 226 all calls simply immediately return @EAGAIN@ and all asynchronicity is lost. 227 227 228 Switching all of the \CFA runtime to @epoll@ for this experiment is unrealistic and does not help in the evaluation of the \CFA runtime.229 For this reason, the \CFA web server sets and resets the @O_NONBLOCK@ flag before and after any calls to @sendfile@.228 Switching the entire \CFA runtime to @epoll@ for this experiment is unrealistic and does not help in the evaluation of the \CFA runtime. 229 For this reason, the \CFA web server sets and resets the @O_NONBLOCK@ flag before and after any calls to @sendfile@. 230 230 However, when the nonblocking @sendfile@ returns @EAGAIN@, the \CFA server cannot block the \at because its I/O subsystem uses @io_uring@. 231 Therefore, the \at spins performing the @sendfile@, yields if the call returns @EAGAIN@ ,and retries in these cases.231 Therefore, the \at spins performing the @sendfile@, yields if the call returns @EAGAIN@ and retries in these cases. 232 232 233 233 Interestingly, Linux 5.15 @io_uring@ introduces the ability to limit the number of worker threads that are created through the @IORING_REGISTER_IOWQ_MAX_WORKERS@ option. 234 234 Presumably, this limit would prevent the explosion of \glspl{kthrd}, which justified using @sendfile@ over @io_uring@ and @splice@. 235 235 However, recall from Section~\ref{iouring} that @io_uring@ maintains two pools of workers: bounded workers and unbounded workers. 236 For a web server, the unbounded workers should handle accepts and reads on socket, and the bounded workers should handle reading files from disk.237 This setup allows fine-grained control over the number of workers needed for each operation type and presumably lead to good performance.236 For a web server, the unbounded workers should handle accepts and reads on sockets, and the bounded workers should handle reading files from disk. 237 This setup allows fine-grained control over the number of workers needed for each operation type and presumably leads to good performance. 238 238 239 239 However, @io_uring@ must contend with another reality of Linux: the versatility of @splice@. 240 240 Indeed, @splice@ can be used both for reading and writing to or from any type of file descriptor. 241 241 This generality makes it ambiguous which pool @io_uring@ should delegate @splice@ calls to. 242 In the case of splicing from a socket to pipe, @splice@ behaves like an unbounded operation, but when splicing from a regular file to a pipe, @splice@ becomes a bounded operation.242 In the case of splicing from a socket to a pipe, @splice@ behaves like an unbounded operation, but when splicing from a regular file to a pipe, @splice@ becomes a bounded operation. 243 243 To make things more complicated, @splice@ can read from a pipe and write to a regular file. 244 244 In this case, the read is an unbounded operation but the write is a bounded one. 245 245 This leaves @io_uring@ in a difficult situation where it can be very difficult to delegate splice operations to the appropriate type of worker. 246 246 Since there is little or no context available to @io_uring@, it seems to always delegate @splice@ operations to the unbounded workers. 247 This decision is unfortunate for this specific experiment , since it prevents the webserver from limiting the number of parallel calls to @splice@ without affecting the performance of @read@ or @accept@.247 This decision is unfortunate for this specific experiment since it prevents the web server from limiting the number of parallel calls to @splice@ without affecting the performance of @read@ or @accept@. 248 248 For this reason, the @sendfile@ approach described above is still the most performant solution in Linux 5.15. 249 249 250 250 One possible workaround is to create more @io_uring@ instances so @splice@ operations can be issued to a different instance than the @read@ and @accept@ operations. 251 251 However, I do not believe this solution is appropriate in general; 252 it simply replaces my current web server hack with a different, equivalent hack.252 it simply replaces my current web server hack with a different, equivalent hack. 253 253 254 254 \subsection{Benchmark Environment} 255 Unlike the Memcached experiment, the web server experiment is run on a heterogeneous environment.255 Unlike the Memcached experiment, the web server experiment is run on a heterogeneous environment. 256 256 \begin{itemize} 257 257 \item 258 258 The server runs Ubuntu 20.04.4 LTS on top of Linux Kernel 5.13.0-52. 259 259 \item 260 The server computer has four AMD Opteron (tm)Processor 6380 with 16 cores running at 2.5GHz, for a total of 64 \glspl{hthrd}.260 The server computer has four AMD Opteron\texttrademark Processor 6380 with 16 cores running at 2.5GHz, for a total of 64 \glspl{hthrd}. 261 261 \item 262 262 The computer is booted with only 8 CPUs enabled, which is sufficient to achieve line rate. … … 273 273 It has two 2.8 GHz Xeon CPUs, and four one-gigabit Ethernet cards. 274 274 \item 275 Network routing is performed by a HP 2530 10 Gigabit Ethernet switch.275 Network routing is performed by an HP 2530 10 Gigabit Ethernet switch. 276 276 \item 277 277 A client machine runs two copies of the workload generator. 278 278 \end{itemize} 279 279 The clients and network are sufficiently provisioned to drive the server to saturation and beyond. 280 Hence, any server effects are attributable solely to the runtime system and web server.281 Finally, without restricting the server hardware resources, it is impossible to determine if a runtime system or the web server using it has any specific design restrictions, \eg using space to reduce time.282 Trying to determine these restriction with large numbers of processors or memory simply means running equally large experiments, which takeslonger and are harder to set up.280 Hence, any server effects are attributable solely to the runtime system and web server. 281 Finally, without restricting the server hardware resources, it is impossible to determine if a runtime system or the web server using it has any specific design restrictions, \eg using space to reduce time. 282 Trying to determine these restrictions with large numbers of processors or memory simply means running equally large experiments, which take longer and are harder to set up. 283 283 284 284 \subsection{Throughput} 285 To measure web server throughput, the server computer is loaded with 21,600 files, sharded across 650 directories, occupying about 2.2GB of disk, distributed over the server's RAID-5 4-drives to achieve high throughput for disk I/O.285 To measure web server throughput, the server computer is loaded with 21,600 files, sharded across 650 directories, occupying about 2.2GB of disk, distributed over the server's RAID-5 4-drives to achieve high throughput for disk I/O. 286 286 The clients run httperf~\cite{httperf} to request a set of static files. 287 287 The httperf load-generator is used with session files to simulate a large number of users and to implement a partially open-loop system. … … 290 290 The experiments are run with 16 clients, each running a copy of httperf (one copy per CPU), requiring a set of 16 log files with requests conforming to a Zipf distribution. 291 291 This distribution is representative of users accessing static data through a web browser. 292 Each request reads a file name from its trace, establishes a connection, performs an HTTP get-request for the file name, receive the file data, close the connection, and repeatthe process.292 Each request reads a file name from its trace, establishes a connection, performs an HTTP get-request for the file name, receives the file data, closes the connection, and repeats the process. 293 293 Some trace elements have multiple file names that are read across a persistent connection. 294 A client times -out if the server does not complete a request within 10 seconds.294 A client times out if the server does not complete a request within 10 seconds. 295 295 296 296 An experiment consists of running a server with request rates ranging from 10,000 to 70,000 requests per second; 297 297 each rate takes about 5 minutes to complete. 298 There is 20 secondsidle time between rates and between experiments to allow connections in the TIME-WAIT state to clear.298 There are 20 seconds of idle time between rates and between experiments to allow connections in the TIME-WAIT state to clear. 299 299 Server throughput is measured both at peak and after saturation (\ie after peak). 300 300 Peak indicates the level of client requests the server can handle and after peak indicates if a server degrades gracefully. … … 328 328 \label{fig:swbsrv:err} 329 329 } 330 \caption[Static Webserver Benchmark : Throughput]{Static Webserver Benchmark : Throughput\smallskip\newline Throughput vs request rate for short lived connectionsconnections.}330 \caption[Static web server Benchmark: Throughput]{Static web server Benchmark: Throughput\smallskip\newline Throughput vs request rate for short-lived connections.} 331 331 \label{fig:swbsrv} 332 332 \end{figure} … … 334 334 Figure~\ref{fig:swbsrv} shows the results comparing \CFA to NGINX in terms of throughput. 335 335 These results are fairly straightforward. 336 Both servers achieve the same throughput until around 57,500 requests per second s.336 Both servers achieve the same throughput until around 57,500 requests per second. 337 337 Since the clients are asking for the same files, the fact that the throughput matches exactly is expected as long as both servers are able to serve the request rate. 338 338 Once the saturation point is reached, both servers are still very close. 339 339 NGINX achieves slightly better throughput. 340 340 However, Figure~\ref{fig:swbsrv:err} shows the rate of errors, a gross approximation of tail latency, where \CFA achieves notably fewer errors once the servers reach saturation. 341 This suggests \CFA is slightly fairer with less throughput, while NGINX sacrifice fairness for more throughput.342 This experiment demonstrate that the \CFA webserver is able to match the performance of NGINX up-to and beyond the saturation point of the machine.341 This suggests \CFA is slightly fairer with less throughput, while NGINX sacrifices fairness for more throughput. 342 This experiment demonstrates that the \CFA web server is able to match the performance of NGINX up to and beyond the saturation point of the machine. 343 343 344 344 \subsection{Disk Operations} 345 With 25GB of memory, the entire experimental file-set plus the web server and OS fit in memory.345 With 25GB of memory, the entire experimental file-set plus the web server and OS fit in memory. 346 346 If memory is constrained, the OS must evict files from the file cache, which causes @sendfile@ to read from disk.\footnote{ 347 347 For the in-memory experiments, the file-system cache was warmed by running an experiment three times before measuring started to ensure all files are in the file-system cache.} 348 Webservers can behave very differently once file I/O begins and increases.349 Hence, prior work~\cite{Harji10} suggests running both kinds of experiments to test overall web server performance.348 web servers can behave very differently once file I/O begins and increases. 349 Hence, prior work~\cite{Harji10} suggests running both kinds of experiments to test overall web server performance. 350 350 351 351 However, after reducing memory to 2.5GB, the problem with @splice@ and @io_uring@ rears its ugly head again. … … 355 355 The only solution for the bounded side is to spawn more threads and let these handle the blocking. 356 356 357 Supporting this case in the web server would require creating more \procs or creating a dedicated thread-pool.357 Supporting this case in the web server would require creating more \procs or creating a dedicated thread pool. 358 358 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; 359 359 hence, I decided to forgo experiments on low-memory performance.
Note: See TracChangeset
for help on using the changeset viewer.