TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

251 点作者 kazuho超过 10 年前

21 条评论

moe超过 10 年前
Very nice work, competition is always good.<p>However, it seems worth mentioning that webservers haven&#x27;t been a bottleneck for a long time now. Your bottleneck is always disk I&#x2F;O, the network, or the slow application server that you&#x27;re proxying to.<p>For reference: Wikipedia[1] serves roughly 8k pageviews&#x2F;sec on average for a total of ~20 billion pageviews&#x2F;month.<p>Assuming each pageview consists of ~10 webserver hits we&#x27;re looking at ~80k requests&#x2F;sec.<p>This is within the realm of a <i>single</i> instance of either nginx or h2o on a beefy machine [on a <i>very</i> beefy network].<p>So, unless you plan to serve Wikipedia or Facebook from a single server, you&#x27;re probably fine picking your webserver software on the basis of features rather than benchmarks.<p>[1] <a href="http://reportcard.wmflabs.org/graphs/pageviews" rel="nofollow">http:&#x2F;&#x2F;reportcard.wmflabs.org&#x2F;graphs&#x2F;pageviews</a>
评论 #8798091 未加载
rkrzr超过 10 年前
Congrats on shipping! This project looks very interesting already and will hopefully pick up more contributors.<p>Is there already support for configuration files? Because for me the performance isn&#x27;t the most important issue, in fact the main reason I&#x27;m using nginx over Apache is that I don&#x27;t want to deal with .htaccess any more.<p>I think if you would consider adding support for the nginx config file format to H2O, thus making it a drop-in replacement for it (if all the used features are actually supported), you could give the project a huge boost.
评论 #8797347 未加载
评论 #8797587 未加载
评论 #8797342 未加载
评论 #8797286 未加载
scottlamb超过 10 年前
I&#x27;m skeptical of the performance numbers. First, like others here I don&#x27;t believe nginx&#x27;s performance will be a bottleneck for HTTP&#x2F;2. Beyond that, I suspect there are cases in which this code is much worse than nginx.<p>Here&#x27;s one. Look at the example request loop on &lt;<a href="https://github.com/h2o/picohttpparser/&gt;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;h2o&#x2F;picohttpparser&#x2F;&gt;</a>. It reads from a socket, appending to an initially-empty buffer. Then it tries to parse the buffer contents as an HTTP request. If the request is incomplete, the loop repeats. (h2o&#x27;s lib&#x2F;http1.c:handle_incoming_request appears to do the same thing.)<p>In particular, phr_parse_request doesn&#x27;t retain any state between attempts. Each time, it goes through the whole buffer. In the degenerate case in which a client sends a large (n-byte) request one byte at a byte, it uses O(n^2) CPU for parsing. That extreme should be rare when clients are not malicious, but the benchmark is probably testing the other extreme where all requests are in a single read. Typical conditions are probably somewhere between.
评论 #8799352 未加载
stephth超过 10 年前
Interesting article. And congratulations for the release!<p>Sorry this is a bit off-topic (and doesn&#x27;t apply to H2O as it&#x27;s been in the works for a while looking at the commits), but I wonder, today, with a language like Rust (1.0 is at the door [1]), as performant as its safe C equivalent but modern and safe by design (and with an escape hatch to C&#x2F;C++ if needed), what would be the advantages of starting a long term project of this type in C today?<p>[1] <a href="http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html" rel="nofollow">http:&#x2F;&#x2F;blog.rust-lang.org&#x2F;2014&#x2F;12&#x2F;12&#x2F;1.0-Timeline.html</a><p>Edit: why the downvotes?
评论 #8797476 未加载
评论 #8797718 未加载
评论 #8797658 未加载
评论 #8797585 未加载
评论 #8805458 未加载
评论 #8797480 未加载
评论 #8797482 未加载
halayli超过 10 年前
This doesn&#x27;t look like a complete HTTP server, comparing it with nginx is not fair.<p>. It&#x27;s missing content-encoding handling on the receiving side<p>. No http continue support<p>. No regex routing support<p>. No header rewrites<p>to name a few.
评论 #8798392 未加载
robbles超过 10 年前
&gt; Instead, switching back to sending small asset files for every required element consisting the webpage being request becomes an ideal approach<p>This doesn&#x27;t solve the other side of the problem that spritesheets are meant to solve, namely that an individual image will not be loaded yet when the first UI element using it is displayed (e.g. in a CSS rollover, or new section of a SPA appears). I can&#x27;t see a way that new protocols are going to solve this, unless I&#x27;m missing something in how HTTP2 is going to be handled by the browser?<p>I assume that once you&#x27;re forced to preload everything you might need for the page, it&#x27;s no longer more efficient to break up into multiple tiny requests.
评论 #8797459 未加载
评论 #8798704 未加载
评论 #8797684 未加载
Shish2k超过 10 年前
Looking at the tangentially linked qrintf project that H2O uses ( <a href="https://github.com/h2o/qrintf" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;h2o&#x2F;qrintf</a> ), replacing generic sprintf calls with specialised versions for a 10x speed boost - that seems like a brilliant idea, I wonder why it took so long for somebody to think of it?
评论 #8797299 未加载
评论 #8797352 未加载
评论 #8797393 未加载
评论 #8797324 未加载
zzzcpan超过 10 年前
Socket API is a bottleneck now, right? So, next step: roll your own http-friendly tcp stack on top of netmap&#x2F;dpdk and get 10x performance increase over nginx.
评论 #8798100 未加载
jarnix超过 10 年前
Obviously it&#x27;s great software. Does Kazuho work alone on this ? If it&#x27;s meant to replace nginx, it needs a lot of other options&#x2F;functions&#x2F;extensions&#x2F;modules&#x2F;...<p>Is it getting commercial support&#x2F;funds ?
评论 #8797360 未加载
PythonicAlpha超过 10 年前
Looks very promising!<p>I am not so much into web-servers (yet), but I found this in the feature list:<p><pre><code> reverse proxy HTTP&#x2F;1 only (no HTTPS) </code></pre> Are there any plans to add also HTTPS-support for reverse proxy? Since I have to include a secondary (Tornado) web-server unto my stack for dynamic pages.<p>It also puzzled me, that https is not supported, but in the benchmarks I found a part: &quot;HTTPS&#x2F;2 (reverse-proxy)&quot;. As I said, I am not so much in Web-servers and https&#x2F;2, but that was a little confusing.
评论 #8797368 未加载
jvehent超过 10 年前
That&#x27;s a cool project. Performance is a fascinating topic.<p>However, in the real world, the number of requests per second a http daemon can perform is the last thing to worry about. If the web is slow, it&#x27;s not because Apache used to be bloated with thread. It&#x27;s because of bad architecture: centralization of services, latency in page builds time, size of static components, data store bottlenecks, etc...<p>Nevertheless, a very cool project. One I&#x27;ll follow closely.
ams6110超过 10 年前
Another one to keep an eye on might be the new httpd in OpenBSD. <a href="http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/httpd.8" rel="nofollow">http:&#x2F;&#x2F;www.openbsd.org&#x2F;cgi-bin&#x2F;man.cgi&#x2F;OpenBSD-current&#x2F;man8&#x2F;...</a><p>I&#x27;m not seeing that there is yet a portable version however.
评论 #8797463 未加载
bkeroack超过 10 年前
If you&#x27;re relying on HTTP for all your microservices, you&#x27;re doing it wrong.
评论 #8797693 未加载
dschiptsov超过 10 年前
So, it has better string, pool allocators, zero-copy buffers and syscall support than nginx&#x2F;core&#x2F;*.ch? That would be a mirracle.
Aldo_MX超过 10 年前
I love this kind of projects which people receive with much skepticism, but after some years will bring interesting improvements to us.
thresh超过 10 年前
Hello there, can you share the performance test details? The configurations of both servers, client software, hwserver setups.<p>Thanks!
haosdent超过 10 年前
I couldn&#x27;t understand why it could faster than Nginx? Maybe the way of benchmark nginx in this case is wrong?
huhtenberg超过 10 年前
That&#x27;s a very good code. Succinct and readable. You clearly now your C well :)
xfalcox超过 10 年前
Any plans to get script support, like nginx access_by_lua?
okpatil超过 10 年前
It seems that everything mentioned in the library could be done with golang easily. I am interested to see how H2O benchmarks with pure golang binaries.
caycep超过 10 年前
whoa, and here i was thinking nginx was the be all end all of sweet sweet blistering speed...