5 ms·

They discount using CGI, which is fair enough, but why not use FastCGI? It's a sensible enough protocol, there are libraries for most languages and there's a go

They discount using CGI, which is fair enough, but why not use FastCGI? It's a sensible enough protocol, there are libraries for most languages and there's a good chance that your existing web server supports it. Technically, there's no good reason why a FastCGI based system would be significantly slower than a custom reimplementation like this.

geocar 11y ago
> Technically, there's no good reason why a FastCGI based system would be significantly slower than a custom reimplementation like this. An HTTP server speaking to a FastCGI application will: • read the HTTP message • decode HTTP • encode FastCGI • write to application The FastCGI application will then: • read the FastCGI message • decode the FastCGI message • do application stuff • encode the FastCGI response • write to the web server The webserver then resumes: • reading the FastCGI response • decoding the FastCGI response • writing the HTTP response Meanwhile, an in-process HTTP server (like nxweb) system will simply: • read the HTTP message • decode HTTP • do application stuff • write the HTTP response Less code runs faster; it is obvious to me why this is faster.
- iMerNibor 11y ago
  I'd imagine encoding/decoding will be really insignificant compared to generating the requested page or fetching data from a database in most, if not all, cases
  - geocar 11y ago
    Most websites do not see more than 100 requests per second. In those cases you are correct: parsing and de-parsing is insignificant compared to the amount of energy the computer is using to heat the room. However in order to do a trillion requests per day you need around 30 machines using a custom web server, or 300 machines using Fastcgi: In this situation the cost is an order of magnitude.
    - mhd 11y ago
      If you managed to get a trillion requests per day with a "hello world" scenario, you're probably also able to get 270 machines for free from your gullible incubator.
      - geocar 11y ago
        Most ad servers deliver static or hello-world-style content, doing no database lookups, but logging their results. RTB systems have about 30-100msec for the entire transaction (and that includes network to the user), so you need better control of your latency anyway.
    - jerf 11y ago
      Many people observe that as miles-per-gallon gets better and better, it begins to become a deceptive measurement in a way, because going from 10 to 20 mpg is a much, much larger change than going from 30 to 40, or even from 80 to 140. It seems people get a better sense of what's going on to measure gallons per mile. When you start doing that it becomes more clear that going from .0001 gallons per mile to .00001 gallons per mile, as large as it may be in orders of magnitude, still isn't that big a deal. Either way you're looking at your cost-of-fuel being effectively zero for all practical use cases, because your costs will be dominated by something else. Similarly, I've noticed that people tend to get a little silly about web server requests-per-second. It really gets to the point you probably ought to be talking about seconds per request, or perhaps rather, microseconds per request or something. Because A: as you start talking about these fast servers, you need to contemplate whether your code can run in, say, 2.5 microseconds either; who cares whether your webserver takes 2 or 25 microseconds to handle a minimal request if your minimal response requires 8 milliseconds (i.e. "8000 microseconds")? 8ms would actually be pretty decent performance for a wide variety of non-trivial web requests. And B: As the webservers get faster and faster, you really need to start wondering what corners they cut to push their reqs/s number up. I can make a blazingly fast webserver that would actually kill nginx's performance stone dead for a "return a constant JSON string response" task... the trick is that I'm not even going to look at the incoming web request, I'm going to just receive a socket, blast out my answer as a constant string buffer without even reading from the socket, and discard the socket. (If you're feeling particularly saucy, hook that up to a user-space TCP stack so you can drop the work of properly setting up and tearing down TCP connections.) There aren't that many real-world tasks for which that is a good solution (though, non-zero!), but it'll look like pure awesomesauce on the benchmark! Properly handling HTTP is non-trivial problem, and even moreso if it's going to be hooked up to a program rather than a static file system or something similarly easy. I actually start getting nervous about web servers that show excessively high numbers. If your performance is much better than nginx, rather than me cheering for joy, I actually have a lot of questions about how you did that exactly, and what my website's security profile looks like with your way-faster server. I'm not saying these questions are completely unanswerable; perhaps there is a way to safely do a much faster web server. I'm just saying that rather than my default response being celebration and "Oh wowzers cool!", my default reaction is a healthy dollop of skepticism.

geocar 11y ago

> Technically, there's no good reason why a FastCGI based system would be significantly slower than a custom reimplementation like this. An HTTP server speaking to a FastCGI application will: • read the HTTP message • decode HTTP • encode FastCGI • write to application The FastCGI application will then: • read the FastCGI message • decode the FastCGI message • do application stuff • encode the FastCGI response • write to the web server The webserver then resumes: • reading the FastCGI response • decoding the FastCGI response • writing the HTTP response Meanwhile, an in-process HTTP server (like nxweb) system will simply: • read the HTTP message • decode HTTP • do application stuff • write the HTTP response Less code runs faster; it is obvious to me why this is faster.

iMerNibor 11y ago
I'd imagine encoding/decoding will be really insignificant compared to generating the requested page or fetching data from a database in most, if not all, cases
- geocar 11y ago
  Most websites do not see more than 100 requests per second. In those cases you are correct: parsing and de-parsing is insignificant compared to the amount of energy the computer is using to heat the room. However in order to do a trillion requests per day you need around 30 machines using a custom web server, or 300 machines using Fastcgi: In this situation the cost is an order of magnitude.
  - mhd 11y ago
    If you managed to get a trillion requests per day with a "hello world" scenario, you're probably also able to get 270 machines for free from your gullible incubator.
    - geocar 11y ago
      Most ad servers deliver static or hello-world-style content, doing no database lookups, but logging their results. RTB systems have about 30-100msec for the entire transaction (and that includes network to the user), so you need better control of your latency anyway.
  - jerf 11y ago
    Many people observe that as miles-per-gallon gets better and better, it begins to become a deceptive measurement in a way, because going from 10 to 20 mpg is a much, much larger change than going from 30 to 40, or even from 80 to 140. It seems people get a better sense of what's going on to measure gallons per mile. When you start doing that it becomes more clear that going from .0001 gallons per mile to .00001 gallons per mile, as large as it may be in orders of magnitude, still isn't that big a deal. Either way you're looking at your cost-of-fuel being effectively zero for all practical use cases, because your costs will be dominated by something else. Similarly, I've noticed that people tend to get a little silly about web server requests-per-second. It really gets to the point you probably ought to be talking about seconds per request, or perhaps rather, microseconds per request or something. Because A: as you start talking about these fast servers, you need to contemplate whether your code can run in, say, 2.5 microseconds either; who cares whether your webserver takes 2 or 25 microseconds to handle a minimal request if your minimal response requires 8 milliseconds (i.e. "8000 microseconds")? 8ms would actually be pretty decent performance for a wide variety of non-trivial web requests. And B: As the webservers get faster and faster, you really need to start wondering what corners they cut to push their reqs/s number up. I can make a blazingly fast webserver that would actually kill nginx's performance stone dead for a "return a constant JSON string response" task... the trick is that I'm not even going to look at the incoming web request, I'm going to just receive a socket, blast out my answer as a constant string buffer without even reading from the socket, and discard the socket. (If you're feeling particularly saucy, hook that up to a user-space TCP stack so you can drop the work of properly setting up and tearing down TCP connections.) There aren't that many real-world tasks for which that is a good solution (though, non-zero!), but it'll look like pure awesomesauce on the benchmark! Properly handling HTTP is non-trivial problem, and even moreso if it's going to be hooked up to a program rather than a static file system or something similarly easy. I actually start getting nervous about web servers that show excessively high numbers. If your performance is much better than nginx, rather than me cheering for joy, I actually have a lot of questions about how you did that exactly, and what my website's security profile looks like with your way-faster server. I'm not saying these questions are completely unanswerable; perhaps there is a way to safely do a much faster web server. I'm just saying that rather than my default response being celebration and "Oh wowzers cool!", my default reaction is a healthy dollop of skepticism.