From Amazon's Dynamo by Werner Vogel:
"In Amazon’s decentralized service oriented infrastructure, SLAs play an important role. For example a page request to one of the e-commerce sites typically requires the rendering engine to construct its response by sending requests to over 150 services. "
Unless all 150 service requests are executed sequentially, which is hard to believe, Amazon's page rendering ought to be able to benefit from Erlang's lightweight concurrency -- even more so than Vimagi :)
This makes me think about adding the following return value to ErlyWeb controller function:
{concurrent, [{ewc,...}, {ewc, ...}, {ewc, ...}]}
This would tell ErlyWeb to render each component in a different process. It may not make a big performance difference in rendering simple pages (it might even slow it down a bit), but for some applications (the future Erlmazon? :) ), it could be useful.
What do you think?
9 comments:
I really like the component orientation you have going in ErlyWeb, and adding concurrent component rendering seems like the next logical step, especially if you\'re interfacing with an SOA and are waiting for requests to complete.
Actually thats very interesting Yariv I can see a number of occasions where that would be useful. I have been thinking for a while about going beyond MVC + database web frameworks. In doing so I have had to look at things like Map Reduce and virtual views (Couchdb etc..). Thus a web query may well have many parallel processes on the back end (such as a map reduce cluster).
Thus I think it is a good idea in principle.
PS it's also worth thinking what the implications of using Map/reduce rather than a DB would have on the MVC model. If you took this to it's extreme you could have multiple AJAX requests concurrently building parts of a page, calling concurrent backend processes (separate rather than map reduce type problems).
Regards
Al
PPS. there is something really odd happening with your captcha, this is my 5 try at submitting this comment.
This seems like a really good idea.
Q: Will exceptions be handle-able cleanly?
I have yet to try ErlyWeb but will. Nice work!
What happened to my comments?
@Bimal I guess exceptions will be sent back to the main controller, which will detect them before rendering the page. The potential downside is that when you render multiple components in parallel and one of them encounters an exception, you have to potentially waste cycles rendering the rest because their processes have already spawned. However, since exceptions don't happen normally (that's why they are called "exceptions" :) ), so there's no need to worry about efficiency. As long as we can show the exceptions to the user, we're fine.
@Al I'm struggling with a crappy CAPTCHA plugin selection. I'll try to fix the situation...
...I think the more I read about Erlang and ErlyWeb... the more I get on board. Thanks for your blog. Erlang and ErlyWeb seem to me like they have a bright future.
This would be pretty easy to do using plists, you could basically run through the list with ewc like you already do, but using plists:map instead of lists:map. http://code.google.com/p/plists/
Please do post to the list and announce if you do it, I'd use it.
By the way, plists does handle exceptions pretty well, and can halt the other running processes if one of them fails, so there's less wasted work
That's a good idea. I'll look into using plists.
Post a Comment