Writing a fast HTTP parser
9 likes7,429 views
Eitaro Fukamachi gave a presentation on writing a fast HTTP parser in Common Lisp called fast-http. He explained that the bottleneck in the Wookie web framework was HTTP parsing, which was slower than Node.js. This was because Node.js uses the C-based and highly optimized http-parser library. Eitaro discussed how fast-http achieves high performance through an architecture that reduces memory allocation and uses the right data types, as well as through benchmarking, profiling, and type declarations to provide hints to the compiler. The goal was to write carefully optimized Lisp code that could match or beat C in performance for complex programs like an HTTP parser.
![[D14] 【詳解】インメモリーデータベース SAP HANA：実際の仕組みと動きを理解しよう！by Toshiro Morisaki](https://cdn.slidesharecdn.com/ss_thumbnails/d14sapmorisaki-140623195128-phpapp01-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Similar to Writing a fast HTTP parser (20)
More from fukamachi (20)
Recently uploaded (20)
Writing a fast HTTP parser
- 1. Lisp Meetup #22 Eitaro Fukamachi Writing a fast HTTP parser
- 2. Thank you for coming.
- 3. I’m Eitaro Fukamachi @nitro_idiot fukamachi
- 7. We’re hiring! Tell @Rudolph_Miller.
- 8. fast-http • HTTP request/response parser • Written in portable Common Lisp • Fast • Chunked body parser
- 9. fast-http Benchmarked with SBCL 1.2.5 / GCC v6.0.0
- 10. Let me tell why I had to write a fast HTTP parser.
- 12. Wookie is slower than Node.js • Wookie is 2 times slower than Node.js • Profiling result was saying “WOOKIE:READ-DATA” was pretty slow. • It was only calling “http-parse”. • “http-parse” which is an HTTP parser Wookie is using.
- 13. The bottleneck was HTTP parsing.
- 14. Wookie is slower than Node.js • Node.js’s HTTP parse is “http-parser”. • Written in C. • General version of Nginx’s HTTP parser. • Is it possible to beat it with Common Lisp?
- 15. Today, I’m talking what I did for writing a fast Common Lisp program.
- 16. 5 important things • Architecture • Reducing memory allocation • Choosing the right data types • Benchmark & Profile • Type declarations
- 17. 5 important things • Architecture • Reducing memory allocation • Choosing the right data types • Benchmark & Profile • Type declarations
- 18. A brief introduction of HTTP
- 19. HTTP request look like… GET /media HTTP/1.1↵ Host: somewrite.jp↵ Connection: keep-alive↵ Accept: */*↵ ↵
- 20. HTTP request look like… GET /media HTTP/1.1↵ Host: somewrite.jp↵ Connection: keep-alive↵ Accept: */*↵ ↵ First Line Headers Body (empty, in this case)
- 21. 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
- 22. HTTP response look like… HTTP/1.1 200 OK↵ Cache-Control: max-age=0↵ Content-Type: text/html↵ Date: Wed, 26 Nov 2014 04:52:55 GMT↵ ↵ <html> …
- 23. HTTP response look like… HTTP/1.1 200 OK↵ Status Line Cache-Control: max-age=0↵ Content-Type: text/html↵ Headers Date: Wed, 26 Nov 2014 04:52:55 GMT↵ ↵ <html> … Body
- 24. HTTP is… • Text-based protocol. (not binary) • Lines terminated with CRLF • Very lenient. • Ignore multiple spaces • Allow continuous header values
- 25. And, there’s another difficulty.
- 26. HTTP messages are sent over a network.
- 27. Which means, we need to think about long & incomplete HTTP messages.
- 28. There’s 2 ways to resolve this problem.
- 30. 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
- 31. 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: … } }
- 32. http-parser (used in Node.js) for (p=data; p != data + len; p++) { … switch (parser->state) { Process char by char case s_dead: … case s_start_req_or_res: … case s_res_or_resp_H: … } } Do something for each state
- 34. PicoHTTPParser (used in H2O) • https://github.com/h2o/picohttpparser • Written in C • Stateless • Reparse when the data is incomplete • Most HTTP request is small
- 36. fast-http is in the middle • Not track state for every character • Set state for every line • It makes the program simple • And easy to optimize
- 37. 5 important things • Architecture • Reducing memory allocation • Choosing the right data types • Benchmark & Profile • Type declarations
- 38. Memory allocation is slow • (in general) • Make sure not to allocate memory during processing • cons, make-instance, make-array… • subseq, append, copy-seq
- 39. 5 important things • Architecture • Reducing memory allocation • Choosing the right data types • Benchmark & Profile • Type declarations
- 40. Data types • Wrong data type makes your program slow. • List or Vector • Hash Table or Structure or Class
- 41. 5 important things • Architecture • Reducing memory allocation • Choosing the right data types • Benchmark & Profile • Type declarations
- 42. Benchmark is quite important • “Don’t guess, measure!” • Check if your changes improve the performance. • Benchmarking also keeps your motivation.
- 43. Profiling • SBCL has builtin profiler • (sb-profile:profile “FAST-HTTP” …) • (sb-profile:report)
- 44. 5 important things • Architecture • Reducing memory allocation • Choosing the right data types • Benchmark & Profile • Type declarations
- 45. Type declaration • Common Lisp has type declaration (optional) • (declare (type <type> <variable symbol>)) • It’s a hint for your Lisp compiler • (declare (optimize (speed 3) (safety 0))) • It’s your wish to your Lisp compiler See also: Cより高速なCommon Lispコードを書く
- 46. (safety 0) • (safety 0) means “don’t check the type & array index in run-time”. • Fast & unsafe (like C) • Is fixnum enough? • What do you do when someone passes a bignum to the function?
- 47. (safety 0) • fast-http has 2 layers • Low-level API • (speed 3) (safety 0) • High-level API (safer) • Check the variable type • (speed 3) (safety 2)
- 48. Attitude
- 49. Attitude • Write carefully. • It’s possible to beat C program • (if the program is complicated enough) • Don’t give up easily • Safety is more important than speed
- 50. Thanks.
- 51. EITARO FUKAMACHI 8arrow.org @nitro_idiot fukamachi