Lift can parallelize page rendering. This is a huge win if you need to consult external servers while rendering a page. If you need to go out to 10 different ad servers and each one takes half a second to respond, you want to run those in parallel:
Ad server #1: pool-3-thread-16
Ad server #2: pool-3-thread-7
Ad server #3: pool-3-thread-14
Ad server #4: pool-3-thread-11
Ad server #5: pool-3-thread-12
Ad server #6: pool-3-thread-9
Ad server #7: pool-3-thread-13
Ad server #8: pool-3-thread-5
Ad server #9: pool-3-thread-6
Ad server #10: pool-3-thread-2
The markup is very simple:
Listing:
/parallel.html
<div class="lift:FetchAd?parallel=true"
style="margin: 12px; border: 1px solid blue">
Ad server #1: <span class="ad">The Ad</span>
</div>
That's not a lot of markup code. When you mark the
snippet as parallel, Lift forwards the
snippet calculation to another thread in a pool
of threads. Lift continues to evaluate the markup
on the page in parallel and recombines the results
before the page is sent to the browser.
Let's look at the snippet code:
Listing:
/net/liftweb/seventhings/snippet/FetchAd.scala
/**
* Fetch an ad from an ad server (takes about 1/2 second
*/
object FetchAd {
def render = {
// sleep for 1/2 second
Thread.sleep(500 millis)
// send the result back
".ad" #> Thread.currentThread.getName
}
}
Once again, something that's hard or impossible
in other web frameworks is is trivial in Lift.
How much does this matter? Is your page load time
slow because you're going out to lots and lots of
different back end servers while composing a page?
Lift makes that kind of work parallelizable.