On Thu, Mar 5, 2009 at 8:31 AM, Jeff Chen <jeff.chen.gr...@gmail.com> wrote:
> Great article! > > It mentions that "the "game" supports 2,000 simultaneous players." For > comparison, can you estimate, roughly of course, how many players > Rails/Django can support with the same app? > Not an identical app, but a similar messaging system would require about 75 front-end Rails servers to deal with the same traffic load. Rails (until recently) was single threaded, so doing long polling with Rails requires a dedicated Rails instance with will consume ~ 300MB of RAM. ~300MB x 2,000 = ~ 600GB of RAM just for the server processes. So, 75 servers with 8GB of RAM each might be able to do the job. This does not include the messaging and inter-user communications which would also consume some form of messaging system, but we can, for the sake of argument, figure that's running on a single RabbitMQ instance (in Erlang) or some-such. It's been my experience with Rails that you need between 20 and 50 times more hardware to run the same Rails app vs. a Lift app. > I wonder whether the performance will be even better if there are more > cores in that server. > Perhaps, although the JVM had 4GB allocated to heap space and the app seemed to be more RAM bound than CPU bound. Making sure there's plenty of memory means that the GC mechanism is happier. With the JVM and with Scala which creates a lot of short-lived objects, having lots of available memory is the key to good performance. > Just curious where the performance boost came from. Is it safe to say > Rails/Django's performance will not change whether running on dual-core or > quad-core machines, because they are not concurrent in nature? > Rails is designed for the sole purpose of translating an HTTP request into another request... usually RDBMS. Rails is not designed for event-based, messaging-style applications. Django and TurboGears sit on top of Python and Python's Twisted library is a great event-based system. I don't know what the integration points are between Django or TurboGears and Twisted, but if some exist, you'd see reasonable performance out of one of those frameworks. > > Does anybody know a performance comparison between Lift and others? Some > hard numbers will be very useful. > Performance comparisons are very difficult. The time it takes to serve "Hello World" may be part of the equation. How long it takes to render a complex page is another part of the equation. Routing of Ajax or Comet requests is another part of the equation (Lift does this particularly well). So, Lift is going to do very, very well for Ajax/Comet game, real-time applications. It may do less well for other applications. In any case, if you can find a benchmark where Lift underperforms Django or Rails, it's a Lift bug and we will fix it. > > > http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/ > > Thanks, > Jeff > > > On Wed, Mar 4, 2009 at 2:55 PM, David Pollak < > feeder.of.the.be...@gmail.com> wrote: > >> http://www.adtmag.com/article.aspx?id=24080 >> >> -- >> Lift, the simply functional web framework http://liftweb.net >> Beginning Scala http://www.apress.com/book/view/1430219890 >> Follow me: http://twitter.com/dpp >> Git some: http://github.com/dpp >> >> >> > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
