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.
I remember my first expierance with mod_perl. I was working for a small development company. That's not the key part
:)
The key part is that I was in charge of the perl backend, and it was really lagging. Loaded mod_perl up and *bam*, we had a fast enough system. I never did a serious benchmark, but it was like 100% improvment
Thus all I can say is good job guys! This doesn't surprise me at all, and it's good to see recognition get passed around in the correct quantity for once
Nope, no problems.
We use Embperl, which is Perl tags in HTML, like PHP. Embperl is very impressive.
I learned Embperl before PHP. Now I'm learning PHP on the side and feel that it is lacking features which Embperl includes. For example, in Embperl, I don't have to do "stripslashes" or "addslashes" when I read from a database. This makes the code cleaner. Also I can use straight HTML in between conditional statements without having to use "print" everywhere.
[$ foreach $key ( keys %ENV ) $]
My key is [+ $key +], which is [+ $ENV{$key} +]
[$endforeach $]
Nice and clean code
Well, unfortunately I have to disagree with Perl not being ecommerce suitable. Your issues likely stemmed from your choice of SSL library. We went with Apache, mod_perl, and Raven SSL in our Apache build. The ecommerce provider we use, Linkpoint, actually provides a .pm file as an API to their payment gateway. It was embarassingly easy to set up.
...
We also use HTML::Mason - the best mod_perl add on period.
Granted, we're not handling the volume of transactions as an eToys.com, but we use an extremely similar hardware configuration and have been running successfully without issue for quite some time.
I cannot recommend Raven's SSL and HTML::Mason enough.
Jusy my 2 cents
If you've had a bad experience with PERL, give Perl a try!
how to invest, a novice's guide
Fully compiled? Servlets? C#? Apparently you've never heard about this thing called "byte-code". It's definitely not fully compiled. Perl doesn't have to be spaghetti, either. Read the article. If you know how to use Perl 5's OO features and ensure that you (and everyone you devlop with) always use them, you can stay on top of things. Not to mention the advantage you get from using a higher-level language.
Because Perl threads are experimental until 5.8 is released?
how to invest, a novice's guide
As for stripslashes and addslashes you should look into magic quotes with PHP.
As for too many print statements you can do <?=$variablename?> to print more concisely.
eToys had over 100 people coding plain vanilla HTML... is that a good example of how mod_perl can be used as an ecommerce app server?
mod_perl definately has it's uses, but eToys is a bad example. Remember, eToys went out of business, in part because they spent way too much money on hardware and had way too many employees doing simple jobs.
You would think a large site like eToys would make good use of templates and would reuse programming objects all over the place. This wasn't the case for eToys at all.
eToys initially felt it was too difficult to use mod_perl to create templates or reuse objects on their site. They almost never reused elements in their pages, and they had very few templates. There was hardly anything there you could call an 'application server', and most of their pages were not dynamic (outside of store item entry).
Instead, they had over 100 HTML people to write the HTML for just about every single page on their site. It wasn't a very large site either. When I say 'HTML', I don't mean 'they wrote DHTML or PHP or java or perl. They had 100 people writing plain vanilla *HTML*.
Towards the end, eToys hired a few smart folks who knew the capabilities of mod_perl. They were on their way to creating a templated dynamic site. In the middle of this new effort, they went bankrupt.
(I used to work for eToys. Posting as AC to protect me from Toby Lenk's lawyers).
It's fixed in Apache 1.3.22. You could also disable the EXPAT rule when compiling Apache.
how to invest, a novice's guide
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.
This is why n-tier apps were invented. Javabeans, COM components, whatever. Just because you can put logic in your pages doesn't mean you should. Gives you the option to run threads asynchronously and/or via message queuing and increase your performance considerably.
Remarkably, in my experience building high performance (not necessarily highly scalable) sites, I've learned (from pain and suffering and/or other coders) that building those strings to push outo the buffer is often very expensive. You wouldn't think...
The other lesson I learned is the value of profiling tools. Particularly tools to show you what is going on at your database and a sniffer to show you what's going over the wire under load. I found problems that I would never have noticed without these tools.
BRENT ROCKWOOD, EST'd 1975
TrustCommerce offers a drop in .pm module as well for people writing perl front ends to their web sites. The Raven SSL package allows apache to serve https, not make ssl connections from a perl program. The trouble with SSL in perl is not serving https+mod_perl, its in writing those easy drop in .pm modules for connecting to the eCommerce gateways. Lucky for all you eCommerce site developers, we gateway programmers get to worry about that, not you.
I don't think Adam's comment was meant to detract from the power of something like Mason and mod_perl for developing web site front ends. It was just that of all the API's we have open source libraries for (C, Perl, J2SE, J2EE, Python, PHP and ColdFusion), the Perl module was by far the hardest to develop as the existing tools lack some important features.
Actually, Scheme can be compiled. There are a number of implementations that just interpret it and relatively few that actually compile (Bigloo, MIT Scheme are the free ones that I can think of).
My only political goal is to see to it that no political party achieves its goals.
Yeah, it's called Apache 1.3.22. :)
Seriously, it wasn't a problem with mod_perl, but the way Apache would be built.
It's been fixed in the latest rev of Apache.
That C component has to go into the Apache server (and run with server privileges, with all that implies, like a potential for buffer overflow attacks) for mod_perl programs to use it.
Complete and utter BS.
What are "server privileges" ? Everything in apache runs under the nobody user (or configurable).
What potential for buffer overflow attacks? Show me one.
The component does *not* have to go into the Apache server for mod_perl programs to use it. Not even slightly. If that were the case, DBI would be unusable from mod_perl, wouldn't it? No-siree, the C component (expat) was included in Apache to support mod_dav. They modified expat slightly (and called it expat-lite), and thus we had symbol conflicts, and the wrong code being executed, and BOOM. So now Apache 1.3.22 uses the DSO expat, same as XML::Parser does, and the problems are gone.
Someone please mod me up or him down. Facts can be checked in the mod_perl and mod_perl-dev list archives.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
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.
Oh, actually my favorite bit is the way a piece of code will start referring to the value stored in a local variable that has never been declared or apparently assigned anywhere previously, and eventually you find out that it has been created out of thin air, because earlier it was passed as an argument to a function that took the parameter by reference.
Or the way that php's idea of variable typing is that if you perform a string operation on an array it has a habit of overwriting the array with the string "Array" rather than, oh, I don't know, a compile time error?
I find features like that really help code maintenance.
Whats wrong with this ?
Admittedly the split function can't work on individual characters as it needs an IFS but substr seems to work ok for me.
What about this
Or have I misunderstood ?
-- Oh Well
We also had a central server, but with a local cache on each machine to improve performance. Although it is possible for one machine to get more than its fair share of sessions, in practice it didn't happen. The load-balancer did a good job of sending new sessions to the least busy machine.
I think you're over-stating the necessity of these things. Container managed persistence is often a way to replace one short SQL statement with 3 long XML files. Message queues are trivial in a good database (Oracle). Naming and lookup services are need if you're using EJBs, but we didn't need EJBs.
They pulled off clustering for eToys, but it was hardly an out of the box solution.
How do you define out of the box? We didn't do much work beyond the custom programming that was needed for our application. The open source components filled in our anfrastructure needs very nicely. It wasn't a "packaged solution", but it was easier than many commercial packages I've had to use in the past.
Try learning Perl next time you're tempted to waste a little credibility. Want to walk a string a character-at-a-time?
Perl's s/// operator is implemented such that removing bits from the front of a scalar moves a pointer rather than shifting all the data.
So Perl programs that parse HTML, XML, or SGML typically have a C component.
So? Using the right tool for the right job is part of the Unix (and Perl, by extension) philosophy.
Greg Bacon
anti-slashite, not anonymous coward
Not true. There was a clean separation. The model objects didn't have any HTML or display code in them. The templates (views) had no control flow code, only formatting. The controller knew how to pick a view, but not what was in it.
What if eToys had survived the dot-com implosion, and bought or were bought by another company? How well would this system plug into (or be plugged into) any special-needs components of the new system? That's the real acid test of maintainability in the large.
We had well-defined and documented APIs for all of the components. The hard part in integrating with another system would have been the differences in core functionality, not the interfaces.
Maybe these standards exist for perl, and I haven't used it enough in an enterprise context to stumble across them. However, you can't help but stumble across the J2EE stuff when you work with Java. Are these standards perfect? No. Are they complete? No. But they're standards, and that's what makes pluggable components possible.
Only to the extent that you can move your J2EE app from one server to another. Every J2EE app uses the basic components (EJB, JSP, servlets, etc.) in its own way. You certainly can't just connect up your warehouse management code to someone else's shipping code without a thorough agreement on the interfaces. Expecting anything more than that is just dreaming.