[Lift] Running parallel site load balanced
I was tasked with designing a new web-based application that has the requirement of being able to run on multiple servers that could be 1) Load balanced without requiring sticky sessions and 2) Single nodes could be transparently shutdown or added without the users noticing I would like to use Lift if possible, but I'm a bit worried about it's state-full nature. Is it possible to use something like Cassandra or Memcached to hold the session data and have Lift grab that from a cookie instead of storing it all internally in memory? I've looked around, but I have not found any good articles about how to scale Lift horizontally. Thanks in advance John -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Running parallel site load balanced
On Mon, Mar 1, 2010 at 12:29 PM, John Pletka jple...@abraxis.com wrote: I was tasked with designing a new web-based application that has the requirement of being able to run on multiple servers that could be 1) Load balanced without requiring sticky sessions and 2) Single nodes could be transparently shutdown or added without the users noticing I would like to use Lift if possible, but I'm a bit worried about it's state-full nature. Is it possible to use something like Cassandra or Memcached to hold the session data and have Lift grab that from a cookie instead of storing it all internally in memory? I've looked around, but I have not found any good articles about how to scale Lift horizontally. The short answer is that Lift is stateful and you can't shovel Lift state into a backing store. You could use Terracotta to create a cluster of Lift machines, but you're still going to be a lot better off routing requests back to the same machine to avoid shuffling a lot of state around (which is expensive any way you slice it) If you could tell us more about your app, there might be other ways to skin your cat. http://icanhascheezburger.com/2007/08/08/i-has-minions/ Thanks, David Thanks in advance John -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Running parallel site load balanced
John Pletka jple...@abraxis.com writes: I was tasked with designing a new web-based application that has the requirement of being able to run on multiple servers that could be 1) Load balanced without requiring sticky sessions and 2) Single nodes could be transparently shutdown or added without the users noticing I would like to use Lift if possible, but I'm a bit worried about it's state-full nature. Is it possible to use something like Cassandra or Memcached to hold the session data and have Lift grab that from a cookie instead of storing it all internally in memory? Short version: No. Longer version: It's not currently possible and probably hard (but not impossible) to do. But I think (but this is pure speculation) that a Lift session is rather heavy since it contains closures for all the callbacks that have been active within the last 10(?) minutes, the overhead of serializing the session state for each request (which you need for HA) would be substantial. I've looked around, but I have not found any good articles about how to scale Lift horizontally. Probably because it has not been done (without sticky sessions) /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Running parallel site load balanced
It is a business application - lots of forms, reports, data lookups. I'm not too concerned about the performance on a single node - at any given time we'll probably have a max of 1000 requests a minute coming in which I've seen Lift handle easily. The biggest problem is we need near 100% up-time. That means having at least a second server in hot-standby mode (preferably parallel production), and some way to do upgrades without bringing the whole site offline. On Mon, Mar 1, 2010 at 3:48 PM, David Pollak feeder.of.the.be...@gmail.comwrote: On Mon, Mar 1, 2010 at 12:29 PM, John Pletka jple...@abraxis.com wrote: I was tasked with designing a new web-based application that has the requirement of being able to run on multiple servers that could be 1) Load balanced without requiring sticky sessions and 2) Single nodes could be transparently shutdown or added without the users noticing I would like to use Lift if possible, but I'm a bit worried about it's state-full nature. Is it possible to use something like Cassandra or Memcached to hold the session data and have Lift grab that from a cookie instead of storing it all internally in memory? I've looked around, but I have not found any good articles about how to scale Lift horizontally. The short answer is that Lift is stateful and you can't shovel Lift state into a backing store. You could use Terracotta to create a cluster of Lift machines, but you're still going to be a lot better off routing requests back to the same machine to avoid shuffling a lot of state around (which is expensive any way you slice it) If you could tell us more about your app, there might be other ways to skin your cat. http://icanhascheezburger.com/2007/08/08/i-has-minions/ Thanks, David Thanks in advance John -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Running parallel site load balanced
Ahh just saw David beat me to it with the other reply :-) John Pletka jple...@abraxis.com writes: It is a business application - lots of forms, reports, data lookups. I'm not too concerned about the performance on a single node - at any given time we'll probably have a max of 1000 requests a minute coming in which I've seen Lift handle easily. The biggest problem is we need near 100% up-time. But you can have near 100% uptime with sticky sessions. What you can't have is High Availability (HA), ie. users won't notice when a server breaks. That means having at least a second server in hot-standby mode (preferably parallel production), and some way to do upgrades without bringing the whole site offline. Doing rolling upgrades is never easy, even if you don't share state. You may have all this figured, but you need to account for different app versions running simultaneously, expanding/shrinking db upgrades etc. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Running parallel site load balanced
On Mon, Mar 1, 2010 at 1:19 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote: Ahh just saw David beat me to it with the other reply :-) John Pletka jple...@abraxis.com writes: It is a business application - lots of forms, reports, data lookups. I'm not too concerned about the performance on a single node - at any given time we'll probably have a max of 1000 requests a minute coming in which I've seen Lift handle easily. The biggest problem is we need near 100% up-time. But you can have near 100% uptime with sticky sessions. What you can't have is High Availability (HA), ie. users won't notice when a server breaks. There are 3 scenarios: 1. Unplanned fail-over. Having a hot standby and extended login session (See ProtoExtendedSession). The user would lose a stateful multi-page wizard and would lose input to the particular screen they were on. It would appear as a glitch... not optimal, but not end of the world. 2. Planned transfer. You could shuffle all new sessions off to the new machine and let the old sessions age on the old server. With a little extra work, you could demark when a user was done with a logic task (e.g., going back to the home page) and use that as the trigger to move the session to the new machine. 3. Upgrade that breaks the DB schema. You're going to have downtime. No way around it. That means having at least a second server in hot-standby mode (preferably parallel production), and some way to do upgrades without bringing the whole site offline. Doing rolling upgrades is never easy, even if you don't share state. You may have all this figured, but you need to account for different app versions running simultaneously, expanding/shrinking db upgrades etc. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Running parallel site load balanced
The ProtoExtendedSession looks like it might match what I'm looking for. With that, they won't have to re-login, right? We're trying to avoid multi-page state-full workflows so that is not a problem. Are you saying if they have a form up, then submit it (say to update a record), that will fail? Will it generate an error that could be caught and nicely handled by the app? On a related note, any recommendations about a open-source loadbalancer that would allow you to take a server offline for new connections, but still allow the old connections to flow through? On Mon, Mar 1, 2010 at 5:39 PM, David Pollak feeder.of.the.be...@gmail.comwrote: On Mon, Mar 1, 2010 at 1:19 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote: Ahh just saw David beat me to it with the other reply :-) John Pletka jple...@abraxis.com writes: It is a business application - lots of forms, reports, data lookups. I'm not too concerned about the performance on a single node - at any given time we'll probably have a max of 1000 requests a minute coming in which I've seen Lift handle easily. The biggest problem is we need near 100% up-time. But you can have near 100% uptime with sticky sessions. What you can't have is High Availability (HA), ie. users won't notice when a server breaks. There are 3 scenarios: 1. Unplanned fail-over. Having a hot standby and extended login session (See ProtoExtendedSession). The user would lose a stateful multi-page wizard and would lose input to the particular screen they were on. It would appear as a glitch... not optimal, but not end of the world. 2. Planned transfer. You could shuffle all new sessions off to the new machine and let the old sessions age on the old server. With a little extra work, you could demark when a user was done with a logic task (e.g., going back to the home page) and use that as the trigger to move the session to the new machine. 3. Upgrade that breaks the DB schema. You're going to have downtime. No way around it. That means having at least a second server in hot-standby mode (preferably parallel production), and some way to do upgrades without bringing the whole site offline. Doing rolling upgrades is never easy, even if you don't share state. You may have all this figured, but you need to account for different app versions running simultaneously, expanding/shrinking db upgrades etc. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Running parallel site load balanced
When you bind a form, you write functions that handle parts of the form. They are stored in memory and when the form is submitted they are executed. They are triggered by assigning them a unique id and using it as the form element's name. There's no way to preserve the functions to survive a restart. So it may be a good idea to warn users in advance about maintenance and that form data won't be submitted if the page is loaded before and submitted after. It would be a nice feature if Lift could somehow detect query params that look like they are bound to functions but are not actually, and give the app a chance to notify the user that the form was not submitted, if such a thing is possible. - John Pletkajple...@abraxis.com wrote: The ProtoExtendedSession looks like it might match what I'm looking for. With that, they won't have to re-login, right? We're trying to avoid multi-page state-full workflows so that is not a problem. Are you saying if they have a form up, then submit it (say to update a record), that will fail? Will it generate an error that could be caught and nicely handled by the app? On a related note, any recommendations about a open-source loadbalancer that would allow you to take a server offline for new connections, but still allow the old connections to flow through? On Mon, Mar 1, 2010 at 5:39 PM, David Pollak feeder.of.the.be...@gmail.comwrote: On Mon, Mar 1, 2010 at 1:19 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote: Ahh just saw David beat me to it with the other reply :-) John Pletka jple...@abraxis.com writes: It is a business application - lots of forms, reports, data lookups. I'm not too concerned about the performance on a single node - at any given time we'll probably have a max of 1000 requests a minute coming in which I've seen Lift handle easily. The biggest problem is we need near 100% up-time. But you can have near 100% uptime with sticky sessions. What you can't have is High Availability (HA), ie. users won't notice when a server breaks. There are 3 scenarios: 1. Unplanned fail-over. Having a hot standby and extended login session (See ProtoExtendedSession). The user would lose a stateful multi-page wizard and would lose input to the particular screen they were on. It would appear as a glitch... not optimal, but not end of the world. 2. Planned transfer. You could shuffle all new sessions off to the new machine and let the old sessions age on the old server. With a little extra work, you could demark when a user was done with a logic task (e.g., going back to the home page) and use that as the trigger to move the session to the new machine. 3. Upgrade that breaks the DB schema. You're going to have downtime. No way around it. That means having at least a second server in hot-standby mode (preferably parallel production), and some way to do upgrades without bringing the whole site offline. Doing rolling upgrades is never easy, even if you don't share state. You may have all this figured, but you need to account for different app versions running simultaneously, expanding/shrinking db upgrades etc. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
