perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harry Zhu" <ha...@greatlodge.com>
Subject Re: [OT] modperl vs. Ruby
Date Mon, 27 Feb 2006 18:12:59 GMT
I'm very much interested.

Harry.



----- Original Message ----- 
From: "Enno" <burglar@xs4all.nl>
To: "Frank Wiles" <frank@wiles.org>
Cc: "Leo Lapworth" <leo@cuckoo.org>; <EMarkert@netscape.net>; 
<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 <leo@cuckoo.org> wrote:
>>
>> > On 26 Feb 2006, at 20:42, EMarkert@netscape.net 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 <frank@wiles.org>
>>    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
>
> 


Mime
View raw message