Slashdot Mirror
E-commerce with mod_perl and Apache
rob_99 writes: "Cool new mod_perl article at perl.com documents building a large scale ecommerce solution w/ mod_perl & apache!" Pretty cool stuff - it's kind of funny to think how ephemeral their work turned out to be.
No; I haven't had that problem at all. Perl is a
good language for writing understandable code.
I was recently contacted by some people about a
web site full of cgi scripts that I wrote several
years ago. They sorta apoligized for not getting
back in touch, explaining that the code was so easy
to understand and modify that they just did it and
didn't need to contact me. But now they had some
more sophisticated needs that they weren't sure they
could program, so they thought they'd call back an
expert.
So maybe the lesson here is that I should learn to
write less readable code. Then people won't be able
to modify it themselves, and they'll have to hire
me to make trivial changes.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
But an application server it is not. Container managed persistance, transactional support, message queues, naming and lookup services? Integration with existing business objects and processes? These aren't trivial in Perl, but they are the core functionality of app servers. They pulled off clustering for eToys, but it was hardly an out of the box solution.
If all you want is a servlet container, don't spend the money on an application server. Tomcat works great and iPlanet bundles one with their web server.
But I gotta say, I would have loved to have been on that team for that. Though I would have rankled at the suggestion of needing "help" with object oriented programming, it would have been worth it to meet those two.
"Avast! Prepare for the rodgering!" THWACK! "Arrr.. me nards.."
C++ guy who did industrial OO perl for two years --
.15 seconds with perl. The images loading (even on broadband) will be the gating factor on pageloads.
[quick disclaimer, feel free to use ruby or php for a substitute for perl below]
Perl is very good for a much larger range of projects than you think. [with a HUGE deference to C++/OO people, see note at bottom]. Very few sites rely on pure computational power. Most sites only need a small compenent to be fast, and that you can implement in the language of you choice with perl bindings. The majority of your site is glue -- and this is what perl does well.
I worked for a small team (5 developers) that wrote 200k lines of perl in a year and a half. That represents a far larger body of code if it had been written in another language. That isn't to say you lose control by using perl. You get to ignore the details, and in the bargain get a perfect language (and some extra time) to write regression tests.
All in all, unless you are a games site that cares about milliseconds, you can get a page out the door in under
-spRed
the deference to OO folk, you can teach people who only know C++/Java perl, you can't teach people who only know perl the others. The reason why is that real CS educations are portable. Perl [and other interpreted languages] are looked down upon by CS folk - so only non-CS folk will persue perl as a primary language. Perl is, however, extremely useful for whatever you are doing (95% of you). Give it a chance, it will save you alot of time in the long run.
.sig Karma out the wazoo, better to spend points elsewhere if this is above 2 or below 0
Perl allows you to do some really cool things, like fit 10-20 lines of code in any other language into 1 line of Perl. (Here's the proof.) Of course, you pay the penalty for being "clever" 6 months down the road.
It's good to remember that just because you can do something, it doesn't mean you should do it.
Seriously though, if you've ever had to debug or maintain someone else's code, you should know how much trouble Perl can make for you. I'd almost rather debug assembly...almost. ;-)
Turambar
------------------------------
Common sense is not so common.
--Voltaire
I part own an e-commerce company that's partly built with Apache/mod_perl/MySQL. We crank millions of dollars through those servers every week (porn still pays, what can you say ;-). The compile time of a script that pulls in libraries with 200k+ lines of code without mod_perl is several seconds. With, it's < 1sec. True we have/need 4GB RAM/server, but it does allow us to scale to whatever we want.
;-)
I often read articles saying perl/mysql can't handle enterprise solutions. Well, it can, does and is doing so in our case. Like any tool, it's as effective as the people wielding it.
We also have a huge codebase in C/C++, Java, Python and a few others. There's even a few NT boxes thrown in for dealing with some obscure hardware. I'm not particularly bias one way or the other, I just need the results.
By the by, I do have one solution for ensuring my programmers don't take sloppy shortcuts and write obviously quick and dirty code. It's the pink slip method. I find it works equally well in any language
Robert Nice
WebsiteBilling.com Inc.
Where is the advantage of this over a simple round-robin scheme? With round-robin each server will at least get the same number of sessions to start. With your scheme it'd be possible to for a couple of machines to be bogged down while the rest are relatively idle. Sure that might be unlikely to happen but I don't understand why you would even give it the chance.
This leads to a total mess, and even when the mess is kept under control it's usually with lame templating techniques like having a standard header and footer, which are initially expedient but not very flexible. "Initially expedient" is exactly what the *SP languages achieve, but at the price of later ease of development.
Of course, you can use any of those languages with a <% at the top of the file, and %> at the bottom, with an entirely seperate templating solution, but that kind of renders the whole point of those implementations moot. In my own experience with PHP, my code has started as normal, mixed-HTML/PHP code, and eventually ended up as just one chunk of PHP code.
I used to work for eToys.
In November, eToys had over well over 1000 employees. By March, they had fired all but a 10-20 employees (all management), and most of those people are gone by now. Few of these 1000 employees received their full severance package because eToys had no money (This was a violation of the contract, but suing was a lengthy and tedious option).
Between December of 1999 and December of 2000, eToys burned though several *HUNDRED* million dollars in funding.
KB Toys bought the eToys merchandise (toys), the eToys brand, some of the computer hardware (but not the intellectual property needed to maintain it, e.g. the engineers and administrators), and I think the warehouses (One of the warehouses was a $20-million high tech warehouse).
That counts as going under.
Their only successful subsidiary, Babycenter.com, lives on. But they don't use mod_perl (It's an Apache + java application server shop).
Every time I see a post like this, I have to ask...what do you think of 'normal' gui applications? ie, GTK or even raw X11 Protocol stuff? You certainly don't separate your interface from the code driving it there, so what is your point with embedded scripting? Seriously.
On a good team, embedded stuff is a joy. You can have your layout artists do their mockup, and then you just insert the code into their mockup to make it all work. The layout guys can still use their gui publishing tools, and you just have to link the code to the forms. Dangerous with idiots, but very effective when the page layout guys are smart enough to keep their hands off anything between the [($|-|+|#]'s
Yes it does...
I too was an eToys employee and the fact that babycenter lives on is no testament to java's superiority, or lack thereof.
In fact, eToys' demise had nothing to do with the technology used. Bad press, spiralling dotcom confidence, burn rate envied by the biggest brush fires all had more of a fatal impact.
If anything, I'd say that because the site was so stable and scalable, the technology used kept the company alive as long as it it did.
Had etoys.com site gone down as fast, as often and as furious as the toysrus.com site did, it would have disintegrated long before the 2000 Christmas season even got
started!
java, mod_perl, etc, etc are only as solid/scalable as the team developing on it. eToys had a world-class development team.
I wish I could say the same for styleclick.com, who used java/tomcat/Inprise!
Javier
"You can't subscript a Perl string character by character."
Am I missing something or are you missing the substr(x,y,z) function. Read in as much info as you want and substr it in a loop to grab chars. Admittedly the split function can't work on individual characters as it needs an IFS but substr seems to work ok for me.
Disclaimer : I'm not a coder and haven't tested the speed/CPU usage of this method.
Well, this shows that Apache and mod_perl have the speed, performance, configurability, etc, to get the job done. Why do we see so many Microsoft/ASP web sites?
I think that it's due to marketing. If the open source movement paid for advertising, publicity, etc, then a lot more people would consider the open source alternative, but they opt for the large company with marketing, and reps, and so on....
Note to ACs: I won't mod you up, even if you are being funny or insightful. So take a chance! It's not real life!
My personal favorite bit is the way you can suddenly create a new instance variable on a whim, just by assigning a value to $this->varName, halfway down a random function.
This, and I would think to say that all your piss-poor examples of why Perl is bad are cured with one statement:
Stop spreading FUD. I've seen and worked with many large, OO and non-OO Perl scripts which are a joy to maintain. You can get bad code in any language. Perl lets you shoot yourself in the foot if you want to. My personal preference is not to hire these types of programmers instead of complaining that the language is too flexible.
At that time, neither MySQL or PostgreSQL could handle the load from our traffic. Oracle also provided things we needed like transactions, replication, message queueing, foreign key constraints, etc. Yes, PostgreSQL had some of those at the time, but it had poor performance. Some of these things have changed since then, and it woudl be interesting to see how big PostgreSQL could scale these days.
I just want to add to my previous comment. You can embed things, but still keep the code pretty separate. Just write a bunch of modules, and then everything you want to do could just be (in embedded perl, for example) [+ &niftyfunction(@stuff) +] I think using embedded scripting in this fashion is even MORE readable than your separate code/layout way of thinking b/c you don't have a bunch of "print" crap getting in the way of what you are writing, and it also allows your layout guys to do the layout...much less work for you, the programmer, and everything is very maintainable, imagine that!
:) http://freefall.homeip.net/about/ Real projects I've been a part of, however, have some very nicely abstracted OO routines that allow programmers and layout folks to work together very efficiently using CVS.
Perl is highly flexible and can be very modular if you code it properly. My web page isn't a great example, but I do use one module on it
I can't say I agree that JSP, ASP, PHP, or any of the *SP family of languages are good design. They encourage exactly the opposite of MVC, they encourage you to mix HTML and (non-display related) programming code.
As it has been pointed out, at least with regards to JSP, "allows" does not mean "encourages". And talking about MVC, you should take a look at one of the many "MVC"-like implementations for Servlet development (be it using JSP or not).
Marcelo Vanzin