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

61–70 of 87 posts

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

#61

Post by jacob2161 »

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.

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

#62

Post by ksec »

> I ran these benchmarks on an older 16-thread AMD 3700X

The 3700X is an 8 Core Zen 2 CPU. Or about 150 RPS per vCPU. By EOY we will have 256 Core Zen 6c EPYC, on a Dual Socket that is 512 Core or 1024 Thread. 153,600 RPS.

And in the old days a RPS is a single pageview, which isn't the case in the modern world.

CPU Core still have a healthy 5 - 10 years cost reduction roadmap. I wonder if CGI will make a comeback someday.

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

#63

Post by senko »

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.

That didn’t bother me so much (less than it should have), but string manipulation in C is tedious, man! And there was soo much string manipulation (none of it done by a helpful framework)…

I used Perl instead, which worked way better in that regard (+ taint based security was welcome in handling untrusted user input), and an enormous (for the time) CPAN ecosystem, but had other problems.

Python web ecosystem was a mess, so PHP3 it was (ah the “good” ol days of mysql_real_escape_string()) … until some enterprising individuals wrote Django and I happily switched. Thank you :)

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

#64

Post by josephernest »

Why would it be limited to ~ 100 connections on a 1-4 GB RAM server? Out of curiosity if we fork() httpd and exec() the cgi handler, it doesn't take the same RAM as the parent process and it could just take a few KB or MB, is that right? So I guess 1000+ concurrent connections even on a small server is possible.

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

#65

Post by anonzzzies »

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.

I made fork run a chroot and if it crashes, it doesn't really matter as it's just a fork. At that time, people weren't really generally good breaking out of a chroot using exploits.

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

#66

Post by jbverschoor »

cb321 wrote: post #48
jbverschoor wrote: post #35

Earlier quoted context omitted.

There were quite a lot of ISA and OS platforms when Java started. Java made a lot of sense. It was that, and a superb standard library

Ah. You refer to the "write once, run anywhere" marketing slogan at a time when there was a lot of JVM-to-JVM variability and JVM JITs were not very advanced. I didn't buy that slogan at the time (look at aaaaall that open source code running all over with ./configure) and always hated Java's crazy boilerplate verbosity combined with a culture to defend it as somehow "better". I mean, it's not like people ran Interne…

I mean, that slogan still holds true 30 years later.

I’ve never used Fortran.. I started out with basic and wanted to do C/C++ because of gamedev. I loved the syntax. Perhaps bc it made me feel smart. The C-style syntax is also big part what made Java popular.

However, I think more and more than the popularity is because Java was the de facto standard to teach at universities. The reason for that was that it was a very clear language, and easy to compile, unlike C, which has so many behavioral quirks, and ofc memory management.

These days Python is being taught in both CS and statistics, which creates a broader market and broader usage spectrum.

Ruby, in my opinion, got big because of rails, but loved because of the stdlib

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

#67

Post by immibis »

cenamus wrote: post #41
citrin_ru wrote: post #26

Earlier quoted context omitted.

CGI never was prohibitively expensive for low load and for high load a persistent process (e. g. FastCGI) is still better. CGI may be allows to handle 2k rps but FastCGI app doing the same job should handle more. You would need to start an additional server process (and restart it on upgrade) but it's worth to do if performance matters.

I agree, but if you're doing fastcgi, you might as well do http directly, with a relay in front of it (load balancing, tls termination, whatever).

CGI-based protocols transfer a bunch of metadata from the front end - such as the client IP address - without any injection or double-parsing vulnerabilities. Using HTTP twice means having more code and a greater security risk.

By the way if you're using nginx, then instead of FastCGI you might prefer SCGI, which does one connection per request and no multiplexing, so it's much simpler.

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

#68

Post by immibis »

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!

Tomcat/Jakarta EE/JSP is a surprisingly solid stack. I only tried it once. Everything mostly just worked, and worked pretty well. You get to write pages PHP-style (interspersed HTML and code) but with the full power of Java instead of a hack language like PHP. Of course that paradigm may not suit everyone, but you also don't have to handle requests that way as you can also install pure Java routes. It supports websockets. You can share data between requests since it's a single-process multi-threaded model, so you can write something with real-time communication. You can also not do that; JSP code (and of course local variables) is scoped to a request. Deployment is very easy: drop the new webapp (a single file) in the webapps directory, by any method you like e.g. scp, and when Tomcat notices the new file is there, it transparently loads the new app and unloads the old one. You do have to watch out for classloader leaks that would prevent the old app being garbage-collected, though - downside of a single-process model.

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

#69

Post by cb321 »

jbverschoor wrote: post #66
cb321 wrote: post #48

Earlier quoted context omitted.

Ah. You refer to the "write once, run anywhere" marketing slogan at a time when there was a lot of JVM-to-JVM variability and JVM JITs were not very advanced. I didn't buy that slogan at the time (look at aaaaall that open source code running all over with ./configure) and always hated Java's crazy boilerplate verbosity combined with a culture to defend it as somehow "better". I mean, it's not like people ran Interne…

I mean, that slogan still holds true 30 years later. I’ve never used Fortran.. I started out with basic and wanted to do C/C++ because of gamedev. I loved the syntax. Perhaps bc it made me feel smart. The C-style syntax is also big part what made Java popular. However, I think more and more than the popularity is because Java was the de facto standard to teach at universities. The reason for that was that it was a ve…

Besides already agreeing to disagree on the Java slogan & syntax, I agree with all you say. Familiarity/being taught in schools is for sure a huge deal. { Not really "news" - Steve Jobs used to give high schools Apple IIs for the same reason. :-) } When even Scheme-inventing MIT moved to Python the writing was on the wall.

I've always been a little surprised Nim wasn't more popular with its Python like syntax, Lisp like meta-power, C-like speed and usually automatic memory management. Ah well.

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

#70

Post by petee »

immibis wrote: post #67
cenamus wrote: post #41

Earlier quoted context omitted.

I agree, but if you're doing fastcgi, you might as well do http directly, with a relay in front of it (load balancing, tls termination, whatever).

CGI-based protocols transfer a bunch of metadata from the front end - such as the client IP address - without any injection or double-parsing vulnerabilities. Using HTTP twice means having more code and a greater security risk. By the way if you're using nginx, then instead of FastCGI you might prefer SCGI, which does one connection per request and no multiplexing, so it's much simpler.

I always wished that FastCGI's Filter & Authorizer roles became popular, it's a nice separation of duties
Post reply on HN