Re: highscalability.com report

2012-04-04 Thread William A. Rowe Jr. 
On 4/3/2012 9:50 PM, Jim Schueler wrote:
> Hope this doesn't get trapped by too many spam filters.
> 
> Sad news.  Just saw a blog
> 
>   http://www.highscalability.com/
> 
> that reports YouPorn.com switched from Perl to PHP.  Apparently there's a 
> reported 10%
> improvement in speed, but I haven't noticed :).
> 
> After a couple months of total immersion, I have less inclination towards
> PHP than ever.  Fight's not out of me yet.

If one is comparing an every-connection mod_perl enabled environment
to a specific-content, fastcgi-proxied php buildout, there's no contest.

When was the last time you built perl with no threading support?  It's
certainly a 5%-15% win.

Re: highscalability.com report

2012-04-04 Thread Issac Goldstand 
On 04/04/2012 10:31, William A. Rowe Jr. wrote:
> On 4/3/2012 9:50 PM, Jim Schueler wrote:
>> Hope this doesn't get trapped by too many spam filters.
>>
>> Sad news.  Just saw a blog
>>
>>   http://www.highscalability.com/
>>
>> that reports YouPorn.com switched from Perl to PHP.  Apparently there's a 
>> reported 10%
>> improvement in speed, but I haven't noticed :).
>>
>> After a couple months of total immersion, I have less inclination towards
>> PHP than ever.  Fight's not out of me yet.
> If one is comparing an every-connection mod_perl enabled environment
> to a specific-content, fastcgi-proxied php buildout, there's no contest.
>
> When was the last time you built perl with no threading support?  It's
> certainly a 5%-15% win.
Agreed.  Honestly, I love mod_perl for easy Apache internals and for
doing really cool things with the httpd API  but if I was given a blank
R&D department and told to build a web site (a public-facing HTML-based
beast, not a webservice or some other API endpoint), I'd very likely
pick PHP.  It's faster and simpler (not easier, but simpler) for people
to work with and if set up properly can be fast enough to serve.  Since
PHP's APC stabilized, I've always considered it to be "good enough"
against the speed advantage of registry scripts

  Issac

Re: highscalability.com report

2012-04-04 Thread Perrin Harkins 
On Tue, Apr 3, 2012 at 10:50 PM, Jim Schueler  wrote:
> that reports YouPorn.com switched from Perl to PHP.  Apparently there's a
> reported 10% improvement in speed, but I haven't noticed :).

We lost YouPorn?!  Tragic!

I'd say the joke's on them though.  If you rewrite an old site and
only get a 10% speed improvement, that's pretty weak.  If they were to
rewrite it in Perl today, it would go up again!

- Perrin

Re: highscalability.com report

2012-04-04 Thread Rolf Banting 
On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins  wrote:

> ...

If they were to
> rewrite it in Perl today, *it would go up again*!
>
> - Perrin
>

No performance anxiety there then.

Re: highscalability.com report

2012-04-04 Thread Mike OK 
LOL
  - Original Message - 
  From: Rolf Banting 
  To: Perrin Harkins 
  Cc: Jim Schueler ; modperl@perl.apache.org 
  Sent: Wednesday, April 04, 2012 9:13 AM
  Subject: Re: highscalability.com report




  On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins  wrote:

... 
If they were to
rewrite it in Perl today, it would go up again!

- Perrin


  No performance anxiety there then.

Re: highscalability.com report

2012-04-04 Thread demerphq 
On 4 April 2012 09:31, William A. Rowe Jr.  wrote:
> On 4/3/2012 9:50 PM, Jim Schueler wrote:
>> Hope this doesn't get trapped by too many spam filters.
>>
>> Sad news.  Just saw a blog
>>
>>   http://www.highscalability.com/
>>
>> that reports YouPorn.com switched from Perl to PHP.  Apparently there's a 
>> reported 10%
>> improvement in speed, but I haven't noticed :).
>>
>> After a couple months of total immersion, I have less inclination towards
>> PHP than ever.  Fight's not out of me yet.
>
> If one is comparing an every-connection mod_perl enabled environment
> to a specific-content, fastcgi-proxied php buildout, there's no contest.
>
> When was the last time you built perl with no threading support?  It's
> certainly a 5%-15% win.

Not certainly. We did that and saw almost no difference.

Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: highscalability.com report

2012-04-04 Thread André Warnier 

Rolf Banting wrote:

On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins  wrote:


...


If they were to

rewrite it in Perl today, *it would go up again*!

- Perrin



No performance anxiety there then.


Particularly with a non-threaded Perl, which allows Apache to fork multiple 
times..

Re: highscalability.com report

2012-04-04 Thread discobeta 
agree, any rewrite of old code should improve by at least 10%, even if it
was written in pascal

On Wed, Apr 4, 2012 at 10:21 AM, André Warnier  wrote:

> Rolf Banting wrote:
>
>> On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins  wrote:
>>
>>  ...
>>>
>>
>> If they were to
>>
>>> rewrite it in Perl today, *it would go up again*!
>>>
>>> - Perrin
>>>
>>>
>> No performance anxiety there then.
>>
>>  Particularly with a non-threaded Perl, which allows Apache to fork
> multiple times..
>
>

Re: highscalability.com report

2012-04-04 Thread Dave Morgan 

Hi All,
So they did a complete rewrite without changing the hardware?
My guess is that the site on the same hardware would be substantially slower.

IMHO
Dave


On 04/04/12 08:23 AM, discobeta wrote:

agree, any rewrite of old code should improve by at least 10%, even if it was 
written in pascal

On Wed, Apr 4, 2012 at 10:21 AM, André Warnier mailto:a...@ice-sa.com>> wrote:

Rolf Banting wrote:

On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins mailto:per...@elem.com>> wrote:

...


If they were to

rewrite it in Perl today, *it would go up again*!

- Perrin


No performance anxiety there then.

Particularly with a non-threaded Perl, which allows Apache to fork multiple 
times..





--
Dave Morgan
Operations Manager, Cool Places In Canada
http://www.coolplaces.ca
dave.mor...@coolplaces.ca
403 288 8759 / 866 938 0516

Re: highscalability.com report

2012-04-04 Thread Michael Ludwig 
demerphq schrieb am 04.04.2012 um 15:37 (+0200):

> > When was the last time you built perl with no threading support?
> >  It's certainly a 5%-15% win.
> 
> Not certainly. We did that and saw almost no difference.


As I see threads mentioned here: I know that there's some Perl threads
knowledge on this list, so I'd like to draw your attention to a question
I asked on StackOverflow about threads in Perl (as I feel guiding docs
for that topic are lacking).

Use cases for ithreads (interpreter threads) in
Perl and rationale for using or not using them?
http://stackoverflow.com/q/9973860/269126

Maybe you'd like to add some of your knowledge over there. Thanks.


Michael

Re: highscalability.com report

2012-04-04 Thread Fred Moyer 
On Wed, Apr 4, 2012 at 6:37 AM, demerphq  wrote:
> On 4 April 2012 09:31, William A. Rowe Jr.  wrote:
>>
>> When was the last time you built perl with no threading support?  It's
>> certainly a 5%-15% win.
>
> Not certainly. We did that and saw almost no difference.

I've done two perlbench sets of comparisons with threaded/non-threaded
across a couple different versions of perl. I don't have the results
posted on the web anymore, but non-threaded was up to 20% faster for
some operations.

As far as real world differences go, I don't think you are likely to
see differences with mod_perl in production environments with threaded
vs non-threaded.  That 20% increase probably only affects 1% of your
application.

Re: highscalability.com report

2012-04-04 Thread Dave Hodgkinson 

On 4 Apr 2012, at 19:41, Fred Moyer wrote:

> On Wed, Apr 4, 2012 at 6:37 AM, demerphq  wrote:
>> On 4 April 2012 09:31, William A. Rowe Jr.  wrote:
>>> 
>>> When was the last time you built perl with no threading support?  It's
>>> certainly a 5%-15% win.
>> 
>> Not certainly. We did that and saw almost no difference.
> 
> I've done two perlbench sets of comparisons with threaded/non-threaded
> across a couple different versions of perl. I don't have the results
> posted on the web anymore, but non-threaded was up to 20% faster for
> some operations.
> 
> As far as real world differences go, I don't think you are likely to
> see differences with mod_perl in production environments with threaded
> vs non-threaded.  That 20% increase probably only affects 1% of your
> application.


I would say the app layer performance is the least of your worries. Front-end
caching, CDNs and caching in the intermediate layers will win you much, much
more than fretting about +/- 20% in the speed of the code. And if you have
a scalable architecture, and I'm assuming youporn is, you can always go
sideways very easily.

Re: highscalability.com report

2012-04-04 Thread William A. Rowe Jr. 
On 4/4/2012 1:41 PM, Fred Moyer wrote:
> On Wed, Apr 4, 2012 at 6:37 AM, demerphq  wrote:
>> On 4 April 2012 09:31, William A. Rowe Jr.  wrote:
>>>
>>> When was the last time you built perl with no threading support?  It's
>>> certainly a 5%-15% win.
>>
>> Not certainly. We did that and saw almost no difference.
> 
> I've done two perlbench sets of comparisons with threaded/non-threaded
> across a couple different versions of perl. I don't have the results
> posted on the web anymore, but non-threaded was up to 20% faster for
> some operations.
> 
> As far as real world differences go, I don't think you are likely to
> see differences with mod_perl in production environments with threaded
> vs non-threaded.  That 20% increase probably only affects 1% of your
> application.

Right.  The missing detail/point was that a well-tuned pool of single
threaded PHP, or Perl, or assembly coded worker processes running under
fcgid is going to outperform the in-process model, given finite cpu and
memory resources.

Re: highscalability.com report

2012-04-04 Thread Randolf Richardson 
> Hi All,
>   So they did a complete rewrite without changing the hardware?
> My guess is that the site on the same hardware would be substantially slower.

A change to the database design, as well as database engine (e.g.,
to something fantastic like PostgreSQL), indexing strategies, etc.,
would also be expected to have a major impact too.

[End of reply.]

> IMHO
> Dave
>
>
> On 04/04/12 08:23 AM, discobeta wrote:
> > agree, any rewrite of old code should improve by at least 10%, even if it 
> > was written in pascal
> >
> > On Wed, Apr 4, 2012 at 10:21 AM, André Warnier  > > wrote:
> >
> > Rolf Banting wrote:
> >
> > On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins  > > wrote:
> >
> > ...
> >
> >
> > If they were to
> >
> > rewrite it in Perl today, *it would go up again*!
> >
> > - Perrin
> >
> >
> > No performance anxiety there then.
> >
> > Particularly with a non-threaded Perl, which allows Apache to fork 
> > multiple times..
> >
> >
>
>
> --
> Dave Morgan
> Operations Manager, Cool Places In Canada
> http://www.coolplaces.ca
> dave.mor...@coolplaces.ca
> 403 288 8759 / 866 938 0516


Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/

Re: highscalability.com report

2012-04-05 Thread Dave Hodgkinson 

Talking of youporn:

http://gizmodo.com/5899327/how-much-porn-does-the-internet-hold

10 Dual layer DVDs per second.

Re: highscalability.com report

2012-04-12 Thread Clinton Gormley 
On Tue, 2012-04-03 at 22:50 -0400, Jim Schueler wrote:
> Hope this doesn't get trapped by too many spam filters.
> 
> Sad news.  Just saw a blog
> 
>http://www.highscalability.com/
> 
> that reports YouPorn.com switched from Perl to PHP.  Apparently there's a 
> reported 10% improvement in speed, but I haven't noticed :).

I think the bigger factor in the speed improvement is probably to do
with switching from MySQL to Redis

https://groups.google.com/group/redis-db/browse_thread/thread/77841c595d29f983?pli=1

clint

Re: highscalability.com report

2012-04-12 Thread Michael Peters 

On 04/12/2012 10:00 AM, Clinton Gormley wrote:


I think the bigger factor in the speed improvement is probably to do
with switching from MySQL to Redis

https://groups.google.com/group/redis-db/browse_thread/thread/77841c595d29f983?pli=1


They didn't really "switch" from mysql to redis. They are using Redis as 
a structured caching layer in front of mysql. Their authoritative data 
is still stored in mysql, but they have several "views" of that data 
that they export regularly to redis. The site pulls these cached views 
from redis and yes that's very fast.


It's kind of similar to a lot of other really big systems (like 
facebook). Authoritative data in an SQL database and then their read 
data in denormalized structures in a NoSQL database.


--
Michael Peters
Plus Three, LP

Re: highscalability.com report

2012-04-12 Thread Octavian Rasnita 

From: "Clinton Gormley" 
Subject: Re: highscalability.com report



On Tue, 2012-04-03 at 22:50 -0400, Jim Schueler wrote:

Hope this doesn't get trapped by too many spam filters.

Sad news.  Just saw a blog

   http://www.highscalability.com/

that reports YouPorn.com switched from Perl to PHP.  Apparently there's a
reported 10% improvement in speed, but I haven't noticed :).


I think the bigger factor in the speed improvement is probably to do
with switching from MySQL to Redis




Yeah, so there should be other reasons for passing from Perl to PHP.

What could be?

Octavian

RE: highscalability.com report

2012-04-12 Thread Jim Schueler 
Chicken and egg problem.  I have posted quite a bit about the pain of 
migrating my skill set to PHP.  And doing whatever I can do stop that

descent.  That's what makes the news so "sad", as I posted originally.

 -Jim

On Thu, 12 Apr 2012, eric.b...@barclays.com wrote:


Well, finding (good) developers is certainly an issue.

Here in NYC, it's very difficult to find proper Perl programmers as opposed to 
dabblers and scripters.

One of the larger web sites here in the city was built by a great Perl guy, but 
as they've grown and become successful, finding Perl talent has become a big 
issue.  I'm told that they're somewhere down the road to moving to PHP.


-Original Message-
From: Octavian Rasnita [mailto:orasn...@gmail.com]
Sent: Thursday, April 12, 2012 1:02 PM
To: Clinton Gormley; Jim Schueler
Cc: modperl@perl.apache.org
Subject: Re: highscalability.com report

From: "Clinton Gormley" 
Subject: Re: highscalability.com report



On Tue, 2012-04-03 at 22:50 -0400, Jim Schueler wrote:

Hope this doesn't get trapped by too many spam filters.

Sad news.  Just saw a blog

   http://www.highscalability.com/

that reports YouPorn.com switched from Perl to PHP.  Apparently

there's a

reported 10% improvement in speed, but I haven't noticed :).


I think the bigger factor in the speed improvement is probably to do
with switching from MySQL to Redis




Yeah, so there should be other reasons for passing from Perl to PHP.

What could be?

Octavian



___
Barclays is one of the world's leading banks, and we believe that by continuing 
to integrate the organisation we can better deliver the full power of Barclays 
to customers, clients and the communities in which we work.
As a visible sign of that integration we are moving to a single Barclays brand 
for the majority of our divisions, including those formerly known as Barclays 
Capital, Barclays Wealth and Barclays Corporate.

___

This e-mail may contain information that is confidential, privileged or 
otherwise protected from
disclosure. If you are not an intended recipient of this e-mail, do not 
duplicate or redistribute
it by any means. Please delete it and any attachments and notify the sender 
that you have received
it in error. Unless specifically indicated, this e-mail is not an offer to buy 
or sell or a
solicitation to buy or sell any securities, investment products or other 
financial product or
service, an official confirmation of any transaction, or an official statement 
of Barclays. Any
views or opinions presented are solely those of the author and do not 
necessarily represent those
of Barclays. This e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer.
By messaging with Barclays you consent to the foregoing.  Barclays offers 
premier investment banking
products and services to its clients through Barclays Bank PLC, a company 
registered in England
(number 1026167) with its registered office at 1 Churchill Place, London, E14 
5HP.  This email may
relate to or be sent from other members of the Barclays Group.

___

RE: highscalability.com report

2012-04-15 Thread eric.berg 
Well, finding (good) developers is certainly an issue.

Here in NYC, it's very difficult to find proper Perl programmers as opposed to 
dabblers and scripters.

One of the larger web sites here in the city was built by a great Perl guy, but 
as they've grown and become successful, finding Perl talent has become a big 
issue.  I'm told that they're somewhere down the road to moving to PHP.

> -Original Message-
> From: Octavian Rasnita [mailto:orasn...@gmail.com]
> Sent: Thursday, April 12, 2012 1:02 PM
> To: Clinton Gormley; Jim Schueler
> Cc: modperl@perl.apache.org
> Subject: Re: highscalability.com report
> 
> From: "Clinton Gormley" 
> Subject: Re: highscalability.com report
> 
> 
> > On Tue, 2012-04-03 at 22:50 -0400, Jim Schueler wrote:
> >> Hope this doesn't get trapped by too many spam filters.
> >>
> >> Sad news.  Just saw a blog
> >>
> >>http://www.highscalability.com/
> >>
> >> that reports YouPorn.com switched from Perl to PHP.  Apparently
> there's a
> >> reported 10% improvement in speed, but I haven't noticed :).
> >
> > I think the bigger factor in the speed improvement is probably to do
> > with switching from MySQL to Redis
> >
> 
> 
> Yeah, so there should be other reasons for passing from Perl to PHP.
> 
> What could be?
> 
> Octavian


___
Barclays is one of the world's leading banks, and we believe that by continuing 
to integrate the organisation we can better deliver the full power of Barclays 
to customers, clients and the communities in which we work. 
As a visible sign of that integration we are moving to a single Barclays brand 
for the majority of our divisions, including those formerly known as Barclays 
Capital, Barclays Wealth and Barclays Corporate.

___

This e-mail may contain information that is confidential, privileged or 
otherwise protected from 
disclosure. If you are not an intended recipient of this e-mail, do not 
duplicate or redistribute 
it by any means. Please delete it and any attachments and notify the sender 
that you have received 
it in error. Unless specifically indicated, this e-mail is not an offer to buy 
or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or 
service, an official confirmation of any transaction, or an official statement 
of Barclays. Any 
views or opinions presented are solely those of the author and do not 
necessarily represent those 
of Barclays. This e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer. 
By messaging with Barclays you consent to the foregoing.  Barclays offers 
premier investment banking 
products and services to its clients through Barclays Bank PLC, a company 
registered in England 
(number 1026167) with its registered office at 1 Churchill Place, London, E14 
5HP.  This email may 
relate to or be sent from other members of the Barclays Group.

___

Re: highscalability.com report

2012-04-15 Thread Dave Hodgkinson 

On 12 Apr 2012, at 18:14,   
wrote:

> Well, finding (good) developers is certainly an issue.
> 
> Here in NYC, it's very difficult to find proper Perl programmers as opposed 
> to dabblers and scripters.
> 
> One of the larger web sites here in the city was built by a great Perl guy, 
> but as they've grown and become successful, finding Perl talent has become a 
> big issue.  I'm told that they're somewhere down the road to moving to PHP.

A good programmer can be a good programmer in any language. Good luck finding
a PHP programmer who really knows his stuff.

Also, if you need perl talent in NY, talk to Uri Gutmann.

RE: highscalability.com report

2012-04-16 Thread Vincent Veyron 
Le jeudi 12 avril 2012 à 13:14 -0400, eric.b...@barclays.com a écrit :
> Well, finding (good) developers is certainly an issue.
> 

Over the years, I have seen more than one of those being driven out of
the field by the inane management that most developers toil under. And
considering how demanding it is to be a good programmer, I can see why
they give up : you just can't have both.

On the other hand, I see scores of good developers in open source
projects (their products certainly are very good)


-- 
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres assurances et des dossiers contentieux pour 
le service juridique

Re: highscalability.com report

2012-04-17 Thread Fred Moyer 
On Mon, Apr 16, 2012 at 3:39 AM, Vincent Veyron  wrote:
> Le jeudi 12 avril 2012 à 13:14 -0400, eric.b...@barclays.com a écrit :
>> Well, finding (good) developers is certainly an issue.
>>
> Over the years, I have seen more than one of those being driven out of
> the field by the inane management that most developers toil under. And
> considering how demanding it is to be a good programmer, I can see why
> they give up : you just can't have both.
>
> On the other hand, I see scores of good developers in open source
> projects (their products certainly are very good)

I think the one of the main reasons this dichotomy exists is that in
open source, developers spend the bulk of their time programming. In
closed source work, developers start out doing a lot of programming,
but over time spend less time programming, and more time going to
meetings, writing status reports, and filling out HR paperwork,
killing processes on overloaded dev servers, etc. The best development
managers I've seen shield their programmers from those tasks and allow
them to get work done. There is no agile silver bullet to make
programmers more effective except giving them uninterrupted time to do
their jobs.

Re: highscalability.com report

2012-04-17 Thread Vincent Veyron 
Le mardi 17 avril 2012 à 10:04 -0700, Fred Moyer a écrit :
> On Mon, Apr 16, 2012 at 3:39 AM, Vincent Veyron  wrote:
> > Le jeudi 12 avril 2012 à 13:14 -0400, eric.b...@barclays.com a écrit :
> >> Well, finding (good) developers is certainly an issue.
> >>
> > Over the years, I have seen more than one of those being driven out of
> > the field by the inane management that most developers toil under. And
> > considering how demanding it is to be a good programmer, I can see why
> > they give up : you just can't have both.
> >
> > On the other hand, I see scores of good developers in open source
> > projects (their products certainly are very good)
> 
> I think the one of the main reasons this dichotomy exists is that in
> open source, developers spend the bulk of their time programming. In
> closed source work, developers start out doing a lot of programming,
> but over time spend less time programming, and more time going to
> meetings, writing status reports, and filling out HR paperwork,
> killing processes on overloaded dev servers, etc. 

That is certainly a problem, I find those meetings awfully inefficient
compared to what gets done with mailing lists (eg : linux kernel,
postgresql...). 

But I see another reason : I find a _huge_ part of the workload in
business applications is generated by the demands of the management
local to that organization (hence the meetings). On the other hand,
administrative tasks in general do not change fundamentally very often.

I can imagine a future when we have a few basic open source business
applications that cover 90% of the needs for accounting/CRM/case
management. Most people will just use that, and whoever has special
needs can fork it if it's worth his effort. That would greatly reduce
the need for those meetings.



> The best development
> managers I've seen shield their programmers from those tasks and allow
> them to get work done. There is no agile silver bullet to make
> programmers more effective except giving them uninterrupted time to do
> their jobs.











-- 
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres assurances et des dossiers contentieux pour 
le service juridique