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

51–60 of 87 posts

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

#51

Post by mrkeen »

atemerev wrote: post #3
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 miss this so much. Deployment should be just copying the file (over ssh or whatever). Why people overcomplicated it so much?

Perhaps. Over SSH? With a password or with a key? Do all employees share the same private key or do keys need to get added and removed when employees come and go. Is there one server or three (Are all deployment instructions done manually in triplicate?). When tomcat itself is upgraded, do you just eat the downtime? What about the system package upgrades or the OS? Which file should be copied over - whatever a particular Dev feels is the latest?

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

#52

Post by grandiego »

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…

I believe even today there's no way to control/isolate memory leaks on a per-war basis.

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

#54

Post by cb321 »

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 perlBesides 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 the "emacs is bloated" meme came from.

Anyway, at the time getline wasn't even standardized (that was 2008 POSIX - and still not in Windows; facepalm emoji), but you could write a pretty slick little library for CGI in a few hundred..few thou' lines of C. Someone surely even did.

But things go by "reputation" and people learn what their friends tell them to, by and large. So, CGI was absolutely the thing that made the mid to late 90s "Perl's moment".

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

#56

Post by Twirrim »

trinix912 wrote: post #31
Twirrim wrote: post #17

Earlier quoted context omitted.

We used to use symlinks to enable atomic operations, too. e.g. under /var/www/ we'd have /var/www/webapp_1.0, and have a symlink /var/www/webapp pointing to it. When there was a new version, upload it to /var/www/webapp_1.1, and then to bring it live, just update the symlink. Need to roll back? Switch the symlink back.

Wouldn't that cause problems when someone would find the old version and corrupt the data with it? Or would only the current version be accessible from the outside?

Your apache/whatever config would be pointed to the symlink location. No one would be able to get at the old versions of the site.

We'd use this approach not just for webapps, but versions of applications we'd build in house, bundles of scripts, whatever.

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

#58

Post by EasyMark »

sugarpimpdorsey wrote: post #5

Surprised with the choice of Apache. There are better choices for serving CGI nowadays. The only reason for still running Apache is you have legacy cruft that requires Apache (like .htaccess).

Apache works great for me and my small to medium loads. Sure it's not as fast as some of the lighter choices but the bottleneck isn't the webserver, it's all the database queries and network latencies.

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

#59

Post by EasyMark »

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…

I think he was just simply trying to revisit CGI and see how it compares from back in the day. Doing FastCGI would have been pointless if that was his primary goal.
Post reply on HN