Earlier quoted context omitted.
Specifically it's garbage collection. e.g. node.js has no problem getting 20k/sec per core, but a stall at the wrong time kills every pipelined HTTP request that follows (until you tear down the connection and restart it).
Worth also mentioning that ad servers tend to have massive RAM requirements (again, for speed). GC in a 30GB JVM can take 10 minutes. To handle it, companies mark the boxes as 'inoperable' when they are in GC mode and remove them from the cluster until thy are ready to return. All of this is motivation to rewrite everything in C.
Nxweb – Fast and Lightweight Web Server
71–75 of 75 posts
Re: Nxweb – Fast and Lightweight Web Server
#72If CloudFlare can handle many thousands of sites [1] with nginx+lua then I'm not sure if it's worth it to go the C route. [1] https://groups.google.com/d/msg/openresty-en/aoBL22H8fP4/bJ3...
Re: Nxweb – Fast and Lightweight Web Server
#73Why? While Nxweb looks very promising, my first question would be 'Why should I use it over eg Nginx?' It would be helpful to have some direct comparison to other servers on the landing page. EDIT: Ok, there is a link to some odd benchmarks and it includes performance comparisons to Nginx and others which are not understandable (Nginx 141 req/s and Nxweb 200 / 121 req/s while it's not clear when 200 and when 121); mo…
Mongoose is a web server. See https://github.com/cesanta/mongoose . It's obviously not https://github.com/Automattic/mongoose .
Re: Nxweb – Fast and Lightweight Web Server
#74Earlier quoted context omitted.
We went from C++ to Go, and started to auto-lose any auctions whose bid requests were in progress during a GC cycle. Go 1.1/1.2 had atrociously long GC pauses (sometimes up to 500ms). You are correct that development efficiency was very important, so losing the auctions was justifiable.
Are things different with Go 1.5/1.6 now that GC has start to be optimized?
> The "stop the world" phase of the collector will almost always be under 10 milliseconds and usually much less.