two-pot screamer dot com

From Slashdot - Choice of Language for Large-Scale Web Apps?

Everything, huh? (Score:5, Funny)
by LibertineR (591918) on Saturday July 30, @04:32PM (#13203785)

And people wonder why geeks dont get laid.

It is Saturday, and instead of being out in the sunshine, taking in rays, talking to women, GOING OUTSIDE, here we are, in front of our screens debating about which language to build our web apps with? Can we suck enough?

Dont bother replying, because when this damn compile is done, I am going outside if it kills me. I wont be here to read any replies, dammit.

Re:Everything, huh? (Score:5, Funny)
by Jeremi (14640) on Saturday July 30, @06:14PM (#13204278)
(http://www.lcscanada.com/jaf)

and instead of being out in the sunshine, taking in rays, talking to women, GOING OUTSIDE, here we are, in front of our screens debating about which language to build our web apps with?

The problem with talking to women is that so few of them have anything interesting to say about whether or not C++ is better than Perl… ;^)

Re:Depends on what you want to do… (Score:5, Informative)
by Space cowboy (13680) * on Saturday July 30, @03:30PM (#13203421)
(Last Journal: Thursday July 07, @08:37PM)

People will say that it doesn’t scale but they base this opinion on a preset prejudice or on the scalability of the underlying architecture.

What people mean by ‘it doesn’t scale’ is that it doesn’t scale. Not that it doesn’t run fast enough or have enough functionality for pretty much anything at the small-to-medium sized website…

I have a set of 200 or so websites all running though a self-built PHP template-based content-management system (hey, this was 8 years ago, they were rare then! :-) that has stood the test of time admirably. It’s only got a few million pages in it’s CMS, but it’s pretty cool:

• Typical page-creation is ~0.01 secs for complex pages
• Copes with (currently) several million users
• Handles email list management (opt-in only, don’t flame me :-)
• Separates the content from the formatting. Formatting is by recursive template instantiation.
• Can embed run-at-page-delivery-time PHP modules as CMS elements
• Has an Ad-server (flash, DHTML or images) which guarantees ad-placement in slots at a pre-paid rate
• Copes well with binary data (PDFs, images, movies, etc.)
• Handles image galleries from both user/admin perspective
• Has sections where extranet companies can “own” part of the sites
• Complete messageboard system, any number of boards, skinnable.
• Manages products, shopping basket etc. and integrates with online purchasing providers
• Provides newsfeeds in a variety of formats (RSS, XML via FTP, etc.)
• Provides a *fast* fulltext search that uses phrases, booleans, etc.
• Layers facilities on top of search (eg: site-editor can embed results of a search into an email (s)he composes. Preview, then deliver to opt-in list.)

And will all those features it’s still not scaleable. I can’t split the system over multiple webservers and begin a transaction on one webserver, have a hardware failure, and have it complete on a different webserver…

I server about a million page-impressions a day (less at weekends) so I’m hardly “big iron”, but at the moment it’s all serving from a single machine(*) with a manual backup ready-to-go. We’re (probably) about to triple our daily throughput (time to splash some cash :-), so scalability has become more important, and I’m looking into the best way of doing this.

I can’t have the above level of scalability but I can divide up the work over (say) 4 cloned webservers, and use round-robin DNS (low TTL) or transparent-proxy load-balancing to share the load. Then at least if one of the machines goes down (not the proxy ;-), I can have it automatically react and recover.

We’re probably going to have 2 database servers as well - one in slave mode, one in master mode (all writes to the master, because we use MySQL). The single point of failure then becomes the proxy gateway (because RR DNS is a bit of a pain), so we can have a spare standing by - the configuration of a load-balancing proxy is pretty trivial, and doesn’t depend on anything else, so it can be sitting ready to run and swapping ethernet patch cables ought to be all that is necessary.

And that’s about as “scalable” as I can make it - not very. All I’m doing is duplicating hardware for speed and reliability. I can have robustness against a machine dying, but that’s about as far as I can go. True scalability allows the operation the machine was doing when it died to complete successfully, and PHP ain’t there (yet). I guess you could implement it in s/w using lots of state tables, and perhaps get 80% of the way there, but it’s an add-on not a built-in, and not a complete solution. Better to go with something that works if you need it…

Just MHO.

Simon

(*) It is a bit of a beast of a machine though :-)

This entry was posted on Sunday, July 31st, 2005 at 10:50 pm and is filed under Scrapbook. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.