K
Kazuho Oku
blog.kazuhooku.com · Personal blog · on HN since 2013
Kazuho Oku, author of the H2O HTTP server, writes about HTTP/2 performance, parsers, sprintf optimization and libuv.
What HN saysHN commenters cite him on HTTP/2 push and cache awareness, and praise his qrintf sprintf-optimizing compiler as a neat find.
20HN people shared it
4linked it in comments
25stories submitted
475story points
4 years agolast shared
2013people per year2026
Most-shared posts
- 1The reasons I stopped using libuv4 people · 22 points · first shared 2014 · 1 comments on HN
- 2Making the HTTPd run 20% faster with qrintf-gcc; a sprintf-optimizing compiler4 people · 17 points · first shared 2014 · 4 comments on HN
- 3Show HN: Dependency-based prioritization makes HTTP/2 much faster than SPDY2 people · 68 points · first shared 2015 · 8 comments on HN
- 4H2O HTTP/2 server 2.0.1 / 2.1.0-beta1 released2 people · 5 points · first shared 2016 · 1 comments on HN
- 5Show HN: Initial release of H2O, and why HTTPD performance will matter in 20151 people · 251 points · first shared 2014 · 83 comments on HN
- 6H2O 1.4.0 released with support for forward secrecy1 people · 40 points · first shared 2015 · 5 comments on HN
- 7Improving Parser Performance Using SSE Instructions1 people · 38 points · first shared 2014 · 7 comments on HN
- 8H2O Author: I joined Fastly1 people · 9 points · first shared 2017 · discussion on HN
- 9Show HN: The JSON SQL Injection Vulnerability1 people · 4 points · first shared 2014 · discussion on HN
- 10Show HN: Determining whether if a function is declared in C++111 people · 3 points · first shared 2014 · discussion on HN
- 11Improving Parser Performance Using SSE Instructions (in Case of PicoHTTPParser)1 people · 3 points · first shared 2014 · discussion on HN
- 12HTTP/2 is much faster than SPDY thanks to dependency-based prioritization1 people · 3 points · first shared 2015 · discussion on HN
- 13H2O version 2.3.0-beta1 released, improvements presented at Rubykaigi 20181 people · 3 points · first shared 2018 · discussion on HN
- 14Show HN: H2O HTTP2 server 1.3 provides faster response to user, supports FastCGI1 people · 2 points · first shared 2015 · discussion on HN
- 15H2O version 2.1.01 people · 2 points · first shared 2017 · discussion on HN
What HN people wrote when they linked it
foobarbazetc · 2018-04-25
The main problem with http2 push and why it’s pointless is that it’s not cache aware.
So you’re pushing unrequested data to everyone regardless.
h2o tries to solve this problem with a special cookie. More here:
http://blog.kazuhooku.com/2015/12/optimizing-performance-of-multi-tier…
But without something like that it’s a feature that will never really gain traction.
jdblair · 2017-03-03
The most interesting thing I learned from this article is the sprintf() pre-compiler (http://blog.kazuhooku.com/2014/10/announcing-qrintf-and-qrintf-gcc.htm… That's awesome.
The rest, well, its a helpful check on over enthusiasm to be familiar with the shortcomings of UNIX. By dint of its popularity, diversity and long lineage, UNIX and its derivatives are particularly rich in warts. Yet, I think it must be true of all real-world operating systems with a long life that cruft, workarounds and ossified bad ideas accumulate.
junkblocker · 2014-05-27
rakoo · 2018-04-25
That's the thing, it doesn't. HTTP2 Push is one of the big "open field" of HTTP2, and to know whether a document needs to be pushed will rely on good heuristics and black magic.
There is however a small standard that's emerging, pioneered by h2o, called casper (https://h2o.examp1e.net/configure/http2_directives.html#http2-casper). The idea is that all resources ever sent to the client are stored in a probabilistic data structure in a cookie. On every request the structure is sent back to the server, which can then check whether the resource has good chances to be already known by the browser.
By the way there are some benchmarks done by h2o's author here: http://blog.kazuhooku.com/2015/10/performance-of-http2-push-and-server… The conclusion is all yours.