I'm very much interested.
Harry.
----- Original Message -----
From: "Enno" <[EMAIL PROTECTED]>
To: "Frank Wiles" <[EMAIL PROTECTED]>
Cc: "Leo Lapworth" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<modperl@perl.apache.org>
Sent: Monday, February 27, 2006 10:46 AM
Subject: Re: [OT] modperl vs. Ruby
Just starting to look at Catalyst, cause we have to rewrite a lot of
stuff here. So far I'm just installing and the incredible amount of
dependencies there are, are scaring the hell out of me (think huge
processes).
It looks like its including an immense load of pure perl modules for
functionality thats already present in mp2+apreq2. (but I might be wrong)
So what I'm gonna do now is benchmark a simple catalyst app versus a pure
mp2+apreq2 handler.
Will post results back to the list, if anyone is interested.
Enno
On Sun, 26 Feb 2006, Frank Wiles wrote:
On Sun, 26 Feb 2006 22:08:56 +0000
Leo Lapworth <[EMAIL PROTECTED]> wrote:
> On 26 Feb 2006, at 20:42, [EMAIL PROTECTED] wrote:
>
> > Good conversations...
> >
> > One question that I keep asking myself about RAD frameworks like
> > Catalyst is yeah, they're nice to develop a quick solution but how
> > well do they scale?
> >
> > In particular, I'd like to use Catalyst but I haven't seen much
> > traffic about large application success stories...
>
> [snip]
>
> So my personal approach is get it working, then refractor and keep
> doing so as you need to, focus on where you have to optimise
> (usually just a few
> core pages on most sites), but make the rest of it easy to add
> features, maintain etc.
I think this is a problem we all deal with at some point. I am as
guilty as the next guy. It is generally known as "premature
optimization". The 37Signals guys have blogged about it, I just
recently blogged about it.
The truth is that 99.9% of this effort is a waste of time. You can
never know for absolute sure where your performance problems are
going to show up. Some sections of your app may get used more than
you expect, some less. You may add a feature 6 months after launch
that impacts your performance or doesn't fit well with your
particular framework more than any development you did pre-launch.
Sure you can make a few guesses in advance as to what is going to
slow down your particular application and avoid making a stupid
mistake. This gets easier and easier as you acquire more experience
with your particular set of tools whatever they may be.
But even some of the generally accepted "best practices" can be
proven wrong. I've heard many people say something along the
lines of "You can't scale an application to any real size without
pooling your database connections", but I've done it and seen it
done by others.
For every "X doesn't scale" or even "X doesn't scale as well as Y"
argument, I'm willing to bet there is someone out there doing it.
The reason it is a waste of time is that you're taking time now to
at least ponder, probably contemplate for awhile, or worse change
how you are developing your application based upon something that
MIGHT happen in the future if certain conditions are met.
I view it like insurance. You have to balance the likely hood of
the problem with the amount of time spent on it. I have car
insurance because car accidents are pretty likely. But I don't
have a special insurance policy to protect me from a rabid gorilla
attacking me with an aluminum baseball bat, while I'm in the shower,
on a Tuesday or Thursday in months that begin with the letter J,
because it is pretty unlikely that it will happen.
Not to sound like a PHB, but you have to think about the ROI as
well. In general hardware is cheaper than programmer time. It's
not uncommon for companies to spend $10k on programming labor to
fix a problem that could be solved with $5k of additional hardware.
Do yourself a favor and just go code. Worry about performance
problems when you have them. You literally don't have a performance
problem until you have an application.
Sure, if you know for a fact that you need to support 20,000
simultaneous users out of the gate, then you have to plan accordingly,
but if you aren't 100% sure and end up with only 20 users all of that
work is an absolute waste of time that could have been better spent on
something else.
Like filling out the insurance paperwork for your new rabid gorilla
policy. :)
---------------------------------
Frank Wiles <[EMAIL PROTECTED]>
http://www.wiles.org
---------------------------------
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 268.1.0/269 - Release Date: 2/24/2006
