Wednesday, March 21. 2007A real-world use of liftTrackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
very promising. I'd love to keep reading more real world experiences your having with the port beyond the scalability. How was your teams reactions to using yet another new framework and language? I'll be honest, scala's syntax turns me off, but I haven't given it a honest try, just a skim of the docs.
The team was initially cranky with "yet another language." However, they're Java guys so they felt much more at home with Scala. One of the team members had working code in a day, so that was a huge win.
On the syntax front, Scala is less ugly (by a long shot) than Java. Once one starts getting "functional" with Scala, being familiar with Scala idioms helps. One can write Scala code that looks like Ruby code (and not having the annoying @ signs everywhere is a real win.) But that code is much more "imperative" in its style and tends to be more verbose. I find that Haskell is a much more difficult for me to read as a functional language that Scala. A lot of it, I think, is experience with particular syntax and idioms.
You know, you can have multiple JRuby runtimes in the same VM to handle many Rails requests without spawning another VM. Rails is designed to be single-threaded (or really, single-runtime) but by pooling a few JRuby runtimes you can handle as many requests as you like.
Look at the rails-integration project hosted in the JRuby Extras project on RubyForge or google it to get more information.
I'm curious as to why your performance test was behind Tomcat when you cited Jetty continuations as one reason for moving over to Scala/JVM.
At first glance, I have to say that the Scala syntax is not altogether pleasing to my eyes, either. BUT, Scala packs a lot of power into its syntax and it's not so awful looking that I find it unapproachable. Scala balances a fair number of requirements well.
I haven't finished the magic to get Jetty continuations to work with lift yet. Additionally, our deployment infrastructure is currently Tomcat, although I expect to change that over once the continuations work is done.
Makes sense. I'll be curious to see what the Jetty continuations part looks like.
It seems to me that Jetty's continuations only provide a subset of what Scala's event-based actors can do for you. For example, when an actor waits for a message using react { ... }, it also frees the underlying thread, but it also saves all the state that is accessed from inside the message handling cases (because it constructs a closure). So, why not wrap all the asynchronous requests in thread-less actors?
Lift looks lovely but for the inlined XmlResponses, which has that whole "code/presentation mixing" problem. Might be appropriate for this XML-returning RESTful app, but web apps that run on xhtml really do need designer-friendly external templates. Well, at least mine do.
Is there a plan (or something already existing) for lift to support an attribute language, or perhaps some kind of Scala HaXML workalike?
Yes. "Controller" methods can return a lot of different things.
A controller can return a map of name/value pairs that's passed into a view. A controller can return a function that operates as a view. A controller can return nothing and an appropriate view is located. Or a controller can compose and return XML or XHTML. So, there's maximum flexibility. In this example, I found that integrating the view and controller was optimal. For XHTML page composition, the view/controller separation is the optimal way to do things.
I disagree Chuck: in this case, the XML response isn't 'presentation' like HTML might be -> it is truly a typed-contract between the server and the client (albeit, one the compiler can't check). So to me it is very appropriate that it appear there in code.
Btw, this is great work!
One of my biggest annoyances with developing webapps in Java (on Tomcat), is that I can't simply change the code and reload the app. Sometimes I might be able to reload the app using for example the tomcat manager, but in my current project I can't do that due to various other libraries being used. So I have to restart the entire server every time I make the smallest change. Very frustrating. How is the Scala/lift combination in this respect?
Right now, the results are mixed, but it's a priority for me.
For "long lived controllers" that use Scala Actors (that's how lift implements the chat and clock), there's less than optimal interaction with Tomcat's reload mechanism. I'm working with the folks who wrote Scala's Actor library and the issue will be resolved either this week or in the next release of the Scala Actor package. For short-lived controllers (like the ones used in the real world work and like Rails controllers), there are very few issues. Basically, change a class, wait 5 seconds, load the web page and all is good. Every once in a while, if the change is global (e.g., many or all classes are rebuilt), Tomcat's classloader picks up a bad combination of old and new classes. This happens to me once or twice a day.
I agree that in this case, the XML response is quite strongly typed and perfectly appropriate for this particular app. Some apps demand looser coupling however. My fault though: I failed to notice http://liftweb.googlecode.com/svn/trunk/liftweb/example/src/main/webapp/ which has exactly the sort of XHTML template scheme I was asking about.
I wish I'd come across lift sooner -- might have been able to avoid so much of the pain I've experienced using JSF (Seam makes it quite tolerable, but really only in a relative sense).
Hello this has nothing to do with your blog or post, but I just wanted to ask if you own the domain www.athena.com, and if so, why did you choose that name?
Thanks!
I just wanted to point out that your original premise (concern about the scalability of Rails) is incorrect. Rails scales using LAMP style architectures, not by language-based multi-threading. You could have made Rails do what you wanted.
That being said, Scala and lift look very interesting, and I am investigating them myself.
Curt,
Please explain how you can have 10,000 simultaneous clients connected to a single machine running Rails. We could not figure a way that Rails could service more than 40-50 simultaneous (open) connections on the same box. Please explain to me how Rails/Ruby can listen for "events" beyond just querying the database asking "should I do something now?" I looked into a Rinda-based solution without luck. Even Rich Kilmer uses Erlang for part of the indi infrastructure (or so he claimed at RubyConf.) There are places where event based/Actor based architectures work better than Rails request/response architecture. We were unable to solve the scalability issues that our application presented exclusively within Rails/Ruby. Short of going outside Rails/Ruby, how can one solve the massive simultaneous connection issue? I look forward to any comments and feedback you have on this issue as well as on lift.
David,
I am curious about that 100% utilization on Rails. Sound a bit suspicious. Did you try to profile it? Where was all the time spent? What was the memory utilization in both cases? I was wondering if you might have had some bad code in Rails in maybe a model that was then fixed during the code to Lift. Maybe some plugin, or bad architectural decision. I developed many rails apps and never saw cpu going to 100%. Were you pounding the crap out of the app during benchmarking? If so, 100% cpu utilization might be what you want. If you are hitting the app full throttle and the cpu is only going 5% it might mean that you are either not hitting it hard enough or the bottleneck is somewhere else, like memory or disk IO. Maybe then fixing that bottleneck should give you higher cpu usage and higher throughput. Just curious. p.s. I am also been investigating Lift and Scala for a project that I am currently working on. |
David PollakCalendar
QuicksearchCategoriesBlog Administration |
||||||||||||||||||||||||||||||||||||||||||