Reply to Re: can any PHP framework match Ruby On Rails clarity of design?

Your name:

Reply:


Posted by lawrence k on 12/28/06 02:43

NC wrote:
> In the same vein, if you absolutely have to have a framework,
> you should consider implementing it as a PHP extension...

That is the attitude taken by the Ruby On Rails crowd. After a project
launches, they profile it and if a part of the code is very CPU
intensive, they rewrite in C. David Heinemeier Hansson, in a recent
interview, talked about rewriting a bottleneck in C, to get better
performance than what he was getting in Ruby:

http://www.infoq.com/interviews/David-Hansson

"We built up the entire Campfire system without really worrying about
scalability. Then the day came when we were actually done with the
system, when we had the system that we wanted to launch, and then we
needed to care about scalability. So we started to do stress testing,
we started running performance benchmarks and we realized that the
initial setup we had was just not fast enough. Step one was adding
caching in Rails. ... If you can cache, your execution can be as slow
as you want, as long as you can do it with cache and cache hits are
high enough, you're totally fine. But in our case we (eventually) did
feel the need to make something faster, so we looked at the Campfire
application. Where was the bottleneck? Where were we having issues or
issues that were going too slow? We found that bottleneck and that
bottleneck was a hundred lines of Ruby code. The responder to that poll
"Did I get a new message, Did I get a new message" The guy who
responded to that question was a bottleneck, a hundred lines of Ruby
code. ...We could easily do millions of requests per day, just because
we have all these people asking "Did I get a new message?" So we chose
to rewrite those hundred lines of Ruby code, to see what it would take
to write it in the fastest language we can rewrite it in; we didn't
rewrite it in assember, but we rewrote it in C, a fantastic language
for rewriting performance bottlenecks. So we rewrote a hundred lines of
Ruby code into three hundred lines of C, in about 3 hours. The great
part was that we had already done all the locking, we already had a
completely working system, we had already specified all of the behavior
in Ruby, so we were not exploring anything in C, we were just
translating lines pretty much, asking "How do we make this Ruby line
into C and make it reasonably fast". We still have the Ruby version so
when you look at the Ruby version and you look at the C version, you
see that they roughly do the same thing. Ruby does it a lot more
eloquently, in a lot less code, and with a lot less mental overhead.
The C version does roughly the same, it's just a lot faster. It's
hitting the database: two requests per question, one request for
permissions and one request to see if you got something new. But since
we cache, those requests are stupidly cheap to make. So even though we
could have said: "This is not even going to scale, we've got the poller
in C, but we're still hitting the database so it's still too expensive"
then the next option was right there for us. If the database were not
fast enough, memcache would be the next obvious step; and that's going
to scale definitely too. So we just haven't moved down the path yet,
but it's there..."

[Back to original message]


Удаленная работа для программистов  •  Как заработать на Google AdSense  •  England, UK  •  статьи на английском  •  PHP MySQL CMS Apache Oscommerce  •  Online Business Knowledge Base  •  DVD MP3 AVI MP4 players codecs conversion help
Home  •  Search  •  Site Map  •  Set as Homepage  •  Add to Favourites

Copyright © 2005-2006 Powered by Custom PHP Programming

Сайт изготовлен в Студии Валентина Петручека
изготовление и поддержка веб-сайтов, разработка программного обеспечения, поисковая оптимизация