Just some glaring inconsistencies that I found: 1. > It’s less work for the user. You don’t have to setup Nginx. If you’re not familiar with Nginx, then using

Just some glaring inconsistencies that I found: 1. > It’s less work for the user. You don’t have to setup Nginx. If you’re not familiar with Nginx, then using Raptor means you’ll have one tool less to worry about. >For example, our builtin HTTP server doesn’t handle static file serving at all, nor gzip compression. Sounds like I would need nginx(or another frontend server) anyways? 2. > By default, Raptor uses the multi-process blocking I/O model, just like Unicorn. > When we said that Raptor’s builtin HTTP server is evented, we were not telling the entire truth. It is actually hybrid multithreaded and evented. So, which it is? I assume by default is multi-process + events, but a paid version offers multithreaded + events? If so, isn't unicorn's model of multi-process+blocking IO is pretty good as well because OS becomes load balancer in that case. Overall it seems they wrote a very fast web server. Kudos to that! But I don't think the web server was ever the problem for Rack/Ruby apps? Still on fence with this one until more details emerge. :-)