Re: Why people not using mod_perl

[Jeff Peng]

Just was curious, is CGI running with perl6 most likely the same as Java with 
JVM?

Regards,
Jeff Peng

Re: Ways to scale a mod_perl site

[Jeff Peng]

-Original Message-
>From: Phil Van 
>Sent: Sep 18, 2009 4:10 AM
>To: Jeff Peng 
>Cc: modperl-list 
>Subject: Re: Ways to scale a mod_perl site
>
>Just curious: since you are already running FastCGI, why not serving
>dynamic contents directly via it? 

we needed some reverse proxies for CDN.
for example, our primary webservers were in ISP A, while in ISP B, we put some 
squid as reverse proxies to serve the users in local ISP.


>Also, you may eliminate Squid. Using
>Apache for static content is good enough (easy to get 5k static PV per
>second per server, or 400 millions per day).
>

No. I'm sure serving static content Apache is worse than squid.
when I was in another department, I maintained the systems for AD union (like 
google's AD).
all content are static, PV of each day was about 200 million.
but we had less than 20 squid (IIRC it was 18) boxes for handling this amount 
of requests.
the same amount of Apache couldn't handle that case.



Regards,
Jeff Peng

Re: Ways to scale a mod_perl site

[David Nicol]

On Thu, Sep 17, 2009 at 4:23 PM, Torsten Foertsch
 wrote:

> I'd go for Apache's mod_cache + mod_disk_cache. The only thing you have
> to do is to set cache control headers. Mod_cache is really fast b/c it
> skips almost all of the http request cycle. And in your case it takes
> load from the database. The request won't even hit mod_perl.
>
> Torsten

it seems like an equivalent way to do this possibly with less
configuration would be to generate the cacheables with file names
representing their input parameters and do the construction of the new
ones with a custom 404 handler. TMTOWTDI.



-- 
"As if you could kill time without injuring eternity!"  -- Henry David Thoreau

Re: Why people not using mod_perl

[Adam Prime]

Torsten Foertsch wrote:

On Thu 17 Sep 2009, Kiran Kumar wrote:

I have seen padre first time at the this year German perl workshop in 
February and tried it out a bit. What I miss is syntax highlighting and 
indentation for C, XS and Perl in one tool. Can padre handle this? Last 
time I looked it could not but that was half a year ago.


I am using Emacs for almost 20 years now but it lacks good XS support.


Padre has been advancing rapidly over the last 6 months or so.  I 
haven't actually used it, but the syntax highlighting for perl is 
supposed to be the best there is in any editor (since it uses PPI)


I don't know about XS or C support, but padre is pluggable, and they are 
always looking for more help.  #padre on irc.perl.org


Adam

Re: Why people not using mod_perl

[Steven Siebert]

> > 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.. ;)
>
> I agree with you for the typical environment...however, our project is not
government owned but comes with a current/updated security clearance
requirement - significantly reducing the available pool.  Our situation is
unique in that requirement but I it reduces the pool of eligible programmers
across all languages the same (although I have no research to back up this
claim).  So...if there are 1:1000 quality perl:java engineers our ratio
stays the same...but the pool is that much smaller.

Re: Ways to scale a mod_perl site

[Torsten Foertsch]

On Wed 16 Sep 2009, Igor Chudov wrote:
> >> I have very little static content. Even images are generated. My
> >> site generates images of math formulae such as (x-1)/(x+1) on the
> >> fly.,
> >
> > I can understand generating them on the fly for flexibility
> > reasons, but I'd cache them, and serve them statically after that,
> > rather than regenerate the images on every single request.  You can
> > accomplish that in the app itself, or just by throwing a caching
> > proxy in front of it (maybe you're already doing this with perlbal)
>
> I actually do cache generated pictures, I store them in a database
> table called 'bincache'. This way I do not have to compute and draw
> every image on the fly. If I have a picture in bincache, I serve it,
> and if I do not, I generate it and save it. That saves some CPU, but
> makes mysql work harder.

I'd go for Apache's mod_cache + mod_disk_cache. The only thing you have 
to do is to set cache control headers. Mod_cache is really fast b/c it 
skips almost all of the http request cycle. And in your case it takes 
load from the database. The request won't even hit mod_perl.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net

RE: Why people not using mod_perl

[Ihnen, David]

Perhaps it could in some portion be quantified as "The ability to think about a 
program without the ide/language structure suggesting paths for you".

The possibilities are infinite.  I can imagine that would be a problem for many.

David


From: Igor Chudov [mailto:ichu...@gmail.com]
Sent: Thursday, September 17, 2009 12:22 PM
Cc: mod_perl list
Subject: Re: Why people not using mod_perl

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

Re: Why people not using mod_perl

[Torsten Foertsch]

On Thu 17 Sep 2009, Kiran Kumar wrote:
> 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

I have seen padre first time at the this year German perl workshop in 
February and tried it out a bit. What I miss is syntax highlighting and 
indentation for C, XS and Perl in one tool. Can padre handle this? Last 
time I looked it could not but that was half a year ago.

I am using Emacs for almost 20 years now but it lacks good XS support.

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net

If anyone in Chicagoland is looking for a full time job

[Igor Chudov]

Someone I know very well, shall I say, is looking for a very strong Perl and
bash programmer.
Contact me off list if interested. This is a local full time job in downtown
Chicago.
The job involves a lot of perl and shell programming and good thinking
skills,
but is not directly mod_perl related. I apologize if this posting is off
topic.

Re: Ways to scale a mod_perl site

[Phil Van]

Just curious: since you are already running FastCGI, why not serving
dynamic contents directly via it? Also, you may eliminate Squid. Using
Apache for static content is good enough (easy to get 5k static PV per
second per server, or 400 millions per day).


Phil



On 9/17/09, Jeff Peng  wrote:
>
>
> -Original Message-
>>From: Cosimo Streppone 
>>Sent: Sep 17, 2009 3:43 AM
>>To: Mod_perl users 
>>Cc: Jeff Peng 
>>Subject: Re: Ways to scale a mod_perl site
>>
>>Jeff Peng  wrote:
>>
>>> How many servers?
>>> We have run the systems with about 500 million PV each day, with many
>>> squid boxes + 200 apache webservers + 200 mysql hosts.
>>> The applications were written with FastCGI.
>>
>>Wow! Why don't you tell or blog a bit about this?
>>I would love to know more about what challenges
>>you went through.
>>
>
>
> Yup, at that time the primary pressure against performance was database.
> We used distributed Mysql servers with an oracle index server.
> Each mysql host served 1 - 1.5 million users.
> When an user logined, the application queried oracle to get the mysql host
> id with the key of username.
> Then the application queried to mysql and got anything it wanted.
> The systems generated 2T data each day (surely we had large amount of
> store).
>
> The front apache servers with FastCGI were running heavily, I remember 8G
> memory were almost eated.
> Squid was useful for static resources, but for dynamic applications like
> CGI, no way to reduce the pressure but adding more machines.
>
> Last, the applications are webmail, the best popolar provider here.
>
>
> Regards,
> Jeff Peng
>

Re: Why people not using mod_perl

[Kiran Kumar]

>
> 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

Re: Why people not using mod_perl

[Igor Chudov]

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

Odd error from subprogram in 'required'

[Bruce Johnson]

I'm getting this error:

[Thu Sep 17 10:52:13 2009] [error] Undefined subroutine  
&ModPerl 
::ROOT 
::ModPerl 
::PerlRunPrefork::home_oraweb_perl_avi_login_2epl::PrintHeader called  
at /home/oraweb/perl/avi/login.pl line 43,  line 71.\n
[Thu Sep 17 10:52:13 2009] [error] [client 65.55.106.207] malformed  
header from script. Bad header=_OF_FUNC: login.pl
[Thu Sep 17 10:52:13 2009] [warn] /avi/login.pl did not send an HTTP  
header


The undefined subroutine IS defined; it's loaded via a line:

require "avi-defaults";

And the subroutine is just:

sub PrintHeader {
  return "Content-type: text/html\n\n";
}


The line as called in login.pl is just:

print &PrintHeader;

Now this subroutine is called *throughout* the application, as you  
might guess, every time we write a html page for display, the app is  
comprised of about 40-50 different scripts.


Heck, every CGI perl script on our server uses the same code, which is  
defined in the '-defaults' file for each application.


ONLY this one script is generating the error.

I've examined the file, there's no odd characters or anything in it.

--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

Re: Why people not using mod_perl

[Fred Moyer]

On Wed, Sep 16, 2009 at 8:15 PM, Steven Siebert  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  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 
>> To: mod_perl list 
>> 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

Re: Why people not using mod_perl

[Adam Prime]

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.

Re: Why people not using mod_perl

[Boysenberry Payne]

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.

Re: Why people not using mod_perl

[Igor Chudov]

On Thu, Sep 17, 2009 at 1:14 PM, Ihnen, David  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

RE: Why people not using mod_perl

[Ihnen, David]

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:smsi...@gmail.com]
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 
mailto:jeff_no...@yahoo.com>> 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 mailto:bvs7...@gmail.com>>
To: mod_perl list mailto:modperl@perl.apache.org>>
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

Re: Why people not using mod_perl

[Jeff Nokes]

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 
To: Jeff Nokes 
Cc: mod_perl list 
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  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 
>To: Jeff Nokes 
>Cc: Brad Van Sickle ; mod_perl list 
>
>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  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 
>>To: mod_perl list 
>>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  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 ca

Re: Why people not using mod_perl

[Igor Chudov]

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  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 
> *To:* Jeff Nokes 
> *Cc:* Brad Van Sickle ; mod_perl list <
> modperl@perl.apache.org>
> *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  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 
>> *To:* mod_perl list 
>> *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   
>> 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)
>>

Re: Ways to scale a mod_perl site

[James Smith]

Igor Chudov wrote:

Guys, I completely love this discussion about cookies. You have really
enlightened me.

I think that letting users store cookie info in a manner that is secure
(involves both encryption and some form of authentication), instead of
storing them in a table, could possibly result in a very substantial
reduction of database use.

  
Alternatively store the information in a two level cache! 
memcached/database - with
write through - then most of the time you get the data from memcached - 
you can do

the same with the images...

write entry: -> write data to memcached ; write data to sql cache

read entry: -> read data from memcached and return OR
  read data from sql cache and write to memcached 
and return


Should avoid most database reads! works well for the images you create 
to minimize

database accesses

The cookie is

1) Encrypted string that I want and
2) MD5 of that string with a secret code appended that the users do not
know, which serves as a form of signing

That should work. I will not change it now, but will do if I get 2x more
traffic.

That way I would need zero hits to the database to handle my users sessions.


(I only retrieve account information when necessary)

As far as I remember now, I do not store much more information in a session
beyond username. (I hope that I am not wrong). So it should be easy.

Even now, I make sure that I reset the cookie table only every several
months. This way I would let users stay logged on forever.

Thanks a lot.

Igor

  





--
The Wellcome Trust Sanger Institute is operated by Genome Research 
Limited, a charity registered in England with number 1021457 and a 
company registered in England with number 2742969, whose registered 
office is 215 Euston Road, London, NW1 2BE. 

Re: ModPerl::Registry and custom error documents

[Torsten Foertsch]

On Thu 17 Sep 2009, Andreas Mock wrote:
> How can we dynamically create own error documents without using
> the lower level mod_perl/apache api? Is there a simple way?
> How can we achieve that?

A very simple registry script:

#!/usr/bin/perl

use strict;

my $r=shift;

$r->status($r->args);
exit;

Then you can configure ErrorDocuments, e.g.

ErrorDocument 404 http://huhu.com
ErrorDocument 500 "dumm gloffe"

Now try it out:

A 404 will be translated into a redirect:

$ curl http://localhost/etest?404 -v
* About to connect() to localhost port 80 (#0)
*   Trying ::1... connected
* Connected to localhost (::1) port 80 (#0)
> GET /etest?404 HTTP/1.1
> User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0 
OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
> Host: localhost
> Accept: */*
>
< HTTP/1.1 302 Found
< Date: Thu, 17 Sep 2009 11:05:19 GMT
< Server: Apache/2.2.13 (Unix) proxy_html/3.0.1 mod_ssl/2.2.13 
OpenSSL/0.9.8h DAV/2 SVN/1.6.4 mod_apreq2-20090110/2.7.1 
mod_perl/2.0.5threading3 Perl/v5.10.0
< Location: http://huhu.com
< Content-Length: 199
< Content-Type: text/html; charset=iso-8859-1
<


302 Found

Found
The document has moved http://huhu.com";>here.

* Connection #0 to host localhost left intact
* Closing connection #0


a 403 sends the normal error page

$ curl http://localhost/etest?403 -v
* About to connect() to localhost port 80 (#0)
*   Trying ::1... connected
* Connected to localhost (::1) port 80 (#0)
> GET /etest?403 HTTP/1.1
> User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0 
OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
> Host: localhost
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< Date: Thu, 17 Sep 2009 11:05:58 GMT
< Server: Apache/2.2.13 (Unix) proxy_html/3.0.1 mod_ssl/2.2.13 
OpenSSL/0.9.8h DAV/2 SVN/1.6.4 mod_apreq2-20090110/2.7.1 
mod_perl/2.0.5threading3 Perl/v5.10.0
< Content-Length: 207
< Content-Type: text/html; charset=iso-8859-1
<


403 Forbidden

Forbidden
You don't have permission to access /etest
on this server.

* Connection #0 to host localhost left intact
* Closing connection #0

and a 500 delivers a custom error message:

$ curl http://localhost/etest?500 -v
* About to connect() to localhost port 80 (#0)
*   Trying ::1... connected
* Connected to localhost (::1) port 80 (#0)
> GET /etest?500 HTTP/1.1
> User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0 
OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10
> Host: localhost
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Date: Thu, 17 Sep 2009 11:09:19 GMT
< Server: Apache/2.2.13 (Unix) proxy_html/3.0.1 mod_ssl/2.2.13 
OpenSSL/0.9.8h DAV/2 SVN/1.6.4 mod_apreq2-20090110/2.7.1 
mod_perl/2.0.5threading3 Perl/v5.10.0
< Content-Length: 11
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
<
* Closing connection #0
dumm gloffe

Torsten

-- 
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net

ModPerl::Registry and custom error documents

[Andreas Mock]

Hi all,

I searched and googled around for a while but couldn't find a solution for
the following question.

We're using ModPerl::Registry (PerlOptions +ParseHeaders)
in combination with mod_perl to serve our pages in a CGI like
environment. This has the advantage for us to have only a very very
small layer of integration between the scripts an the special runtime
environment.

Now we want to serve custom made error documents and thought
naively to get it work by just setting the status to the error code
and serving a html-page as it works with a normal status 200 page.

But this doesn't work. It seams that apache jumps right into the
error handling stuff as soon as a status code >= 400 is seen.

How can we dynamically create own error documents without using
the lower level mod_perl/apache api? Is there a simple way?
How can we achieve that?

Best regards
Andreas Mock

Re: Ways to scale a mod_perl site

[Jeff Peng]

-Original Message-
>From: Cosimo Streppone 
>Sent: Sep 17, 2009 3:43 AM
>To: Mod_perl users 
>Cc: Jeff Peng 
>Subject: Re: Ways to scale a mod_perl site
>
>Jeff Peng  wrote:
>
>> How many servers?
>> We have run the systems with about 500 million PV each day, with many  
>> squid boxes + 200 apache webservers + 200 mysql hosts.
>> The applications were written with FastCGI.
>
>Wow! Why don't you tell or blog a bit about this?
>I would love to know more about what challenges
>you went through.
>


Yup, at that time the primary pressure against performance was database.
We used distributed Mysql servers with an oracle index server.
Each mysql host served 1 - 1.5 million users.
When an user logined, the application queried oracle to get the mysql host id 
with the key of username.
Then the application queried to mysql and got anything it wanted.
The systems generated 2T data each day (surely we had large amount of store).

The front apache servers with FastCGI were running heavily, I remember 8G 
memory were almost eated.
Squid was useful for static resources, but for dynamic applications like CGI, 
no way to reduce the pressure but adding more machines.

Last, the applications are webmail, the best popolar provider here.


Regards,
Jeff Peng

Re: Ways to scale a mod_perl site

[Cosimo Streppone]

In data 17 september 2009 alle ore 09:43:50, Cosimo Streppone  
 ha scritto:



Jeff Peng  wrote:


How many servers?
We have run the systems with about 500 million PV each day, with many  
squid boxes + 200 apache webservers + 200 mysql hosts.

The applications were written with FastCGI.


Wow! Why don't you tell or blog a bit about this?

[...]
and we currently serve [...]


Mmh, I just re-read that, and I realized it may sound
like: "Wow, look at how cool we are!".

It wasn't meant to sound like that, obviously,
but more like: here's our experience. We'd like to confront
with others on this list.

:-)

--
Cosimo

Re: Ways to scale a mod_perl site

[Cosimo Streppone]

Jeff Peng  wrote:


How many servers?
We have run the systems with about 500 million PV each day, with many  
squid boxes + 200 apache webservers + 200 mysql hosts.

The applications were written with FastCGI.


Wow! Why don't you tell or blog a bit about this?
I would love to know more about what challenges
you went through.

Maybe someone else has also stories to tell.

At Opera Software, our team works on a social network website,
and we currently serve 2 million page views per day peak,
with something around 700,000 unique visitors per day peak,
and ~120M hits per day with under 20 servers.

Those include database servers, apache fronts,
mod_perl backends, varnish/memcached caches, upload servers,
cronjobs/mail, etc...

For the curious:
http://www.slideshare.net/cstrep/myoperacom-scalability-v20

And yes, we're looking for ways to optimize/scale better
our application, since we're growing more and more... :-)

--
Cosimo