Lift & requests

[DonCorsean]

I'm trying to convince some folks at my company to use Lift for some projects. There is a concern from others on the team that lift is a blocking/synchronous when it comes to requests. I don't believe this to be the case, but thought someone here may be able to elaborate and explain in better detail how lift handles requests.

[Diego Medina]

I think that the blocking/synchronous theme is taken too far in many cases, it is not that an async way to handle things will make your app super fast, because if your database takes 2 minutes to give you your data, the user will end up having to wait that long to "see" what he/she is looking for. It doesn't help any app to have 100k requests waiting on your db/file system/etc.

That being said, if you have a snippet that takes longer than what you want your users to wait to see "part" of the page, you have a few options:

load snippets lazily:

http://seventhings.liftweb.net/lazy

run snippets in parallel:

http://seventhings.liftweb.net/parallel

use comet and ajax to update the page

http://seventhings.liftweb.net/comet

and if you are doing rest apis, use continuation /  RestContinuation

http://demo.liftweb.net/async_rest

I would say Lift is pretty async if you want it to :)

If you need more details/help , just post again

Thanks

Diego

On Fri, Apr 4, 2014 at 4:38 PM, DonCorsean <donco...@gmail.com> wrote:

I'm trying to convince some folks at my company to use Lift for some projects. There is a concern from others on the team that lift is a blocking/synchronous when it comes to requests. I don't believe this to be the case, but thought someone here may be able to elaborate and explain in better detail how lift handles requests.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala consultant
di...@fmpwizard.com
http://fmpwizard.telegr.am

[Antonio Salazar Cardozo]

It would be helpful to know what you are trying to compare to. As Diego pointed out, Lift gives you a

range of options for dealing with requests, including ways that yield the request thread for reuse, but

the assertion that async IO will magically make your application fast at no cost is usually cargo culting

rather than reality. Use cases matter.

Thanks,

Antonio

[ti com]

I think the advantage of async design is that it uses less threads so more throughput no?

--

[Antonio Salazar Cardozo]

That's the best-case advantage of async design, assuming that you're finding yourself blocked by enough

synchronous IO that it's a problem. It's a solution to a particular problem, and it's better to be sure you

have the problem before you deal with the complications that it brings.

Thanks,

Antonio

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

[ti com]

I mean if you don't have io. Because more threads means more context switching no?

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.

[Antonio Salazar Cardozo]

If you don't have IO, then you probably gain little benefit from async. Async is about yielding the thread

to other potential users when there is a blocking operation that you can wait for more data on. This is

typically (though not always) in IO situations. The lack of threads in Node.js is arguably a limitation, not

a feature (and mitigated by WebWorkers, I believe), and has little to do with async—it simply means that

you have to use multiple processes to scale out when you have CPU-intensive work.

The key aspect of async is yielding when you can't do anything. Usually not doing anything involves IO.

If you have no points where you can't do anything, or few enough of them, then async doesn't help you

in increasing concurrency, and threads will help you as much as they ever would.

Context switching is bad, but async also requires context switching—if the current activity yields to wait

for more IO and another activity is invoked, you still have to tear down the current activity's stack and

set up that of the other activity. What you do save is the fact that you can run out of threads, whereas

async stuff runs on the same thread (there can also be multiple threads running multiple async things,

of course), so it doesn't expose threading limitations. But you can get into the same contention issues

where something is monopolizing the thread because it's CPU-bound instead of IO bound and the other

async things that would be scheduled on the thread won't run as a result.

In short, more threads doesn't mean more context switching (compared to async), depending on the

use case. Moreover, most of async's advantage comes in things that don't require work in your

application but do require waiting—typically IO. In multi-threaded contexts, you can also use async

when you need results from another thread that's doing work, but your thread doesn't need to do

anything in the meantime. Lift supports this kind of interaction using RestHelper.async, comet, etc.

Thanks,

Antonio