Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: ModPerl

Re: Why people not using mod_perl

  

 
First page Previous page 1 2 Next page Last page  View All ModPerl modperl RSS feed   Index | Next | Previous | View Threaded


pangj at vfemail

Sep 16, 2009, 1:52 AM

Post #1 of 34 (2722 views)
Permalink
Re: Why people not using mod_perl
On Tue, 30 Nov 2004 22:38:11 +0000
modperl[at]att.net wrote:

> 3) capacity/scalable
>
> mod_perl is very scalable --- I mean, one can properly
> config a single server to handle dynamic content for
> 200K daily unique IPs. PHP may end up with just 100K
> and servlet ends up at around 50K.
>

I'm just curious, is this performance data still true in today?
We have a new project building a website for a goverment which should
handle lots of transportation data, servlet and modperl are two
choices. So I googled and found this old message.

http://www.gossamer-threads.com/lists/modperl/advocacy/75311


pharkins at gmail

Sep 16, 2009, 11:32 AM

Post #2 of 34 (2658 views)
Permalink
Re: Why people not using mod_perl [In reply to]
On Wed, Sep 16, 2009 at 4:52 AM, Jeff Pang <pangj [at] vfemail> wrote:
> I'm just curious, is this performance data still true in today?
> We have a new project building a website for a goverment which should handle
> lots of transportation data, servlet and modperl are two choices.

I don't know what the source of that data was. However, mod_perl is
basically just Perl, and Perl is very fast. In most of the language
benchmarks I've seen, Perl comes out a little ahead of PHP and
somewhat behind Java. In real-world websites though, Perl often ends
up being faster than Java because of slow Java web frameworks and the
overly-abstract designs they encourage.

You can certainly succeed at building large websites with either Perl
or Java. I'd suggest you consider who will be doing the work and what
the expenses will be. If you decide to use Java, go with open source.
The commercial frameworks are slow and not worth the price.

- Perrin


ichudov at gmail

Sep 16, 2009, 2:30 PM

Post #3 of 34 (2656 views)
Permalink
Re: Why people not using mod_perl [In reply to]
My site algebra.com is about 80,000 lines of mod_perl code.

I wrote a relatively large framework, with many homegrown perl modules,
about five years ago.
It uses a database, image generation modules, a big mathematical engine that
I wrote (that "shows work", unlike popular third party packages), etc.

All pages of my site are dynamic and it is very image heavy due to math
formulae.

I can say two things:

1) It is relatively fast, serving pages in 0.1 seconds or so

2) Despite the quantity of code, and its age, it is still very maintainable
and understandable (to me).

If I was to make a choice again, I would go with mod_perl again. With Perl,
I can "stand on the shoulders of giants" like Lincoln etc, and use the
brilliant stuff they provided to serve my users.

i


fred at redhotpenguin

Sep 16, 2009, 2:42 PM

Post #4 of 34 (2654 views)
Permalink
Re: Why people not using mod_perl [In reply to]
On Wed, Sep 16, 2009 at 2:30 PM, Igor Chudov <ichudov [at] gmail> wrote:
> My site algebra.com is about 80,000 lines of mod_perl code.
>
> I wrote a relatively large framework, with many homegrown perl modules,
> about five years ago.
> It uses a database, image generation modules, a big mathematical engine that
> I wrote (that "shows work", unlike popular third party packages), etc.
>
> All pages of my site are dynamic and it is very image heavy due to math
> formulae.
>
> I can say two things:
>
> 1) It is relatively fast, serving pages in 0.1 seconds or so

It is fast, just visited it. However, I think you could get a faster
initial page load by compressing the html returned to the client using
mod_deflate. The main page request was 137 milliseconds and you could
probably drop that by 30-50% with gzipping the output.

Nice work!

> 2) Despite the quantity of code, and its age, it is still very maintainable
> and understandable (to me).
>
> If I was to make a choice again, I would go with mod_perl again. With Perl,
> I can "stand on the shoulders of giants" like Lincoln etc, and use the
> brilliant stuff they provided to serve my users.

Yes, that's why I use mod_perl. The core developers on the Apache
Httpd, and mod_perl core are world class.


thefatphil at yahoo

Sep 16, 2009, 2:59 PM

Post #5 of 34 (2653 views)
Permalink
Re: Why people not using mod_perl [In reply to]
--- On Thu, 9/17/09, Igor Chudov <ichudov [at] gmail> wrote:
> My site algebra.com is about 80,000
> lines of mod_perl code.
>
> I wrote a relatively large framework, with many homegrown
> perl modules, about five years ago.
> It uses a database, image generation modules, a big
> mathematical engine that I wrote (that "shows
> work", unlike popular third party packages), etc.
>
>
> All pages of my site are dynamic and it is very image heavy
> due to math formulae.
>
> I can say two things:
>
> 1) It is relatively fast, serving pages in 0.1 seconds or
> so
>
> 2) Despite the quantity of code, and its age, it is still
> very maintainable and understandable (to me).

In that case, would you like to fix its mangled output?

e.g. http://www.algebra.com/algebra/homework/divisibility/Prime_factorization_algorithm.wikipedia

  (Redirected from Prime factorization algorithm)

faster than O((1+ε)b) for all positive ε

an integer M with 1 ≤ M ≤ N

Pollard's p − 1 algorithm

Section 4.5.4: Factoring into Primes, pp. 379–417.

Chapter 5: Exponential Factoring Algorithms, pp. 191–226. Chapter 6: Subexponential Factoring Algorithms, pp. 227–284. Section 7.4: Elliptic curve method, pp. 301–313.

Eric W. Weisstein, “RSA-640 Factored”

v • d • e

AKS · APR · Ballie–PSW · ECPP · Fermat · Lucas · Lucas–Lehmer · Lucas–Lehmer–Riesel · Proth's theorem · Pépin's · Solovay–Strassen · Miller–Rabin · Trial division

Sieve of Atkin · Sieve of Eratosthenes · Sieve of Sundaram · Wheel factorization

CFRAC · Dixon's · ECM · Euler's · Pollard's rho · P − 1 · P + 1 · QS · GNFS · SNFS · rational sieve · Fermat's · Shanks' square forms · Trial division · Shor's

Ancient Egyptian multiplication · Aryabhata · Binary GCD · Chakravala · Euclidean · Extended Euclidean · integer relation algorithm · integer square root · Modular exponentiation · Schoof's · Shanks-Tonelli



Looks like you've got utf8 and iso8859-1 messed up.

Phil


thefatphil at yahoo

Sep 16, 2009, 3:02 PM

Post #6 of 34 (2655 views)
Permalink
Re: Why people not using mod_perl [In reply to]
It gets worse:
"""
Factor any number

Find all factors of [305550321722429173]

Solution by Factor any number
305550321722429173 is NOT a prime number: 305550321722429173 = 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 * 3 * 3 * 3 * 3 * 199 * 293 * 252718517
Work Shown

305550321722429173 is divisible by 2: 305550321722429173 = 1.52775160861215e+17 * 2.
1.52775160861215e+17 is divisible by 2: 1.52775160861215e+17 = 7.63875804306073e+16 * 2.
7.63875804306073e+16 is divisible by 2: 7.63875804306073e+16 = 3.81937902153036e+16 * 2.
3.81937902153036e+16 is divisible by 2: 3.81937902153036e+16 = 1.90968951076518e+16 * 2.
1.90968951076518e+16 is divisible by 2: 1.90968951076518e+16 = 9.54844755382591e+15 * 2.
9.54844755382591e+15 is divisible by 2: 9.54844755382591e+15 = 4.77422377691296e+15 * 2.
4.77422377691296e+15 is divisible by 2: 4.77422377691296e+15 = 2.38711188845648e+15 * 2.
2.38711188845648e+15 is divisible by 2: 2.38711188845648e+15 = 1.19355594422824e+15 * 2.
1.19355594422824e+15 is divisible by 3: 1.19355594422824e+15 = 397851981409413 * 3.
397851981409413 is divisible by 3: 397851981409413 = 132617327136471 * 3.
132617327136471 is divisible by 3: 132617327136471 = 44205775712157 * 3.
44205775712157 is divisible by 3: 44205775712157 = 14735258570719 * 3.
14735258570719 is divisible by 199: 14735258570719 = 74046525481 * 199.
74046525481 is divisible by 293: 74046525481 = 252718517 * 293.
252718517 is not divisible by anything.
"""


bvs7085 at gmail

Sep 16, 2009, 3:31 PM

Post #7 of 34 (2655 views)
Permalink
Re: Why people not using mod_perl [In reply to]
This is a mod_perl list, so I would expect to see Perl championed pretty
heavily, but Java, .net and there ilk are undoubtedly *the* choice for
large web applications. I'd like to get into some discussion as to why
almost all *large* sites choose these languages.

I don't have any experience developing a large application in Java,
although I do have a lot of experience working on the operations side of
a large web application that is Java based.

The reasons I generally hear for choosing Java over mod_perl are:

1) Speed - I don't buy this at all
2) Maintainability - I think this makes sense. Perl can be pretty easy
to maintain if you stick a good framework around it, but you have to
seek out that framework and YOU are responsible for adhereing to it.
All of that is inherent in Java. It also helps that Java has OO built in.
3) Easier to package and build/move code - In my experience this is true.
4) Advantages to be gained from running on an actually application
server - Also valid
5) Compatible enterprise class middleware - Also true, Java plugs into
more truly enterprise level suff than Perl does. (security frameworks,
etc... )
6) Support

A lot of the industry seems look at Perl as obsolete technology that has
been replaced by *insert hot new technology of the week here* which is
a total shame. I've worked with a lot of technologies and I think Perl
is a great choice for small/medium websites and webapps, which is
probably what most of us work on. But I'm very interested to know at
what point (if any) a site/app grows too large or too complex for
mod_perl and what defines that turning point. Could Amazon run on
mod_perl for example?
>
>
>
>
> Phil Carmody wrote:
>> --- On Thu, 9/17/09, Igor Chudov <ichudov [at] gmail> wrote:
>>
>>> My site algebra.com is about 80,000
>>> lines of mod_perl code.
>>>
>>> I wrote a relatively large framework, with many homegrown
>>> perl modules, about five years ago.
>>> It uses a database, image generation modules, a big
>>> mathematical engine that I wrote (that "shows
>>> work", unlike popular third party packages), etc.
>>>
>>>
>>> All pages of my site are dynamic and it is very image heavy
>>> due to math formulae.
>>>
>>> I can say two things:
>>>
>>> 1) It is relatively fast, serving pages in 0.1 seconds or
>>> so
>>>
>>> 2) Despite the quantity of code, and its age, it is still
>>> very maintainable and understandable (to me).
>>>
>>
>> In that case, would you like to fix its mangled output?
>>
>> e.g. http://www.algebra.com/algebra/homework/divisibility/Prime_factorization_algorithm.wikipedia
>>
>> Â Â (Redirected from Prime factorization algorithm)
>>
>> faster than O((1+ε)b) for all positive ε
>>
>> an integer M with 1 ≤ M ≤ N
>>
>> Pollard's p − 1 algorithm
>>
>> Section 4.5.4: Factoring into Primes, pp. 379–417.
>>
>> Chapter 5: Exponential Factoring Algorithms, pp. 191–226. Chapter 6: Subexponential Factoring Algorithms, pp. 227–284. Section 7.4: Elliptic curve method, pp. 301–313.
>>
>> Eric W. Weisstein, “RSA-640 Factored”
>>
>> v • d • e
>>
>> AKS · APR · Ballie–PSW · ECPP · Fermat · Lucas · Lucas–Lehmer · Lucas–Lehmer–Riesel · Proth's theorem · Pépin's · Solovay–Strassen · Miller–Rabin · Trial division
>>
>> Sieve of Atkin · Sieve of Eratosthenes · Sieve of Sundaram · Wheel factorization
>>
>> CFRAC · Dixon's · ECM · Euler's · Pollard's rho · P − 1 · P + 1 · QS · GNFS · SNFS · rational sieve · Fermat's · Shanks' square forms · Trial division · Shor's
>>
>> Ancient Egyptian multiplication · Aryabhata · Binary GCD · Chakravala · Euclidean · Extended Euclidean · integer relation algorithm · integer square root · Modular exponentiation · Schoof's · Shanks-Tonelli
>>
>>
>>
>> Looks like you've got utf8 and iso8859-1 messed up.
>>
>> Phil
>>
>>
>>
>>
>>
>>


practicalperl at gmail

Sep 16, 2009, 6:42 PM

Post #8 of 34 (2652 views)
Permalink
Re: Why people not using mod_perl [In reply to]
On Thu, Sep 17, 2009 at 2:32 AM, Perrin Harkins <pharkins [at] gmail> wrote:

>
> I don't know what the source of that data was. However, mod_perl is
> basically just Perl, and Perl is very fast.


I think the more exact statement should be, mod_perl is compiled perl,
mod_perl is very fast.
But perl CGI...I must say it's very slow.

Jenn.


pharkins at gmail

Sep 16, 2009, 7:05 PM

Post #9 of 34 (2650 views)
Permalink
Re: Why people not using mod_perl [In reply to]
On Wed, Sep 16, 2009 at 9:42 PM, Jenn G. <practicalperl [at] gmail> wrote:
> I think the more exact statement should be, mod_perl is compiled perl,
> mod_perl is very fast.
> But perl CGI...I must say it's very slow.

Well, you can say CGI is slow, but Perl CGI is very fast compared to
the alternatives. Have you ever tried Java CGI? Or PHP CGI? They're
not fast.

Also, I don't like to tell people that mod_perl is "compiled" because
it's really no more compiled than any other perl script. If you want
to be precise, you could say mod_perl is a persistent daemon for
running perl code, just like servlets are a persistent daemon for
running Java.

- Perrin


practicalperl at gmail

Sep 16, 2009, 7:15 PM

Post #10 of 34 (2651 views)
Permalink
Re: Why people not using mod_perl [In reply to]
On Thu, Sep 17, 2009 at 10:05 AM, Perrin Harkins <pharkins [at] gmail> wrote:
> On Wed, Sep 16, 2009 at 9:42 PM, Jenn G. <practicalperl [at] gmail> wrote:
>> I think the more exact statement should be, mod_perl is compiled perl,
>> mod_perl is very fast.
>> But perl CGI...I must say it's very slow.
>
> Well, you can say CGI is slow, but Perl CGI is very fast compared to
> the alternatives. Have you ever tried Java CGI? Or PHP CGI? They're
> not fast.

but nobody run Java or PHP as CGI.
the only thing I heard is somebody run php as fastcgi under lighttpd.

>
> Also, I don't like to tell people that mod_perl is "compiled" because
> it's really no more compiled than any other perl script.

mod_perl loads and compiles perl scripts only once, but CGI loads and
compiles them every time for each request.
Am I right? thanks.


jeff_nokes at yahoo

Sep 16, 2009, 7:47 PM

Post #11 of 34 (2654 views)
Permalink
Re: Why people not using mod_perl [In reply to]
Doesn't Amazon run mod_perl/Mason?

BTW, I agree with most of your points (would debate #4,5). I may substitute the phrase "More convenient" for "Easier" in #3. I would also add ...

#7) How many engineers are available to hire that know or want to work with said technology?

I built a great platform at eBay on mod_perl/Mason that handled eBay-size traffic; we ran 6 eBay sites on it. Now it is used for specialty e-commerce solutions like worldofgood.ebay.com, global.ebay.com (cross-border trade), dealfinder.ebay.com, etc. In fact, on the same hardware, the main eBay Java app would support ~6 threads per box; the mod_perl platform supported ~60 (prefork), significant CapEx and power savings (which adds up at a place like eBay).






________________________________
From: Brad Van Sickle <bvs7085 [at] gmail>
To: mod_perl list <modperl [at] perl>
Sent: Wednesday, September 16, 2009 3:31:30 PM
Subject: Re: Why people not using mod_perl



This is a mod_perl list, so I would expect to see Perl championed
pretty heavily, but Java, .net and there ilk are undoubtedly *the*
choice for large web applications. I'd like to get into some
discussion as to why almost all *large* sites choose these languages.

I don't have any experience developing a large application in Java,
although I do have a lot of experience working on the operations side
of a large web application that is Java based.

The reasons I generally hear for choosing Java over mod_perl are:

1) Speed - I don't buy this at all
2) Maintainability - I think this makes sense. Perl can be pretty easy
to maintain if you stick a good framework around it, but you have to
seek out that framework and YOU are responsible for adhereing to it.
All of that is inherent in Java. It also helps that Java has OO built
in.
3) Easier to package and build/move code - In my experience this is
true.
4) Advantages to be gained from running on an actually application
server - Also valid
5) Compatible enterprise class middleware - Also true, Java plugs into
more truly enterprise level suff than Perl does. (security frameworks,
etc... )
6) Support

A lot of the industry seems look at Perl as obsolete technology that
has been replaced by *insert hot new technology of the week here*
which is a total shame. I've worked with a lot of technologies and I
think Perl is a great choice for small/medium websites and webapps,
which is probably what most of us work on. But I'm very interested to
know at what point (if any) a site/app grows too large or too complex
for mod_perl and what defines that turning point. Could Amazon run on
mod_perl for example?


>
>
>
>>Phil Carmody wrote:
>
>--- On Thu, 9/17/09, Igor Chudov <ichudov [at] gmail> wrote:
>>
>>My site algebra.com is about 80,000
>>>lines of mod_perl code.
>>>
>>>I wrote a relatively large framework, with many homegrown
>>>perl modules, about five years ago.
>>>It uses a database, image generation modules, a big
>>>mathematical engine that I wrote (that "shows
>>>work", unlike popular third party packages), etc.
>>>
>>>
>>>All pages of my site are dynamic and it is very image heavy
>>>due to math formulae.
>>>
>>>I can say two things:
>>>
>>>1) It is relatively fast, serving pages in 0.1 seconds or
>>>so
>>>
>>>2) Despite the quantity of code, and its age, it is still
>>>very maintainable and understandable (to me).
>>>
>>In that case, would you like to fix its mangled output?
>>
>>e.g. http://www.algebra.com/algebra/homework/divisibility/Prime_factorization_algorithm.wikipedia
>>
>>Â Â (Redirected from Prime factorization algorithm)
>>
>>faster than O((1+ε)b) for all positive ε
>>
>>an integer M with 1 ≤ M ≤ N
>>
>>Pollard's p − 1 algorithm
>>
>>Section 4.5.4: Factoring into Primes, pp. 379–417.
>>
>>Chapter 5: Exponential Factoring Algorithms, pp. 191–226. Chapter 6: Subexponential Factoring Algorithms, pp. 227–284. Section 7.4: Elliptic curve method, pp. 301–313.
>>
>>Eric W. Weisstein, “RSA-640 Factoredâ€
>>
>>v • d • e
>>
>>AKS · APR · Ballie–PSW · ECPP · Fermat · Lucas · Lucas–Lehmer · Lucas–Lehmer–Riesel · Proth's theorem · Pépin's · Solovay–Strassen · Miller–Rabin · Trial division
>>
>>Sieve of Atkin · Sieve of Eratosthenes · Sieve of Sundaram · Wheel factorization
>>
>>CFRAC · Dixon's · ECM · Euler's · Pollard's rho · P − 1 · P + 1 · QS · GNFS · SNFS · rational sieve · Fermat's · Shanks' square forms · Trial division · Shor's
>>
>>Ancient Egyptian multiplication · Aryabhata · Binary GCD · Chakravala · Euclidean · Extended Euclidean · integer relation algorithm · integer square root · Modular exponentiation · Schoof's · Shanks-Tonelli
>>
>>
>>
>>Looks like you've got utf8 and iso8859-1 messed up.
>>
>>Phil
>>
>>
>>
>>
>>
>>


pharkins at gmail

Sep 16, 2009, 8:13 PM

Post #12 of 34 (2649 views)
Permalink
Re: Why people not using mod_perl [In reply to]
On Wed, Sep 16, 2009 at 10:15 PM, Jenn G. <practicalperl [at] gmail> wrote:
> but nobody run Java or PHP as CGI.
> the only thing I heard is somebody run php as fastcgi under lighttpd.

Some cheap ISPs run PHP as CGI for security reasons. My point is, it
doesn't make any difference if Perl is slow when you run it as CGI,
since you don't need to run it as CGI any more than you need to run
Java that way.

> mod_perl loads and compiles perl scripts only once, but CGI loads and
> compiles them every time for each request.
> Am I right?

That's right. In both cases the perl code is compiled, but with
mod_perl the perl interpreter is kept in memory so it doesn't need to
recompile it each time.

- Perrin


smsiebe at gmail

Sep 16, 2009, 8:15 PM

Post #13 of 34 (2647 views)
Permalink
Re: Why people not using mod_perl [In reply to]
I would also add, in addition to the frameworks, the availability of tools
such as Netbeans and Eclipse IDE's are unmatched in the perl domain. These
IDE's provide many high-level conveniences for enterprise developers, most
notably in the realm of SOA (such as graphical building of BPEL and CEP).

After nearly 10 years building and maintaining a critical government system,
we are sadly migrating away from mod_perl to a J2EE based solution due to
the success and growth of our mod_perl-based system. mod_perl and MySQL has
served as well when we were taking on medium-to-large loads...however, as we
are growing to a distributed (multi-site, multi-node) system, with tie-ins
to numerous internal and external business systems across the enterprise,
with development partners working at distributed factories...tools such as
Netbeans and it's tight integration with Glassfish, SVN, and Hudson make
building at this level a lot more manageable. I found that mod_perl for
large-scale web applications works great, and if necessary horizontal
scaling is achievable to sustain even more load. However, when dealing with
complex SOA architectures, and the management of business workflows...the
framework support and tools to accomplish this just aren't there in perl.

Add to this Jeff's comment on the availability of high caliber perl
engineers...we are almost forced to make this decision.

We will continue to use mod_perl for other uses, such as our custom SCM/ALM
system we built over the years...but the main product is migrating.


On Wed, Sep 16, 2009 at 10:47 PM, Jeff Nokes <jeff_nokes [at] yahoo> wrote:

> Doesn't Amazon run mod_perl/Mason?
>
> BTW, I agree with most of your points (would debate #4,5). I may
> substitute the phrase "More convenient" for "Easier" in #3. I would also
> add ...
>
> #7) How many engineers are available to hire that know or want to work
> with said technology?
>
> I built a great platform at eBay on mod_perl/Mason that handled eBay-size
> traffic; we ran 6 eBay sites on it. Now it is used for specialty e-commerce
> solutions like worldofgood.ebay.com, global.ebay.com (cross-border trade),
> dealfinder.ebay.com, etc. In fact, on the same hardware, the main eBay
> Java app would support ~6 threads per box; the mod_perl platform supported
> ~60 (prefork), significant CapEx and power savings (which adds up at a place
> like eBay).
>
>
>
> ------------------------------
> *From:* Brad Van Sickle <bvs7085 [at] gmail>
> *To:* mod_perl list <modperl [at] perl>
> *Sent:* Wednesday, September 16, 2009 3:31:30 PM
> *Subject:* Re: Why people not using mod_perl
>
>
>
> This is a mod_perl list, so I would expect to see Perl championed pretty
> heavily, but Java, .net and there ilk are undoubtedly *the* choice for large
> web applications. I'd like to get into some discussion as to why almost all
> *large* sites choose these languages.
>
> I don't have any experience developing a large application in Java,
> although I do have a lot of experience working on the operations side of a
> large web application that is Java based.
>
> The reasons I generally hear for choosing Java over mod_perl are:
>
> 1) Speed - I don't buy this at all
> 2) Maintainability - I think this makes sense. Perl can be pretty easy to
> maintain if you stick a good framework around it, but you have to seek out
> that framework and YOU are responsible for adhereing to it. All of that is
> inherent in Java. It also helps that Java has OO built in.
> 3) Easier to package and build/move code - In my experience this is true.
> 4) Advantages to be gained from running on an actually application server -
> Also valid
> 5) Compatible enterprise class middleware - Also true, Java plugs into more
> truly enterprise level suff than Perl does. (security frameworks, etc... )
> 6) Support
>
> A lot of the industry seems look at Perl as obsolete technology that has
> been replaced by *insert hot new technology of the week here* which is a
> total shame. I've worked with a lot of technologies and I think Perl is a
> great choice for small/medium websites and webapps, which is probably what
> most of us work on. But I'm very interested to know at what point (if any)
> a site/app grows too large or too complex for mod_perl and what defines that
> turning point. Could Amazon run on mod_perl for example?
>
>
>
>
>
> Phil Carmody wrote:
>
> --- On Thu, 9/17/09, Igor Chudov <ichudov [at] gmail> <ichudov [at] gmail> wrote:
>
> My site algebra.com is about 80,000
> lines of mod_perl code.
>
> I wrote a relatively large framework, with many homegrown
> perl modules, about five years ago.
>
> It uses a database, image generation modules, a big
> mathematical engine that I wrote (that "shows
> work", unlike popular third party packages), etc.
>
>
> All pages of my site are dynamic and it is very image heavy
>
> due to math formulae.
>
> I can say two things:
>
> 1) It is relatively fast, serving pages in 0.1 seconds or
> so
>
> 2) Despite the quantity of code, and its age, it is still
> very maintainable and understandable (to me).
>
> In that case, would you like to fix its mangled output?
>
> e.g. http://www.algebra.com/algebra/homework/divisibility/Prime_factorization_algorithm.wikipedia
>
> Â Â (Redirected from Prime factorization algorithm)
>
> faster than O((1+ε)b) for all positive ε
>
> an integer M with 1 ≤ M ≤ N
>
> Pollard's p − 1 algorithm
>
> Section 4.5.4: Factoring into Primes, pp. 379–417.
>
> Chapter 5: Exponential Factoring Algorithms, pp. 191–226. Chapter 6: Subexponential Factoring Algorithms, pp. 227–284. Section 7.4: Elliptic curve method, pp. 301–313.
>
> Eric W. Weisstein, “RSA-640 Factoredâ€
>
> v • d • e
>
> AKS · APR · Ballie–PSW · ECPP · Fermat · Lucas · Lucas–Lehmer ·
> Lucas–Lehmer–Riesel · Proth's theorem · Pépin's · Solovay–Strassen · Miller–Rabin · Trial division
>
> Sieve of Atkin · Sieve of Eratosthenes · Sieve of Sundaram · Wheel factorization
>
>
> CFRAC · Dixon's · ECM · Euler's · Pollard's rho · P − 1 · P + 1 · QS · GNFS · SNFS · rational sieve · Fermat's · Shanks' square forms · Trial division · Shor's
>
> Ancient Egyptian multiplication · Aryabhata · Binary GCD · Chakravala · Euclidean · Extended Euclidean · integer relation algorithm · integer square root · Modular exponentiation · Schoof's · Shanks-Tonelli
>
>
>
> Looks like you've got utf8 and iso8859-1 messed up.
>
> Phil
>
>
>
>
>
>


ichudov at gmail

Sep 16, 2009, 8:26 PM

Post #14 of 34 (2649 views)
Permalink
Re: Why people not using mod_perl [In reply to]
You must have use my module Net::eBay, at some point, right?

I wrote Net::eBay about 3 years ago.

Igor

On Wed, Sep 16, 2009 at 9:47 PM, Jeff Nokes <jeff_nokes [at] yahoo> wrote:

> Doesn't Amazon run mod_perl/Mason?
>
> BTW, I agree with most of your points (would debate #4,5). I may
> substitute the phrase "More convenient" for "Easier" in #3. I would also
> add ...
>
> #7) How many engineers are available to hire that know or want to work
> with said technology?
>
> I built a great platform at eBay on mod_perl/Mason that handled eBay-size
> traffic; we ran 6 eBay sites on it. Now it is used for specialty e-commerce
> solutions like worldofgood.ebay.com, global.ebay.com (cross-border trade),
> dealfinder.ebay.com, etc. In fact, on the same hardware, the main eBay
> Java app would support ~6 threads per box; the mod_perl platform supported
> ~60 (prefork), significant CapEx and power savings (which adds up at a place
> like eBay).
>
>
>
> ------------------------------
> *From:* Brad Van Sickle <bvs7085 [at] gmail>
> *To:* mod_perl list <modperl [at] perl>
> *Sent:* Wednesday, September 16, 2009 3:31:30 PM
> *Subject:* Re: Why people not using mod_perl
>
>
>
> This is a mod_perl list, so I would expect to see Perl championed pretty
> heavily, but Java, .net and there ilk are undoubtedly *the* choice for large
> web applications. I'd like to get into some discussion as to why almost all
> *large* sites choose these languages.
>
> I don't have any experience developing a large application in Java,
> although I do have a lot of experience working on the operations side of a
> large web application that is Java based.
>
> The reasons I generally hear for choosing Java over mod_perl are:
>
> 1) Speed - I don't buy this at all
> 2) Maintainability - I think this makes sense. Perl can be pretty easy to
> maintain if you stick a good framework around it, but you have to seek out
> that framework and YOU are responsible for adhereing to it. All of that is
> inherent in Java. It also helps that Java has OO built in.
> 3) Easier to package and build/move code - In my experience this is true.
> 4) Advantages to be gained from running on an actually application server -
> Also valid
> 5) Compatible enterprise class middleware - Also true, Java plugs into more
> truly enterprise level suff than Perl does. (security frameworks, etc... )
> 6) Support
>
> A lot of the industry seems look at Perl as obsolete technology that has
> been replaced by *insert hot new technology of the week here* which is a
> total shame. I've worked with a lot of technologies and I think Perl is a
> great choice for small/medium websites and webapps, which is probably what
> most of us work on. But I'm very interested to know at what point (if any)
> a site/app grows too large or too complex for mod_perl and what defines that
> turning point. Could Amazon run on mod_perl for example?
>
>
>
>
>
> Phil Carmody wrote:
>
> --- On Thu, 9/17/09, Igor Chudov <ichudov [at] gmail> <ichudov [at] gmail> wrote:
>
> My site algebra.com is about 80,000
> lines of mod_perl code.
>
> I wrote a relatively large framework, with many homegrown
> perl modules, about five years ago.
> It uses a database, image generation modules, a big
> mathematical engine that I wrote (that "shows
> work", unlike popular third party packages), etc.
>
>
> All pages of my site are dynamic and it is very image heavy
> due to math formulae.
>
> I can say two things:
>
> 1) It is relatively fast, serving pages in 0.1 seconds or
> so
>
> 2) Despite the quantity of code, and its age, it is still
> very maintainable and understandable (to me).
>
> In that case, would you like to fix its mangled output?
>
> e.g. http://www.algebra.com/algebra/homework/divisibility/Prime_factorization_algorithm.wikipedia
>
> Â Â (Redirected from Prime factorization algorithm)
>
> faster than O((1+ε)b) for all positive ε
>
> an integer M with 1 ≤ M ≤ N
>
> Pollard's p − 1 algorithm
>
> Section 4.5.4: Factoring into Primes, pp. 379–417.
>
> Chapter 5: Exponential Factoring Algorithms, pp. 191–226. Chapter 6: Subexponential Factoring Algorithms, pp. 227–284. Section 7.4: Elliptic curve method, pp. 301–313.
>
> Eric W. Weisstein, “RSA-640 Factoredâ€
>
> v • d • e
>
> AKS · APR · Ballie–PSW · ECPP · Fermat · Lucas · Lucas–Lehmer ·
> Lucas–Lehmer–Riesel · Proth's theorem · Pépin's · Solovay–Strassen · Miller–Rabin · Trial division
>
> Sieve of Atkin · Sieve of Eratosthenes · Sieve of Sundaram · Wheel factorization
>
> CFRAC · Dixon's · ECM · Euler's · Pollard's rho · P − 1 · P + 1 · QS · GNFS · SNFS · rational sieve · Fermat's · Shanks' square forms · Trial division · Shor's
>
> Ancient Egyptian multiplication · Aryabhata · Binary GCD · Chakravala · Euclidean · Extended Euclidean · integer relation algorithm · integer square root · Modular exponentiation · Schoof's · Shanks-Tonelli
>
>
>
> Looks like you've got utf8 and iso8859-1 messed up.
>
> Phil
>
>
>
>
>
>


jeffpeng at mindspring

Sep 16, 2009, 9:31 PM

Post #15 of 34 (2648 views)
Permalink
Re: Why people not using mod_perl [In reply to]
from what you all stated, does it mean mod_perl is really outmoded comparing to Java?
Here Java programmer is cheaper than mod_perl developer.
But if mp can get better performance, we may consider it as first choice.

Regards,
Jeff.


jeff_nokes at yahoo

Sep 16, 2009, 10:54 PM

Post #16 of 34 (2647 views)
Permalink
Re: Why people not using mod_perl [In reply to]
Well, actually Igor, we ended up writing eBay::API. We needed something that was able to extend many more web services that are internal-use only, that the public doesn't have access to. The fact that eBay web service data-types are probably the most complex out there, and they change often, we had to come up with a way to easily incorporate those changes by slurping up a giant WSDL, and auto-generating all the classes and data types, etc.

But we do thank you for writing that. I knew of many API clients at the time that absolutely loved Net::eBay! In fact, I think at the time, the #2 API client (in listings) was perl-based, and using it.

Cheers,
- Jeff



________________________________
From: Igor Chudov <ichudov [at] gmail>
To: Jeff Nokes <jeff_nokes [at] yahoo>
Cc: Brad Van Sickle <bvs7085 [at] gmail>; mod_perl list <modperl [at] perl>
Sent: Wednesday, September 16, 2009 8:26:53 PM
Subject: Re: Why people not using mod_perl

You must have use my module Net::eBay, at some point, right?

I wrote Net::eBay about 3 years ago.

Igor


On Wed, Sep 16, 2009 at 9:47 PM, Jeff Nokes <jeff_nokes [at] yahoo> wrote:

Doesn't Amazon run mod_perl/Mason?
>
>BTW, I agree with most of your points (would debate #4,5). I may substitute the phrase "More convenient" for "Easier" in #3. I would also add ...
>
> #7) How many engineers are available to hire that know or want to work with said technology?
>
>I built a great platform at eBay on mod_perl/Mason that handled eBay-size traffic; we ran 6 eBay sites on it. Now it is used for specialty e-commerce solutions like worldofgood.ebay.com, global.ebay.com (cross-border trade), dealfinder.ebay.com, etc. In fact, on the same hardware, the main eBay Java app would support ~6 threads per box; the mod_perl platform supported ~60 (prefork), significant CapEx and power savings (which adds up at a place like
> eBay).
>
>
>
>
>
>
________________________________
From: Brad Van Sickle <bvs7085 [at] gmail>
>To: mod_perl list <modperl [at] perl>
>Sent: Wednesday, September 16, 2009 3:31:30 PM
>Subject: Re: Why people not using mod_perl
>
>
>
>
>>This is a mod_perl list, so I would expect to see Perl championed
>pretty heavily, but Java, .net and there ilk are undoubtedly *the*
>choice for large web applications. I'd like to get into some
>discussion as to why almost all *large* sites choose these languages.
>
>>I don't have any experience developing a large application in Java,
>although I do have a lot of experience working on the operations side
>of a large web application that is Java based.
>
>>The reasons I generally hear for choosing Java over mod_perl are:
>
>>1) Speed - I don't buy this at all
>>2) Maintainability - I think this makes sense. Perl can be pretty easy
>to maintain if you stick a good framework around it, but you have to
>seek out that framework and YOU are responsible for adhereing to it.
>All of that is inherent in Java. It also helps that Java has OO built
>in.
>>3) Easier to package and build/move code - In my experience this is
>true.
>>4) Advantages to be gained from running on an actually application
>server - Also valid
>>5) Compatible enterprise class middleware - Also true, Java plugs into
>more truly enterprise level suff than Perl does. (security frameworks,
>etc... )
>>6) Support
>
>>A lot of the industry seems look at Perl as obsolete technology that
>has been replaced by *insert hot new technology of the week here*
>which is a total shame. I've worked with a lot of technologies and I
>think Perl is a great choice for small/medium websites and webapps,
>which is probably what most of us work on. But I'm very interested to
>know at what point (if any) a site/app grows too large or too complex
>for mod_perl and what defines that turning point. Could Amazon run on
>mod_perl for example?
>
>
>>
>>
>>
>>>>Phil Carmody wrote:
>>
>>--- On Thu, 9/17/09, Igor Chudov <ichudov [at] gmail> wrote:
>>>
>>>My site algebra.com is about 80,000
>>>>lines of mod_perl code.
>>>>
>>>>I wrote a relatively large framework, with many homegrown
>>>>perl modules, about five years ago.
>>>>
>>>>It uses a database, image generation modules, a big
>>>>mathematical engine that I wrote (that "shows
>>>>work", unlike popular third party packages), etc.
>>>>
>>>>
>>>>All pages of my site are dynamic and it is very image heavy
>>>>
>>>>due to math formulae.
>>>>
>>>>I can say two things:
>>>>
>>>>1) It is relatively fast, serving pages in 0.1 seconds or
>>>>so
>>>>
>>>>2) Despite the quantity of code, and its age, it is still
>>>>very maintainable and understandable (to me).
>>>>
>>>In that case, would you like to fix its mangled output?
>>>
>>>e.g. http://www.algebra.com/algebra/homework/divisibility/Prime_factorization_algorithm.wikipedia
>>>
>>>Â Â (Redirected from Prime factorization algorithm)
>>>
>>>faster than O((1+ε)b) for all positive ε
>>>
>>>an integer M with 1 ≤ M ≤ N
>>>
>>>Pollard's p − 1 algorithm
>>>
>>>Section 4.5.4: Factoring into Primes, pp. 379–417.
>>>
>>>Chapter 5: Exponential Factoring Algorithms, pp. 191–226. Chapter 6: Subexponential Factoring Algorithms, pp. 227–284. Section 7.4: Elliptic curve method, pp. 301–313.
>>>
>>>Eric W. Weisstein, “RSA-640 Factoredâ€
>>>
>>>v • d • e
>>>
>>>AKS · APR · Ballie–PSW · ECPP · Fermat · Lucas · Lucas–Lehmer ·
>>> Lucas–Lehmer–Riesel · Proth's theorem · Pépin's · Solovay–Strassen · Miller–Rabin · Trial division
>>>
>>>Sieve of Atkin · Sieve of Eratosthenes · Sieve of Sundaram · Wheel factorization
>>>
>>>
>>>CFRAC · Dixon's · ECM · Euler's · Pollard's rho · P − 1 · P + 1 · QS · GNFS · SNFS · rational sieve · Fermat's · Shanks' square forms · Trial division · Shor's
>>>
>>>Ancient Egyptian multiplication · Aryabhata · Binary GCD · Chakravala · Euclidean · Extended Euclidean · integer relation algorithm · integer square root · Modular exponentiation · Schoof's · Shanks-Tonelli
>>>
>>>
>>>
>>>Looks like you've got utf8 and iso8859-1 messed up.
>>>
>>>Phil
>>>
>>>
>>>
>>>
>>>
>>>


ichudov at gmail

Sep 17, 2009, 4:52 AM

Post #17 of 34 (2645 views)
Permalink
Re: Why people not using mod_perl [In reply to]
Interesting. I did not even know about that #2 guy.

What sort of hardware and OS are you running there?

Igor

On Thu, Sep 17, 2009 at 12:54 AM, Jeff Nokes <jeff_nokes [at] yahoo> wrote:

> Well, actually Igor, we ended up writing eBay::API. We needed something
> that was able to extend many more web services that are internal-use only,
> that the public doesn't have access to. The fact that eBay web service
> data-types are probably the most complex out there, and they change often,
> we had to come up with a way to easily incorporate those changes by slurping
> up a giant WSDL, and auto-generating all the classes and data types, etc.
>
> But we do thank you for writing that. I knew of many API clients at the
> time that absolutely loved Net::eBay! In fact, I think at the time, the #2
> API client (in listings) was perl-based, and using it.
>
> Cheers,
> - Jeff
>
> ------------------------------
> *From:* Igor Chudov <ichudov [at] gmail>
> *To:* Jeff Nokes <jeff_nokes [at] yahoo>
> *Cc:* Brad Van Sickle <bvs7085 [at] gmail>; mod_perl list <
> modperl [at] perl>
> *Sent:* Wednesday, September 16, 2009 8:26:53 PM
>
> *Subject:* Re: Why people not using mod_perl
>
> You must have use my module Net::eBay, at some point, right?
>
> I wrote Net::eBay about 3 years ago.
>
> Igor
>
> On Wed, Sep 16, 2009 at 9:47 PM, Jeff Nokes <jeff_nokes [at] yahoo> wrote:
>
>> Doesn't Amazon run mod_perl/Mason?
>>
>> BTW, I agree with most of your points (would debate #4,5). I may
>> substitute the phrase "More convenient" for "Easier" in #3. I would also
>> add ...
>>
>> #7) How many engineers are available to hire that know or want to work
>> with said technology?
>>
>> I built a great platform at eBay on mod_perl/Mason that handled eBay-size
>> traffic; we ran 6 eBay sites on it. Now it is used for specialty e-commerce
>> solutions like worldofgood.ebay.com, global.ebay.com (cross-border
>> trade), dealfinder.ebay.com, etc. In fact, on the same hardware, the
>> main eBay Java app would support ~6 threads per box; the mod_perl platform
>> supported ~60 (prefork), significant CapEx and power savings (which adds up
>> at a place like eBay).
>>
>>
>>
>> ------------------------------
>> *From:* Brad Van Sickle <bvs7085 [at] gmail>
>> *To:* mod_perl list <modperl [at] perl>
>> *Sent:* Wednesday, September 16, 2009 3:31:30 PM
>> *Subject:* Re: Why people not using mod_perl
>>
>>
>>
>> This is a mod_perl list, so I would expect to see Perl championed pretty
>> heavily, but Java, .net and there ilk are undoubtedly *the* choice for large
>> web applications. I'd like to get into some discussion as to why almost all
>> *large* sites choose these languages.
>>
>> I don't have any experience developing a large application in Java,
>> although I do have a lot of experience working on the operations side of a
>> large web application that is Java based.
>>
>> The reasons I generally hear for choosing Java over mod_perl are:
>>
>> 1) Speed - I don't buy this at all
>> 2) Maintainability - I think this makes sense. Perl can be pretty easy to
>> maintain if you stick a good framework around it, but you have to seek out
>> that framework and YOU are responsible for adhereing to it. All of that is
>> inherent in Java. It also helps that Java has OO built in.
>> 3) Easier to package and build/move code - In my experience this is true.
>> 4) Advantages to be gained from running on an actually application server
>> - Also valid
>> 5) Compatible enterprise class middleware - Also true, Java plugs into
>> more truly enterprise level suff than Perl does. (security frameworks,
>> etc... )
>> 6) Support
>>
>> A lot of the industry seems look at Perl as obsolete technology that has
>> been replaced by *insert hot new technology of the week here* which is a
>> total shame. I've worked with a lot of technologies and I think Perl is a
>> great choice for small/medium websites and webapps, which is probably what
>> most of us work on. But I'm very interested to know at what point (if any)
>> a site/app grows too large or too complex for mod_perl and what defines that
>> turning point. Could Amazon run on mod_perl for example?
>>
>>
>>
>>
>>
>> Phil Carmody wrote:
>>
>> --- On Thu, 9/17/09, Igor Chudov <ichudov [at] gmail> <ichudov [at] gmail> wrote:
>>
>> My site algebra.com is about 80,000
>> lines of mod_perl code.
>>
>> I wrote a relatively large framework, with many homegrown
>> perl modules, about five years ago.
>>
>> It uses a database, image generation modules, a big
>> mathematical engine that I wrote (that "shows
>> work", unlike popular third party packages), etc.
>>
>>
>> All pages of my site are dynamic and it is very image heavy
>>
>> due to math formulae.
>>
>> I can say two things:
>>
>> 1) It is relatively fast, serving pages in 0.1 seconds or
>> so
>>
>> 2) Despite the quantity of code, and its age, it is still
>> very maintainable and understandable (to me).
>>
>> In that case, would you like to fix its mangled output?
>>
>> e.g. http://www.algebra.com/algebra/homework/divisibility/Prime_factorization_algorithm.wikipedia
>>
>> Â Â (Redirected from Prime factorization algorithm)
>>
>> faster than O((1+ε)b) for all positive ε
>>
>> an integer M with 1 ≤ M ≤ N
>>
>> Pollard's p − 1 algorithm
>>
>> Section 4.5.4: Factoring into Primes, pp. 379–417.
>>
>> Chapter 5: Exponential Factoring Algorithms, pp. 191–226. Chapter 6: Subexponential Factoring Algorithms, pp. 227–284. Section 7.4: Elliptic curve method, pp. 301–313.
>>
>> Eric W. Weisstein, “RSA-640 Factoredâ€
>>
>> v • d • e
>>
>> AKS · APR · Ballie–PSW · ECPP · Fermat · Lucas · Lucas–Lehmer ·
>> Lucas–Lehmer–Riesel · Proth's theorem · Pépin's · Solovay–Strassen · Miller–Rabin · Trial division
>>
>> Sieve of Atkin · Sieve of Eratosthenes · Sieve of Sundaram · Wheel factorization
>>
>>
>> CFRAC · Dixon's · ECM · Euler's · Pollard's rho · P − 1 · P + 1 · QS · GNFS · SNFS · rational sieve · Fermat's · Shanks' square forms · Trial division · Shor's
>>
>> Ancient Egyptian multiplication · Aryabhata · Binary GCD · Chakravala · Euclidean · Extended Euclidean · integer relation algorithm · integer square root · Modular exponentiation · Schoof's · Shanks-Tonelli
>>
>>
>>
>> Looks like you've got utf8 and iso8859-1 messed up.
>>
>> Phil
>>
>>
>>
>>
>>
>>
>


jeff_nokes at yahoo

Sep 17, 2009, 10:37 AM

Post #18 of 34 (2641 views)
Permalink
Re: Why people not using mod_perl [In reply to]
I left eBay a little over a year ago. When I was there, we were running on 32-bit, dual CPU HP blades, RHEL 4 for my platform. For the main Java platform, they were running 32-bit and 64-bit blades, on a flavor of Windows server.





________________________________
From: Igor Chudov <ichudov [at] gmail>
To: Jeff Nokes <jeff_nokes [at] yahoo>
Cc: mod_perl list <modperl [at] perl>
Sent: Thursday, September 17, 2009 4:52:38 AM
Subject: Re: Why people not using mod_perl

Interesting. I did not even know about that #2 guy.

What sort of hardware and OS are you running there?

Igor


On Thu, Sep 17, 2009 at 12:54 AM, Jeff Nokes <jeff_nokes [at] yahoo> wrote:

>Well, actually Igor, we ended up writing eBay::API. We needed something that was able to extend many more web services that are internal-use only, that the public doesn't have access to. The fact that eBay web service data-types are probably the most complex out there, and they change often, we had to come up with a way to easily incorporate those changes by slurping up a giant WSDL, and auto-generating all the classes and data types, etc.
>
>But we do thank you for writing that. I knew of many API clients at the time that absolutely loved Net::eBay! In fact, I think at the time, the #2 API client (in listings) was perl-based, and using it.
>
>Cheers,
>- Jeff
>
>
>
>
________________________________
From: Igor Chudov <ichudov [at] gmail>
>To: Jeff Nokes <jeff_nokes [at] yahoo>
>Cc: Brad Van Sickle <bvs7085 [at] gmail>; mod_perl list <modperl [at] perl>
>Sent: Wednesday, September 16, 2009 8:26:53 PM
>
>Subject: Re: Why people not using mod_perl
>
>
>>You must have use my module Net::eBay, at some point, right?
>
>I wrote Net::eBay about 3 years ago.
>
>Igor
>
>
>On Wed, Sep 16, 2009 at 9:47 PM, Jeff Nokes <jeff_nokes [at] yahoo> wrote:
>
>Doesn't Amazon run mod_perl/Mason?
>>
>>BTW, I agree with most of your points (would debate #4,5). I may substitute the phrase "More convenient" for "Easier" in #3. I would also add ...
>>
>> #7) How many engineers are available to hire that know or want to work with said technology?
>>
>>I built a great platform at eBay on mod_perl/Mason that handled eBay-size traffic; we ran 6 eBay sites on it. Now it is used for specialty e-commerce solutions like worldofgood.ebay.com, global.ebay.com (cross-border trade), dealfinder.ebay.com, etc. In fact, on the same hardware, the main eBay Java app would support ~6 threads per box; the mod_perl platform supported ~60 (prefork), significant CapEx and power savings (which adds up at a place like
>> eBay).
>>
>>
>>
>>
>>
>>
________________________________
>>From: Brad Van Sickle <bvs7085 [at] gmail>
>>To: mod_perl list <modperl [at] perl>
>>Sent: Wednesday, September 16, 2009 3:31:30 PM
>>Subject: Re: Why people not using mod_perl
>>
>>
>>
>>
>>>>This is a mod_perl list, so I would expect to see Perl championed
>>pretty heavily, but Java, .net and there ilk are undoubtedly *the*
>>choice for large web applications. I'd like to get into some
>>discussion as to why almost all *large* sites choose these languages.
>>
>>>>I don't have any experience developing a large application in Java,
>>although I do have a lot of experience working on the operations side
>>of a large web application that is Java based.
>>
>>>>The reasons I generally hear for choosing Java over mod_perl are:
>>
>>>>1) Speed - I don't buy this at all
>>>>2) Maintainability - I think this makes sense. Perl can be pretty easy
>>to maintain if you stick a good framework around it, but you have to
>>seek out that framework and YOU are responsible for adhereing to it.
>>All of that is inherent in Java. It also helps that Java has OO built
>>in.
>>>>3) Easier to package and build/move code - In my experience this is
>>true.
>>>>4) Advantages to be gained from running on an actually application
>>server - Also valid
>>>>5) Compatible enterprise class middleware - Also true, Java plugs into
>>more truly enterprise level suff than Perl does. (security frameworks,
>>etc... )
>>>>6) Support
>>
>>>>A lot of the industry seems look at Perl as obsolete technology that
>>has been replaced by *insert hot new technology of the week here*
>>which is a total shame. I've worked with a lot of technologies and I
>>think Perl is a great choice for small/medium websites and webapps,
>>which is probably what most of us work on. But I'm very interested to
>>know at what point (if any) a site/app grows too large or too complex
>>for mod_perl and what defines that turning point. Could Amazon run on
>>mod_perl for example?
>>
>>
>>>
>>>
>>>
>>>>>>Phil Carmody wrote:
>>>
>>>--- On Thu, 9/17/09, Igor Chudov <ichudov [at] gmail> wrote:
>>>>
>>>>My site algebra.com is about 80,000
>>>>>lines of mod_perl code.
>>>>>
>>>>>I wrote a relatively large framework, with many homegrown
>>>>>perl modules, about five years ago.
>>>>>
>>>>>
>>>>>It uses a database, image generation modules, a big
>>>>>mathematical engine that I wrote (that "shows
>>>>>work", unlike popular third party packages), etc.
>>>>>
>>>>>
>>>>>All pages of my site are dynamic and it is very image heavy
>>>>>
>>>>>
>>>>>due to math formulae.
>>>>>
>>>>>I can say two things:
>>>>>
>>>>>1) It is relatively fast, serving pages in 0.1 seconds or
>>>>>so
>>>>>
>>>>>2) Despite the quantity of code, and its age, it is still
>>>>>very maintainable and understandable (to me).
>>>>>
>>>>In that case, would you like to fix its mangled output?
>>>>
>>>>e.g. http://www.algebra.com/algebra/homework/divisibility/Prime_factorization_algorithm.wikipedia
>>>>
>>>>Â Â (Redirected from Prime factorization algorithm)
>>>>
>>>>faster than O((1+ε)b) for all positive ε
>>>>
>>>>an integer M with 1 ≤ M ≤ N
>>>>
>>>>Pollard's p − 1 algorithm
>>>>
>>>>Section 4.5.4: Factoring into Primes, pp. 379–417.
>>>>
>>>>Chapter 5: Exponential Factoring Algorithms, pp. 191–226. Chapter 6: Subexponential Factoring Algorithms, pp. 227–284. Section 7.4: Elliptic curve method, pp. 301–313.
>>>>
>>>>Eric W. Weisstein, “RSA-640 Factoredâ€
>>>>
>>>>v • d • e
>>>>
>>>>AKS · APR · Ballie–PSW · ECPP · Fermat · Lucas · Lucas–Lehmer ·
>>>> Lucas–Lehmer–Riesel · Proth's theorem · Pépin's · Solovay–Strassen · Miller–Rabin · Trial division
>>>>
>>>>Sieve of Atkin · Sieve of Eratosthenes · Sieve of Sundaram · Wheel factorization
>>>>
>>>>
>>>>CFRAC · Dixon's · ECM · Euler's · Pollard's rho · P − 1 · P + 1 · QS · GNFS · SNFS · rational sieve · Fermat's · Shanks' square forms · Trial division · Shor's
>>>>
>>>>Ancient Egyptian multiplication · Aryabhata · Binary GCD · Chakravala · Euclidean · Extended Euclidean · integer relation algorithm · integer square root · Modular exponentiation · Schoof's · Shanks-Tonelli
>>>>
>>>>
>>>>
>>>>Looks like you've got utf8 and iso8859-1 messed up.
>>>>
>>>>Phil
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>


dihnen at amazon

Sep 17, 2009, 11:14 AM

Post #19 of 34 (2644 views)
Permalink
RE: Why people not using mod_perl [In reply to]
Rather than develop and contribute the community the ideas used in integrating (IDE-app server-version store-job management) for the perl environment… you stop using perl for that.

This is *exactly* why people are not using mod_perl – perl lacks the investment given to these big projects that people ARE investing in with the java technology.

There is nothing magical about java applied to this integration – perl could it it as well (or better, given lessons learned from the earlier take).

Sorry if I sound a bit bitter, but this lack of investment in my favored technology frustrates me something fierce. You and your business/company may have the clout after 10 years of building large critical systems to have the resources to invest in actually DOING this, and you would rather move to java.

(not that it’s the only reason to move to java, but it sounds like it’s the fallover difference)

Sigh.

David


From: Steven Siebert [mailto:smsiebe [at] gmail]
Sent: Wednesday, September 16, 2009 8:15 PM
To: Jeff Nokes
Cc: Brad Van Sickle; mod_perl list
Subject: Re: Why people not using mod_perl

I would also add, in addition to the frameworks, the availability of tools such as Netbeans and Eclipse IDE's are unmatched in the perl domain. These IDE's provide many high-level conveniences for enterprise developers, most notably in the realm of SOA (such as graphical building of BPEL and CEP).

After nearly 10 years building and maintaining a critical government system, we are sadly migrating away from mod_perl to a J2EE based solution due to the success and growth of our mod_perl-based system. mod_perl and MySQL has served as well when we were taking on medium-to-large loads...however, as we are growing to a distributed (multi-site, multi-node) system, with tie-ins to numerous internal and external business systems across the enterprise, with development partners working at distributed factories...tools such as Netbeans and it's tight integration with Glassfish, SVN, and Hudson make building at this level a lot more manageable. I found that mod_perl for large-scale web applications works great, and if necessary horizontal scaling is achievable to sustain even more load. However, when dealing with complex SOA architectures, and the management of business workflows...the framework support and tools to accomplish this just aren't there in perl.

Add to this Jeff's comment on the availability of high caliber perl engineers...we are almost forced to make this decision.

We will continue to use mod_perl for other uses, such as our custom SCM/ALM system we built over the years...but the main product is migrating.

On Wed, Sep 16, 2009 at 10:47 PM, Jeff Nokes <jeff_nokes [at] yahoo<mailto:jeff_nokes [at] yahoo>> wrote:
Doesn't Amazon run mod_perl/Mason?

BTW, I agree with most of your points (would debate #4,5). I may substitute the phrase "More convenient" for "Easier" in #3. I would also add ...

#7) How many engineers are available to hire that know or want to work with said technology?

I built a great platform at eBay on mod_perl/Mason that handled eBay-size traffic; we ran 6 eBay sites on it. Now it is used for specialty e-commerce solutions like worldofgood.ebay.com<http://worldofgood.ebay.com>, global.ebay.com<http://global.ebay.com> (cross-border trade), dealfinder.ebay.com<http://dealfinder.ebay.com>, etc. In fact, on the same hardware, the main eBay Java app would support ~6 threads per box; the mod_perl platform supported ~60 (prefork), significant CapEx and power savings (which adds up at a place like eBay).


________________________________
From: Brad Van Sickle <bvs7085 [at] gmail<mailto:bvs7085 [at] gmail>>
To: mod_perl list <modperl [at] perl<mailto:modperl [at] perl>>
Sent: Wednesday, September 16, 2009 3:31:30 PM
Subject: Re: Why people not using mod_perl



This is a mod_perl list, so I would expect to see Perl championed pretty heavily, but Java, .net and there ilk are undoubtedly *the* choice for large web applications. I'd like to get into some discussion as to why almost all *large* sites choose these languages.

I don't have any experience developing a large application in Java, although I do have a lot of experience working on the operations side of a large web application that is Java based.

The reasons I generally hear for choosing Java over mod_perl are:

1) Speed - I don't buy this at all
2) Maintainability - I think this makes sense. Perl can be pretty easy to maintain if you stick a good framework around it, but you have to seek out that framework and YOU are responsible for adhereing to it. All of that is inherent in Java. It also helps that Java has OO built in.
3) Easier to package and build/move code - In my experience this is true.
4) Advantages to be gained from running on an actually application server - Also valid
5) Compatible enterprise class middleware - Also true, Java plugs into more truly enterprise level suff than Perl does. (security frameworks, etc... )
6) Support

A lot of the industry seems look at Perl as obsolete technology that has been replaced by *insert hot new technology of the week here* which is a total shame. I've worked with a lot of technologies and I think Perl is a great choice for small/medium websites and webapps, which is probably what most of us work on. But I'm very interested to know at what point (if any) a site/app grows too large or too complex for mod_perl and what defines that turning point. Could Amazon run on mod_perl for example?





Phil Carmody wrote:

--- On Thu, 9/17/09, Igor Chudov <ichudov [at] gmail><mailto:ichudov [at] gmail> wrote:



My site algebra.com<http://algebra.com> is about 80,000

lines of mod_perl code.



I wrote a relatively large framework, with many homegrown

perl modules, about five years ago.







It uses a database, image generation modules, a big

mathematical engine that I wrote (that "shows

work", unlike popular third party packages), etc.





All pages of my site are dynamic and it is very image heavy







due to math formulae.



I can say two things:



1) It is relatively fast, serving pages in 0.1 seconds or

so



2) Despite the quantity of code, and its age, it is still

very maintainable and understandable (to me).









In that case, would you like to fix its mangled output?



e.g. http://www.algebra.com/algebra/homework/divisibility/Prime_factorization_algorithm.wikipedia








  (Redirected from Prime factorization algorithm)



faster than O((1+ε)b) for all positive ε



an integer M with 1 ≤ M ≤ N



Pollard's p − 1 algorithm



Section 4.5.4: Factoring into Primes, pp. 379–417.








Chapter 5: Exponential Factoring Algorithms, pp. 191–226. Chapter 6: Subexponential Factoring Algorithms, pp. 227–284. Section 7.4: Elliptic curve method, pp. 301–313.



Eric W. Weisstein, “RSA-640 Factoredâ€








v • d • e



AKS · APR · Ballie–PSW · ECPP · Fermat · Lucas · Lucas–Lehmer ·

Lucas–Lehmer–Riesel · Proth's theorem · Pépin's · Solovay–Strassen · Miller–Rabin · Trial division



Sieve of Atkin · Sieve of Eratosthenes · Sieve of Sundaram · Wheel factorization









CFRAC · Dixon's · ECM · Euler's · Pollard's rho · P − 1 · P + 1 · QS · GNFS · SNFS · rational sieve · Fermat's · Shanks' square forms · Trial division · Shor's



Ancient Egyptian multiplication · Aryabhata · Binary GCD · Chakravala · Euclidean · Extended Euclidean · integer relation algorithm · integer square root · Modular exponentiation · Schoof's · Shanks-Tonelli












Looks like you've got utf8 and iso8859-1 messed up.



Phil


ichudov at gmail

Sep 17, 2009, 11:26 AM

Post #20 of 34 (2644 views)
Permalink
Re: Why people not using mod_perl [In reply to]
On Thu, Sep 17, 2009 at 1:14 PM, Ihnen, David <dihnen [at] amazon> wrote:

> Rather than develop and contribute the community the ideas used in
> integrating (IDE-app server-version store-job management) for the perl
> environment you stop using perl for that.
>
> This is **exactly** why people are not using mod_perl perl lacks the
> investment given to these big projects that people ARE investing in with the
> java technology.
>
People are using mod_perl, just not as much as some of us would like.

I am now satisfied that mod_perl is a very viable system with devoted
following.

i


boysenberry at habitatlife

Sep 17, 2009, 11:27 AM

Post #21 of 34 (2644 views)
Permalink
Re: Why people not using mod_perl [In reply to]
I wonder if this will still be the case with Parrot and Perl 6?
I've read up on it a bit and with being able to compile multiple
languages exposing their libraries to each other it would seem more
programmers might be tempted into using Perl because of it's massive
library base.
What are the plans for mod_perl with perl 6?

Thanks,
Boysenberry Payne

On Sep 16, 2009, at 9:31 PM, Jeff Peng wrote:

> from what you all stated, does it mean mod_perl is really outmoded
> comparing to Java?
> Here Java programmer is cheaper than mod_perl developer.
> But if mp can get better performance, we may consider it as first
> choice.
>
> Regards,
> Jeff.


adam.prime at utoronto

Sep 17, 2009, 11:31 AM

Post #22 of 34 (2642 views)
Permalink
Re: Why people not using mod_perl [In reply to]
Jeff Horwitz is working on mod_parrot and mod_perl6

mod_parrot info:
http://www.parrot.org/mod_parrot

Jeffs blog:
http://www.smashing.org/jeff/

It's coming along, but currently it's tough to actually do much that's
useful without things like DBI, or Apache::Request. at least that's
where it was at YAPC.

Adam


Boysenberry Payne wrote:
> I wonder if this will still be the case with Parrot and Perl 6?
> I've read up on it a bit and with being able to compile multiple
> languages exposing their libraries to each other it would seem more
> programmers might be tempted into using Perl because of it's massive
> library base.
> What are the plans for mod_perl with perl 6?
>
> Thanks,
> Boysenberry Payne
>
> On Sep 16, 2009, at 9:31 PM, Jeff Peng wrote:
>
>> from what you all stated, does it mean mod_perl is really outmoded
>> comparing to Java?
>> Here Java programmer is cheaper than mod_perl developer.
>> But if mp can get better performance, we may consider it as first choice.
>>
>> Regards,
>> Jeff.
>


fred at redhotpenguin

Sep 17, 2009, 11:47 AM

Post #23 of 34 (2649 views)
Permalink
Re: Why people not using mod_perl [In reply to]
On Wed, Sep 16, 2009 at 8:15 PM, Steven Siebert <smsiebe [at] gmail> wrote:
> I would also add, in addition to the frameworks, the availability of tools
> such as Netbeans and Eclipse IDE's are unmatched in the perl domain.  These
> IDE's provide many high-level conveniences for enterprise developers, most
> notably in the realm of SOA (such as graphical building of BPEL and CEP).

Emacs, Vim, Komodo, and others are equally as capable in the Perl
domain. What you don't have as much of in the Perl domain is the
commercial support for those tools, with the exception of ActiveState.
I just pulled down the latest copy of Komodo and took it for a spin;
though however many times I try out the GUI based editors I end up
going back to cli based tools because they are so much more performant
when you've been using them a while and have customized them for your
particular needs.

I don't doubt there is more support for service oriented architectures
with Java based IDEs, as Java tends to be a preferable language for
medium and large sized development teams which are easier for larger
entities to support. Factors such as productivity per individual
developer are less important with a large team.

> After nearly 10 years building and maintaining a critical government system,
> we are sadly migrating away from mod_perl to a J2EE based solution due to
> the success and growth of our mod_perl-based system.  mod_perl and MySQL has
> served as well when we were taking on medium-to-large loads...however, as we

I think this is a natural progression of successful applications. The
development needs of a large established system are different than
those of a fast growing application. Large systems tend to have more
management levels involved, and development speed and scalability are
no longer bottlenecks - external systems and compliance tend to be
higher priority, and that takes less code writing and more
coordination between stakeholders.

> Add to this Jeff's comment on the availability of high caliber perl
> engineers...we are almost forced to make this decision.

Maybe you aren't looking in the right places:

http://jobs.perl.org
YAPC::*
This email list
The Perl Mongers groups

Dice, Craigslist, Monster, etc. are great places to find Java
programmers but bad places to find Perl programmers. In Silicon
Valley, you can usually shake a tree and a couple of Java programmers
will fall out.. ;)


>
> We will continue to use mod_perl for other uses, such as our custom SCM/ALM
> system we built over the years...but the main product is migrating.
>
>
> On Wed, Sep 16, 2009 at 10:47 PM, Jeff Nokes <jeff_nokes [at] yahoo> wrote:
>>
>> Doesn't Amazon run mod_perl/Mason?
>>
>> BTW, I agree with most of your points (would debate #4,5).  I may
>> substitute the phrase "More convenient" for "Easier" in #3.  I would also
>> add ...
>>
>>    #7)  How many engineers are available to hire that know or want to work
>> with said technology?
>>
>> I built a great platform at eBay on mod_perl/Mason that handled eBay-size
>> traffic; we ran 6 eBay sites on it.  Now it is used for specialty e-commerce
>> solutions like worldofgood.ebay.com, global.ebay.com (cross-border trade),
>> dealfinder.ebay.com, etc.  In fact, on the same hardware, the main eBay Java
>> app would support ~6 threads per box; the mod_perl platform supported ~60
>> (prefork), significant CapEx and power savings (which adds up at a place
>> like eBay).
>>
>>
>>
>> ________________________________
>> From: Brad Van Sickle <bvs7085 [at] gmail>
>> To: mod_perl list <modperl [at] perl>
>> Sent: Wednesday, September 16, 2009 3:31:30 PM
>> Subject: Re: Why people not using mod_perl
>>
>>
>>
>> This is a mod_perl list, so I would expect to see Perl championed pretty
>> heavily, but Java, .net and there ilk are undoubtedly *the* choice for large
>> web applications.  I'd like to get into some discussion as to why almost all
>> *large* sites choose these languages.
>>
>> I don't have any experience developing a large application in Java,
>> although I do have a lot of experience working on the operations side of a
>> large web application that is Java based.
>>
>> The reasons I generally hear for choosing Java over mod_perl are:
>>
>> 1) Speed - I don't buy this at all
>> 2) Maintainability - I think this makes sense.  Perl can be pretty easy to
>> maintain if you stick a good framework around it, but you have to seek out
>> that framework and YOU are responsible for adhereing to it.  All of that is
>> inherent in Java.  It also helps that Java has OO built in.
>> 3) Easier to package and build/move code - In my experience this is true.
>> 4) Advantages to be gained from running on an actually application server
>> - Also valid
>> 5) Compatible enterprise class middleware - Also true, Java plugs into
>> more truly enterprise level suff than Perl does. (security frameworks,
>> etc... )
>> 6) Support
>>
>> A lot of the industry seems look at Perl as obsolete technology that has
>> been replaced by *insert hot new technology of the week here*  which is a
>> total shame.  I've worked with a lot of technologies and I think Perl is a
>> great choice for small/medium websites and webapps, which is probably what
>> most of us work on.  But I'm very interested to know at what point (if any)
>> a site/app grows too large or too complex for mod_perl and what defines that
>> turning point.   Could Amazon run on mod_perl for example?
>>
>>
>>
>>
>> Phil Carmody wrote:
>>
>> --- On Thu, 9/17/09, Igor Chudov <ichudov [at] gmail> wrote:
>>
>>
>> My site algebra.com is about 80,000
>> lines of mod_perl code.
>>
>> I wrote a relatively large framework, with many homegrown
>> perl modules, about five years ago.
>>
>>
>> It uses a database, image generation modules, a big
>> mathematical engine that I wrote (that "shows
>> work", unlike popular third party packages), etc.
>>
>>
>> All pages of my site are dynamic and it is very image heavy
>>
>>
>> due to math formulae.
>>
>> I can say two things:
>>
>> 1) It is relatively fast, serving pages in 0.1 seconds or
>> so
>>
>> 2) Despite the quantity of code, and its age, it is still
>> very maintainable and understandable (to me).
>>
>>
>>
>>
>> In that case, would you like to fix its mangled output?
>>
>> e.g.
>> http://www.algebra.com/algebra/homework/divisibility/Prime_factorization_algorithm.wikipedia
>>
>>
>>
>> Â Â (Redirected from Prime factorization algorithm)
>>
>> faster than O((1+ε)b) for all positive ε
>>
>> an integer M with 1 ≤ M ≤ N
>>
>> Pollard's p − 1 algorithm
>>
>> Section 4.5.4: Factoring into Primes, pp. 379–417.
>>
>>
>>
>> Chapter 5: Exponential Factoring Algorithms, pp. 191–226. Chapter 6:
>> Subexponential Factoring Algorithms, pp. 227–284. Section 7.4: Elliptic
>> curve method, pp. 301–313.
>>
>> Eric W. Weisstein, “RSA-640 Factoredâ€
>>
>>
>>
>> v • d • e
>>
>> AKS · APR · Ballie–PSW · ECPP · Fermat · Lucas · Lucas–Lehmer ·
>> Lucas–Lehmer–Riesel · Proth's theorem · Pépin's ·
>> Solovay–Strassen · Miller–Rabin · Trial division
>>
>> Sieve of Atkin · Sieve of Eratosthenes · Sieve of Sundaram · Wheel
>> factorization
>>
>>
>>
>> CFRAC · Dixon's · ECM · Euler's · Pollard's rho · P − 1 · P + 1 ·
>> QS · GNFS · SNFS · rational sieve · Fermat's · Shanks' square forms ·
>> Trial division · Shor's
>>
>> Ancient Egyptian multiplication · Aryabhata · Binary GCD · Chakravala
>> · Euclidean · Extended Euclidean · integer relation algorithm · integer
>> square root · Modular exponentiation · Schoof's · Shanks-Tonelli
>>
>>
>>
>>
>>
>> Looks like you've got utf8 and iso8859-1 messed up.
>>
>> Phil
>>
>>
>>
>>
>>
>>
>


ichudov at gmail

Sep 17, 2009, 12:22 PM

Post #24 of 34 (2643 views)
Permalink
Re: Why people not using mod_perl [In reply to]
Just to add a little bit.

In my experience, perl programming requires a certain type of mind. I cannot
define it very precisely, but not everyone can "think in perl". Those who
can, basically, have a huge advantage over those who cannot, but that
naturally limits perl adoption somewhat. I think that more people can think
in java than in perl.

I would hope that as long as use of perl is substantial, it will remain a
viable platform that I can enjoy and use to live and make money. I do not
care if perl is "very popular", or just "popular", I will be happy as long
as it is "viable".

Igor


mkirank1 at gmail

Sep 17, 2009, 12:32 PM

Post #25 of 34 (2646 views)
Permalink
Re: Why people not using mod_perl [In reply to]
>
> Emacs, Vim, Komodo, and others are equally as capable in the Perl
> domain. What you don't have as much of in the Perl domain is the
> commercial support for those tools, with the exception of ActiveState.
> I just pulled down the latest copy of Komodo and took it for a spin;
> though however many times I try out the GUI based editors I end up
> going back to cli based tools because they are so much more performant
> when you've been using them a while and have customized them for your
> particular needs.
>
There is also Padre (http://padre.perlide.org/) , You can write
plugins and customize to your needs, there are already lots of plugins
available http://search.cpan.org/search?query=padre%3A%3Aplugin&mode=all

First page Previous page 1 2 Next page Last page  View All ModPerl modperl RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.