Re: highscalability.com report
On Mon, Apr 16, 2012 at 3:39 AM, Vincent Veyron vv.li...@wanadoo.fr 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
Le mardi 17 avril 2012 à 10:04 -0700, Fred Moyer a écrit : On Mon, Apr 16, 2012 at 3:39 AM, Vincent Veyron vv.li...@wanadoo.fr 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
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 https://groups.google.com/group/redis-db/browse_thread/thread/77841c595d29f983?pli=1 clint
Re: highscalability.com report
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
From: Clinton Gormley cl...@traveljury.com 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
Talking of youporn: http://gizmodo.com/5899327/how-much-porn-does-the-internet-hold 10 Dual layer DVDs per second.
Re: highscalability.com report
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
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 RD 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
On Tue, Apr 3, 2012 at 10:50 PM, Jim Schueler jschue...@eloquency.com 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
On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins per...@elem.com 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
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 per...@elem.com 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
On 4 April 2012 09:31, William A. Rowe Jr. wr...@rowe-clan.net 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
Rolf Banting wrote: On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins 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..
Re: highscalability.com report
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 a...@ice-sa.com wrote: Rolf Banting wrote: On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins 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..
Re: highscalability.com report
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 a...@ice-sa.com mailto:a...@ice-sa.com wrote: Rolf Banting wrote: On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins per...@elem.com 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
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. digressing 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. /digressing Michael
Re: highscalability.com report
On Wed, Apr 4, 2012 at 6:37 AM, demerphq demer...@gmail.com wrote: On 4 April 2012 09:31, William A. Rowe Jr. wr...@rowe-clan.net 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
On 4 Apr 2012, at 19:41, Fred Moyer wrote: On Wed, Apr 4, 2012 at 6:37 AM, demerphq demer...@gmail.com wrote: On 4 April 2012 09:31, William A. Rowe Jr. wr...@rowe-clan.net 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
On 4/4/2012 1:41 PM, Fred Moyer wrote: On Wed, Apr 4, 2012 at 6:37 AM, demerphq demer...@gmail.com wrote: On 4 April 2012 09:31, William A. Rowe Jr. wr...@rowe-clan.net 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
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 a...@ice-sa.com mailto:a...@ice-sa.com wrote: Rolf Banting wrote: On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins per...@elem.com 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 Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer Network Services, Inc. Beautiful British Columbia, Canada http://www.inter-corporate.com/
