Demonstration at European Lisp Symposium 2015 in London, UK.

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

5. We’re hiring!

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

13. Fast
https://github.com/fukamachi/woo#benchmarks

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

25. Tactic 1:
Better architecture

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

30. Event-driven
• Single-threaded
Problem
Server 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

40. And,
there’s another difficulty.

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.

44. 1. Stateful (http-parser)

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!!

49. 2. Stateless (PicoHTTPParser)

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

52. And fast-http is…

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.

63. EITARO FUKAMACHI
8arrow.org
@nitro_idiot fukamachi