3 ms·
As someone who wrote a large, commercial social network for schools in Perl + CGI.pm in ~ 2000, here were the problems: * Perl was very memory inefficient so y
by rwmj 4y ago
As someone who wrote a large, commercial social network for schools in Perl + CGI.pm in ~ 2000, here were the problems:
* Perl was very memory inefficient so you could often only serve 4 users at the same time, given the limited RAM available (eg. 512M - 1G). Note that Perl's speed was not a problem. I suspect this one has probably gone away with modern servers with massive amounts of RAM, plus the cloud allows you to quickly scale up and down with demand. Nevertheless using a compiled language would be better. (I later wrote a vastly more efficient framework in C).
* Every action on the page had to round-trip to the server, and always involved a database check (at minimum to map the user's cookie to a user ID). This is sort of solved now that Javascript is widely supported, although that brings its own issues along. Also memcached neatly solves the database access problem. Our website was developed a little bit before memcached.
* It's very clumsy and time-consuming to write any non-trivial CRUD-style action using CGI. eg. Just having a table with update/delete buttons is going to involve writing paging code, update form, update submit form (repeat for every possible action). This is the kind of thing that Ruby on Rails solved quite nicely.
* Organizational problems interfacing with the database. We had to negotiate with the DBA for every schema change, which is a problem when the DBA is a sociopath supported by management. Devops sort of solves this (but also I appreciated not being on call).
* The general hassle of dealing with the web, like setting all the non-obvious HTTP headers to make it secure. I think modern frameworks just deal with this, although I've not used them very much.
However if I was to go back and change anything, it wouldn't have been to change the technology. It would have been to extend the service first to university students and later to the whole world :-)
- daneel_w 4y ago"Perl was very memory inefficient so you could often only serve 4 users at the same time, given the limited RAM available (eg. 512M - 1G). Note that Perl's speed was not a problem. I suspect this one has probably gone away with modern servers with massive amounts of RAM. Nevertheless using a compiled language would be better. (I later wrote a vastly more efficient framework in C)." I cannot even imagine the strange complexities of this circa year 2000 web application if it could only fit 4 simultaneous page loads on 1 GB of RAM. It's baffling, in fact. Perl isn't really memory hungry these days. Was it really that bad 20 years ago? I would be surprised if the Perl 5 interpreter wasn't in fact much leaner back then. At least my immediate impression of this bullet point is that it wasn't a programming language problem, but a software design problem.
- rwmj 4y agoWell it depends what you're doing of course. Part of the application was an email interface which I remember was a particular problem - it was likely loading whole emails into memory to do MIME parsing. But the point here is that large, slow processes gradually take over your system crowding out smaller and simpler requests. We had our own cage in a Docklands data centre, so "spinning up another server" was a weeks long process involving many people. In modern terms Perl isn't a problem, especially when you have servers with hundreds of gigabytes.
- daneel_w 4y agoI can safely say that it's not really an immediately impeding problem with 1 GB of RAM either. I have a bit of experience in the context as I develop and manage a very large Perl software stack that runs on a fleet of servers ranging from itty-bitty to small/medium. Some of it is inefficient CGI, some of it is FastCGI, some of it is resident in the background and some of it fires up on intervals. All of it is heavily trafficated. But, certainly, I'll concede that if the platform is completely CGI-based and for some reason is written such that there's a minimum footprint of 50-100 MB for any single invocation, then servers will be needing a bit of memory in lieu of a software rethink.
- ilyt 4y agoIt was definitely a software problem. Small Perl app would take few tens of MBs max back then (and now). Also Perl FCGI existed much earlier than 2000 (looking at CPAN ~'96-97 appear to be first versions), althought obviously the code would be bit more complex than just "dump html on stdout"