Re: Amazon
Hi, One of the first things I would look is their job postings...if they are switching, that would be one sign. Indeed, I saw a few software development jobs on amazon asking for Java and C/C++ experience. Only found one asking for any two of Java, C/C++, and Perl. Of course, this is just a hint...they may be hiring people to maintain their payroll database, etc. But you might want to watch their jobs DB to see if there is any trend they're moving toward... Ray Jonathan Vanasco wrote: I've heard from a few reputable sources that Amazon is looking to drop mod_perl, and push into another technology ( which I've also head is likely to be Java ).
Re: Amazon
On 23 Feb 2008, at 07:25, Jie Gao wrote: Choosing java for better performance would certainly be a joke. Java isn't slow you know :) Memory usage, well, that depends. But it's not slow. -- Andy Armstrong, Hexten
Re: Amazon
I think what Jie meant was "choosing java *just* for performance would certainly be a joke" On 2/23/08, Andy Armstrong <[EMAIL PROTECTED]> wrote: > On 23 Feb 2008, at 07:25, Jie Gao wrote: > > Choosing java for better performance would certainly be a joke. > > > Java isn't slow you know :) > > Memory usage, well, that depends. But it's not slow. > > -- > Andy Armstrong, Hexten > > > > >
Re: Amazon
On 23 Feb 2008, at 11:29, [EMAIL PROTECTED] wrote: I think what Jie meant was "choosing java *just* for performance would certainly be a joke" Ah. Sorry. -- Andy Armstrong, Hexten
Re: Amazon
Jonathan Vanasco wrote: I've heard from a few reputable sources that Amazon is looking to drop mod_perl, and push into another technology ( which I've also head is likely to be Java ). I always thought amazon was a good argument for perl but not mod_perl - last time I looked they were using mason + fastcgi (not mod_perl) --Geoff
Re: Amazon
hi, On Sat, 23 Feb 2008, Michael Lackhoff wrote: In a recent issue of the German iX magazine there was a report about a similar migration (www.mobile.de I think). I would like to comment on that article. I think it is very important to read this article less as a "Everyone should migrate to Java, here's why" and more as a "We've been migrating, here's how and what problems we solved". The reason I'm saying this is because the article keeps quiet about some details. I'm not saying the article is wrong or bad, but from a perl programmer's point of view there are some important details left out. - some of the original developers left, so it was difficult to maintain the original codebase This is true. But there were two main reasons why Perl programmers left - The company moved from the city to somewhere in the middle of nowhere. It's normal that you lose employees if you do this. - The company had sponsored perl workshops and had sent people to workshops and conferences before. That stopped long before the switsch to Java. It's no surprise that it gets at least more difficult to find perl programmers if you stop supporting the community. - JAVA community with lots of help and high quality tools and libraries. - the new solution used less resources (they saved a few hundred servers) and still ran faster. Also with that part the article leaves something important out. Part of the solution that saved lots of servers was the new search component. This is written in C++ (I'm telling no secrets here, although this wasn't mentioned in the article), and the first part of the changes was in fact letting the perl code communicate with the new search engine. Already this was a success and saved lots of hardware. While I would certainly say that the new code design and software architecture is much better than the old one (naturally, if you redesign something historically grown up), I'd also say this could have happened with Perl, too. For many features which were actually needed there was no time. But if you do a rewrite you have time for everything. I felt the need to say that after reading the article. Again, the article itself is written well for its purpose, but if you (or your boss) search for reasons to switch to Java you should search for something more detailed. A few years ago the 'P' in LAMP clearly was 'Perl', now it is 'PHP' in most cases. Developers tend to go (even if slowly) where the money is. Well, talking about PHP, I would be careful as a company to say there are more PHP developers, and they are even cheaper, so we switch. There *are* professional PHP programmers and it is possible to write good code, but the fact that there are many PHP programmers is in my opinion due to the fact that it's easy to write a simple website with it and almost every webhoster supports it. So I would estimate to get PHP programmers with the same quality you have to search as long as for perl programmers, if you care about security. So I still hope that at least some companies prefer quality to quantity. regards, tina -- http://darkdance.net/ http://perlpunks.de/
Re: Amazon
On Sat, Feb 23, 2008 at 06:25:42PM +1100, Jie Gao wrote: > > Choosing java for better performance would certainly be a joke. If a > java solution fails, it would be an industry-standard failure, backside > covered. :-) > Just a variation on the old, "Nobody ever got fired for choosing IBM." Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Amazon
modperl is fast, but it consumes too much memory. so we choose fastcgi written by C++. On Sat, Feb 23, 2008 at 10:49 PM, Roberto C. Sánchez <[EMAIL PROTECTED]> wrote: > On Sat, Feb 23, 2008 at 06:25:42PM +1100, Jie Gao wrote: > > > > Choosing java for better performance would certainly be a joke. If a > > java solution fails, it would be an industry-standard failure, backside > > covered. :-) > > > Just a variation on the old, "Nobody ever got fired for choosing IBM." >
Re: Amazon
offtopic: On Sat, 23 Feb 2008, J. Peng wrote: modperl is fast, but it consumes too much memory. so we choose fastcgi written by C++. actually it consumes less memory than FastCGI if you do it right. If you load as many modules and data structures as you can at startup time, Apache will share the memory between the processes (as long as you don't change the data). With FastCGI this is not possible (or so I was told), so you usually end up with using more memory. regards, tina -- http://darkdance.net/ http://perlpunks.de/
Re: Amazon
On Fri, Feb 22, 2008 at 8:59 PM, Jonathan Vanasco <[EMAIL PROTECTED]> wrote: > I've heard from a few reputable sources that Amazon is looking to > drop mod_perl, and push into another technology ( which I've also > head is likely to be Java ). Amazon uses Mason with FastCGI. They have never used mod_perl. They also use nearly everything (C++, Java, etc.) somewhere in their system. The Perl stuff is just used on the front-end. They have a quirky setup. For one thing, they use Safe, which makes it hard to use all the normal CPAN modules. I'd be surprised if they moved off Perl though. It would be a major investment for them to rewrite. - Perrin
Re: Amazon
On Sat, Feb 23, 2008 at 10:08 AM, Tina Müller <[EMAIL PROTECTED]> wrote: > On Sat, 23 Feb 2008, J. Peng wrote: > > > modperl is fast, but it consumes too much memory. > > so we choose fastcgi written by C++. > > actually it consumes less memory than FastCGI if you do it right. If you > load as many modules and data structures as you can at startup time, > Apache will share the memory between the processes (as long as you don't > change the data). > With FastCGI this is not possible (or so I was told), so you usually end > up with using more memory. The process model is pretty similar (pre-fork), so it should be about the same. The important part of that sentence though was "C++", which would have a smaller footprint than Perl if it was done well. It's a tradeoff for developer time of course... - Perrin
Re: Amazon
On Sat, Feb 23, 2008 at 11:08 PM, Tina Müller <[EMAIL PROTECTED]> wrote: > offtopic: > > > On Sat, 23 Feb 2008, J. Peng wrote: > > > modperl is fast, but it consumes too much memory. > > so we choose fastcgi written by C++. > > actually it consumes less memory than FastCGI if you do it right. If you > load as many modules and data structures as you can at startup time, > Apache will share the memory between the processes (as long as you don't > change the data). Apache with prefork mode can share the memory? Sorry I didn't know it. Sharing memory between multi-processes need extra programming, I don't know apache has done it already.
Re: Amazon
On Sat, 23 Feb 2008, J. Peng wrote: > On Sat, 23 Feb 2008, J. Peng wrote: > > > modperl is fast, but it consumes too much memory. > > so we choose fastcgi written by C++. > > actually it consumes less memory than FastCGI if you do it right. If you > load as many modules and data structures as you can at startup time, > Apache will share the memory between the processes (as long as you don't > change the data). Apache with prefork mode can share the memory? Sorry I didn't know it. Sharing memory between multi-processes need extra programming, I don't know apache has done it already. well, it's not "shared memory", it's just the simple forking model which doesn't copy memory, for example module code or big configuration data. only if you change some of the data the process copies the memory page. -- http://darkdance.net/ http://perlpunks.de/
Re: Amazon
J. Peng wrote: Apache with prefork mode can share the memory? Sorry I didn't know it. Sharing memory between multi-processes need extra programming, I don't know apache has done it already. Both prefork and worker models share memory. fork() takes all of your pages and marks them "copy on write". This means; no-touchie, share nice. Don't confuse this with shared, writeable pages. Once you do write to any byte of a common page (even assigning the same value and not actually anything), the kernel makes you up your own private copy. Do that in every fork()ed child, and it hurts. This is why the process and conf pools of httpd should never be touched by a sane module from the child_init hook, onwards. But you won't notice the sharing as much with worker model, since there might be only 10 processes sharing memory to support 250 children, instead of 250 children all sharing that same config. Although worker starts out 25 times more compact, so the net win from fork()+threading is roughly equivalent ;-)
