Lazy Asynchronous IO For Event Driven Servers Written

Lazy Asynchronous I/O For Event Driven Servers Written by: Khaled Elmeleegy, Anupam Chanda, Alan L. Cox and Willy Zwaenepoel Presented by: Trevor Armstrong

Introduction • Many operations case programs to block • Negative effect on performance for event driven servers • Three methods to work around this problem: – Abandon event driven approach – Use thread pool to service blocking requests – Accept it

Lazy Asynchronous I/O • General, non-blocking counterpart for each and every system call • Lazy = system doesn’t create continuation if blocking call returns without blocking – 73% - 86% don’t block • Simple • Returns on completion (not partial) • User-level library, no changes to kernel

LAIO API • laio_syscall() – Same as syscall(), standard function for performing indirect system calls – Returns -1 (EINPROGRESS) on blocking • laio_gethandle() – Returns opaque handle for background laio_syscall • laio_poll() – Waits for completion of background laio_syscall

Typically Usage • Event notification library • Event loop receives request • Program executes blocking call with laio_syscall • Creates an event object using laio_gethandle and continuation function • Returns to event loop • Event loop uses laio_poll to check for completion

Evaluation - Microbenchmarks • 100, 000 iterations of reading 1 byte from pipe • Low I/O overhead • Byte in pipe – LAIO 1. 4 x slower than Non Blocking I/O – LAIO 3. 2 x faster than AIO (overhead) • Byte not in pipe – LAIO 1. 08 x slower than AIO

Evaluation - Macrobenchmarks • Web Servers benchmark application • thttpd – Single threaded EDS – Non blocking socket I/O – Blocking file I/O • Flash – Employs the asymmetric multiprocess event driven architecture (AMPED)

Evaluation • Machines – 2. 4 GHz Intel Xeon Processor – 2 GB RAM – One 7200 RMP Hard drive • Connected by gigabit Ethernet switch

Evaluation

Evaluation NB I/O - Berkley • Workload = 6. 4 GB • thttpd – LAIO-LAIO vs NB-B = 12% - 38% improvement • Flash – LAIO-LAIO vs NB-B = 5% - 108% improvement • Lots of blocking disk access

Evaluation NB I/O Plot

Evaluation NB I/O - Berkley

Evaluation NB I/O - Rice • Workload = 1. 1 GB • thttpd – LAIO-LAIO vs NB-B = 9% - 36% improvement • Flash – LAIO-LAIO vs NB-B = 12% - 38% improvement • Workload fits in memory (no benefit with warm cache)

Evaluation NB I/O - Rice

Evaluation AMPED • Flash with helper processes • Two relevant helpers – File read: reads a file from disk – Name conversion: checks for a file’s existence and permissions

Evaluation AMPED • LAIO avoids complexity of creation and communication of helper processes as well as state • Flash (Berkeley) – LAIO-LAIO vs NB-AMPED = 10 -40% improvement • Better disk utilization

Evaluation AMPED

Code Comparison Component Flash-NBAMPED Flash-LAIO File read 550 15 Name Conversion 610 375 Partial-write state maintenance 70 0 Total code size 8860 8020 9. 5% reduction in lines of code

Questions/Comments