Woo: Writing a fast web server @ ELS2015
3 likes9,770 views
Eitaro Fukamachi presented on writing the fast web server Woo in Common Lisp. He discussed three tactics for achieving speed: using a multithreaded event-driven architecture instead of prefork, developing a fast HTTP parser instead of regular expressions, and using the libev event library. Benchmarks showed Woo was 1.6 times faster than Node.js. The goal was to create the fastest HTTP server in Common Lisp.
Ad
More Related Content
What's hot (20)
Viewers also liked (20)
Ad
Similar to Woo: Writing a fast web server @ ELS2015 (20)
Ad
Recently uploaded (20)
Woo: Writing a fast web server @ ELS2015
- 1. Woo: Writing a fast web server 8th European Lisp Symposium @ London, UK April 21, 2015 Eitaro Fukamachi Somewrite Co., Ltd.
- 2. I’m Eitaro Fukamachi @nitro_idiot fukamachi
- 3. My Products • Clack • Caveman2 • CL-DBI • quickdocs.org • datafly • SxQL ...and 25 other libraries
- 6. Woo
- 7. • HTTP server written in Common Lisp • HTTP/0.9, HTTP/1.x • Clack compliant Woo
- 8. Clack? • Abstraction layer of HTTP servers Web server Application Web server Web server Application Application
- 9. Clack? • Abstraction layer of HTTP servers Web server Application Web server Web server Application Application Clack
- 10. ex) Caveman2 • built on top of Clack Web serverWeb server Web server Caveman2 (Web framework) Clack
- 11. ex) RESTAS (without Clack) • directly built on top of Hunchentoot Web server Depends on Hunchentoot. Can’t switch the backend!! Supports only Hunchentoot Web server Web server RESTAS (Web framework)
- 12. Clack-compliant (woo:run (lambda (env) ‘(200 (:content-type “text/plain”) (“Hello, World”)))) (clack:clackup (lambda (env) ‘(200 (:content-type “text/plain”) (“Hello, World”))) :server :woo) Run with Clack
- 14. Fast — in the real worldreq/sec 0 33 65 98 130 Node.js Woo 127.18 76.73 1.6 times faster!
- 15. Let me tell why I had to write a fast HTTP server.
- 17. Wookie is slower than Node.js • Wookie is 2 times slower than Node.js
- 18. Wookie is slower than Node.js • Wookie is 2 times slower than Node.js IS COMMON LISP SLOW???
- 19. Wookie is slower than Node.js • Wookie is 2 times slower than Node.js IS COMMON LISP SLOW??? NO WAY!
- 20. So, I decided to write a faster one.
- 21. How could it be fast?
- 22. 3 difficulties in writing an HTTP servers
- 23. 3 difficulties in HTTP server • Network I/O is the largest bottleneck • Need to handle a vast amount of requests at once • Need to handle various HTTP clients (fast / slow / unstable)
- 24. 3 tactics (no silver bullet) 1. Better architecture 2. Fast HTTP parsing 3. The libev event library
- 26. 2 architectures: Prefork vs Event-driven
- 27. Prefork Worker process Worker process Worker process master process Requests accept connections Responses • Simple • Fast for little simultaneous connections • ex) Hunchentoot, Unicorn, Apache
- 28. Prefork Worker process Worker process Worker process master process Requests accept connections Responses • Slow client can cause performance issue. • like Mobile users • Slowloris attack blocking! ･･･ Problem
- 29. Event-driven • Handle many clients at the same time • Asnyc ACCEPT/ READ/WRITE • ex) Woo, Wookie, Tornado, nginxServer process (single-threaded) Event loop
- 31. Woo took another way: Multithreaded event-driven
- 32. Multithreaded event-driven Server process Event loop listen on the same file descriptor Server process Event loop Server process Event loop
- 33. Tactic 2: Fast HTTP parsing
- 34. HTTP parsing can be a bottleneck • Wookie's largest bottleneck is HTTP parsing • http-parse (uses regular expression) • fast-http (byte by byte parser) • 6000 times faster than http-parse
- 35. A brief introduction of HTTP
- 36. HTTP request look like… GET /media HTTP/1.1↵ Host: somewrite.jp↵ Connection: keep-alive↵ Accept: */*↵ ↵
- 37. HTTP request look like… GET /media HTTP/1.1↵ Host: somewrite.jp↵ Connection: keep-alive↵ Accept: */*↵ ↵ First Line Headers Body (empty, in this case)
- 38. HTTP request look like… GET /media HTTP/1.1↵ Host: somewrite.jp↵ Connection: keep-alive↵ Accept: */*↵ ↵ CR + LF CRLF * 2 at the end of headers
- 39. HTTP is… • Text-based protocol. (not binary) • Lines terminated with CRLF • Very lenient. • Ignore multiple spaces • Allow continuous header values
- 41. HTTP messages are sent over a network.
- 42. Which means, we need to think about long & incomplete HTTP messages.
- 43. There’s 2 ways to resolve this problem.
- 45. http-parser (used in Node.js) • https://github.com/joyent/http-parser • Written in C • Ported from Nginx’s HTTP parser • Written as Node.js’s HTTP parser • Stateful
- 46. http-parser (used in Node.js) for (p=data; p != data + len; p++) { … switch (parser->state) { case s_dead: … case s_start_req_or_res: … case s_res_or_resp_H: … } }
- 47. http-parser (used in Node.js) for (p=data; p != data + len; p++) { … switch (parser->state) { case s_dead: … case s_start_req_or_res: … case s_res_or_resp_H: … } } Process char by char Do something for each state
- 48. http-parser (used in Node.js) for (p=data; p != data + len; p++) { … switch (parser->state) { case s_dead: … case s_start_req_or_res: … case s_res_or_resp_H: … } } Process char by char Do something for each state Executed for every char!!
- 50. PicoHTTPParser (used in H2O) • https://github.com/h2o/picohttpparser • Written in C • Stateless
- 51. PicoHTTPParser (used in H2O) • https://github.com/h2o/picohttpparser • Written in C • Stateless • Reparse when the data is incomplete • Most HTTP request is small
- 53. fast-http is in the middle • Stateful • Track state for every line, not every char • 1.25 times faster than C http-parser.
- 54. Tactic 3: The libev event library
- 55. libev • Wrapper of epoll, kqueue, POSIX select, poll • Thin • Fast
- 56. libev • Wrapper of epoll, kqueue, POSIX select, poll • Thin • Fast • Poor Windows support • Windows isn’t popular for running an HTTP server
- 57. Goal
- 58. Goal: What is fast enough? • The initial goal was “Beating Node.js” • Done • Being the fastest HTTP server in Common Lisp • Done
- 59. Got a great Pull Request
- 60. See Also • Clack: clacklisp.org • fast-http: github.com/fukamachi/fast-http • libev • Woo: github.com/fukamachi/woo
- 61. You may be interested in • Dexador: github.com/fukamachi/dexador • HTTP client library built on top of fast-http and usocket.
- 62. Thanks.