Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serving 200M requests per day with a CGI-bin

jacob.gold

Post reply on HN
Print view View original

71–80 of 87 posts

Re: Serving 200M requests per day with a CGI-bin

#71

Post by kiitos »

jacob2161 wrote: post #61
kiitos wrote: post #45

> I used plow to make concurrent HTTP requests and measure the results. If this refers to https://github.com/six-ddc/plow then -- oops! lots of issues in that repo, no tests, etc. etc. The results in the README are also pretty clearly unsound! In both scenarios, writes were faster than reads? _edit_: I guess because the writes all returned 3xx, oops again! Probably don't take this article's claims at face value...

(I didn't downvote you) plow may not be the best tool that exists but it does make concurrent HTTP requests and generate metrics for them successfully. The writes returned 3xx because the handler returns a redirect, so this is expected.

> plow may not be the best tool that exists but it does make concurrent HTTP requests and generate metrics for them successfully.

HTTP load testing is a problem area that is much more subtle than it seems. I've no doubt that plow does what you're saying here, but, without any tests whatsoever, I have serious doubts that it does so correctly, particularly if/when the load test starts bumping up against any of the numerous bottlenecks that can affect results and their measurements.

> The writes returned 3xx because the handler returns a redirect, so this is expected.

Yeah, but, unless `plow` actually follows that redirect, it's not really measuring the actual end-to-end latency, and further the guestbook.cgi returns 301 See Other for both valid requests (that performed a write) and invalid requests (that didn't).

Re: Serving 200M requests per day with a CGI-bin

#73

Post by canyp »

foobiekr wrote: post #27
cb321 wrote: post #12

Even back in the 1990s, CGI programs written in C were lightning fast. It just was (is) an error prone environment. Any safer modern alternative like the article's Go program or Nim or whatever not making database connections will be very fast & low latency to localhost - really similar to a CLI utility where you fork & exec. It's not free, but it's not that expensive compared to network latencies then or now. People…

You know, CGI with pre-forking (for latency hiding) and a safer language (like Rust) would be a great system to work on. Put the TLS termination in a nice multi-threaded web server (or in a layer like CloudFront). No lingering state, very easy to dump a core and debug, nice mostly-linear request model (no callback chains, etc.) and trivially easy to scale. You're just reading from stdin and writing to stdout. Gloriou…

> Websockets adds a bit of complexity but almost none.

There's websocketd, which makes your program just a matter of reading from stdin and writing stdout. http://websocketd.com/

Re: Serving 200M requests per day with a CGI-bin

#74

Post by ryao »

simonw wrote: post #20
geocar wrote: post #16

Earlier quoted context omitted.

I think you might have found that CGI scripts deployed as statically-linked C binaries, with some attention given to size, you might've not been so disappointed. The "performance hit of starting a new process" is bigger if the process is a dynamically-linked php interpreter with gobs of shared libraries to load, and some source file, reading parsing compiling whatever, and not just by a little bit, always has been, s…

That's likely true - but C is a scary language to write web-facing applications in because it's so easy to have things like buffer overflows or memory leaks.

If you use secure string functions, you can generally avoid buffer overflows in C. The problem is that not everyone does. That said, exploiting buffer overflows in programs whose source code and binaries are not public is very difficult. It likely can be done, but most people would likely go after easier targets. If you deploy AddressSanitizer in production, you can get the program to terminate whenever a buffer overflows occurs, at the expense of additional overhead when there is no buffer overflow.

Memory leaks are considered a feature in short lived programs, since not freeing memory in favor of relying on the kernel to free it at program exit lets them run faster.

Re: Serving 200M requests per day with a CGI-bin

#75

Post by lenkite »

whartung wrote: post #19
miroljub wrote: post #9

Earlier quoted context omitted.

It depends on the application usage pattern. For heavily used applications, sure, it's an excellent choice. But imagine having to host 50 small applications each serving a couple of hundreds requests per day. In that case, the memory overhead of Tomcat with 50 war files is much bigger than a simple Apache/Nginx server with a CGI script.

The other issue with Tomcat is that a single bad actor can more easily compromise the server. Not saying that can't happen with CGI, but since Tomcat is a shared environment, it's much more susceptible to it. This is why shared, public Tomcat hosting never became popular compared to shared CGI hosting. A rogue CGI program can be managed by the host accounting subsystem (say, it runs too long, takes up too much memory…

Well, James Gosling was working on the Java Isolates spec, but then Sun experienced financial difficulties and most of the future-thinking JSR (java specification request) work got frozen. Oracle had different priorities after acquisition - moving away from big, fat, enterprise app servers was a big no-no.

Re: Serving 200M requests per day with a CGI-bin

#76

Post by palmfacehn »

Traubenfuchs wrote: post #2

Try an apache tomcat 11 next. You can just dump .jsp files or whole java servlet applications as .war file via ssh and it will just work! One shared JVM for maximum performance! It can also share db connection pools, caches, etc. among those applications! Wow!

I'm still happily using Jetty for webapp backends.

Re: Serving 200M requests per day with a CGI-bin

#77

Post by dolmen »

cb321 wrote: post #54
perlgeek wrote: post #53

CGI scripts were one of the reason that perl was optimized for a quick startup time. I just did a `time perl -e ''` (starting perl, executing an empty program), it took 5ms. 33ms with python3, 77ms with ruby.

While all you say is true, it bears note that it didn't need to be decisive. The current mob branch of tcc is such that a `#!/bin/tcc -run` "script" is about 1.3x faster than perl Besides your two slower examples, Julia and Java VMs and else thread PHP also have really big start up times. As I said up top, people just get addicted to "big environments". Lisp culture would do that with images and this is part of where…

CGI is not anymore a major use case for Perl. The modern Perl web apps are built on PSGI and production deployment is as a long lived Perl process.

I wouldn't be surprised to learn that Perl startup time has drifted. Need benchmark.

Re: Serving 200M requests per day with a CGI-bin

#79

Post by cb321 »

dolmen wrote: post #77
cb321 wrote: post #54

Earlier quoted context omitted.

While all you say is true, it bears note that it didn't need to be decisive. The current mob branch of tcc is such that a `#!/bin/tcc -run` "script" is about 1.3x faster than perl Besides your two slower examples, Julia and Java VMs and else thread PHP also have really big start up times. As I said up top, people just get addicted to "big environments". Lisp culture would do that with images and this is part of where…

CGI is not anymore a major use case for Perl. The modern Perl web apps are built on PSGI and production deployment is as a long lived Perl process. I wouldn't be surprised to learn that Perl startup time has drifted. Need benchmark.

The major modern use case I know of is command-line utilities which also benefit from low start-up. Of course, that doesn't mean there hasn't been "perf rot" over the decades as you say. Such rot should never surprise anyone. :-)

Some perl5 lover should take the time to compile all those 5.6 to 5.42 versions on the same host OS/CPU and do a performance comparison and create a nice chart for the world to trap and maybe correct such performance regressions. I just tried getting 5.8.9 to compile on modern Linux with gcc-15, and it seemed like a real PITA. (Earlier didn't even ./Configure -des right.)

Re: Serving 200M requests per day with a CGI-bin

#80

Post by olcarl75 »

znpy wrote: post #40

Op is probably missing the point: 2400 requests/second is abysmally low on a modern 16 core cpu. At the very least go for FastCGI, for christ’s sake…

2400 requests is somewhat decent. Having seen companies like amazon, where their website backend can only handle a few hundred RPS per box, 2400 ain't that bad.
Post reply on HN