In the amazon cloud it is possible to run several servers to load balance and to scale on demand.
- Gergely 2011/9/24, Adam Chlipala <[email protected]>: > austin seipp wrote: >> The Ur/Web runtime system represents asynchronous channels for message >> passing between clients with an ID that is generated by the when a new >> channel is allocated, and uses this for example when you insert a >> 'channel' into the database. Would it be possible to move this channel >> generation into the database itself, perhaps with a sequence or >> something similar? >> > > Moving name generation into the database is easy, but there is other > important state. Fundamentally, we must manage TCP connections by > clients, which sounds scary to do with SQL. Each channel has a buffer, > and there is locking to manage proper use of the buffers. All this is > done now with shared memory on a single host. > > I have contemplated supporting application distribution by changing > [client] and [channel] representations to store server IDs as well, so > that each server can easily manage its own name supply. It would be a > run-time error to access a channel associated with a different server. > The Ur/Web runtime could be modified to set a cookie that a load > balancer or proxy could use to detect requests to the appropriate > servers, where the needed channels live. The feasibility of this idea > is based on the assumption that it's easy to group mutually > communicating clients into cohorts that fit on single servers. (Note > that "client" here refers to a single page view, not a single browsing > session, making the problem easier.) > > > HOWEVER... I'm wondering whether it really is important to support > application distribution. I can understand having back-up servers that > you switch to if the primary server encounters a problem. That model is > already supported very well with Ur/Web. You can use hot-swap support > in the DBMS, and the only remaining server-side state is the clients and > channels, which aren't especially persistent anyway. If all Comet > interaction is reset on the occasional server failure, that doesn't seem > so awful to me. Again, here we are only talking about failures of a > single primary server, so we don't have the usual problem of "rare > failure + many servers = frequent failure." > > I know it's in vogue today to care about having many servers in > production at once, serving the same application. Still, I'm deeply > skeptical that this capability matters for more than a handful of web > applications that have ever existed. I lean towards using a single very > powerful server, with reasonable performance for shared memory across cores. > > I'm very interested in arguments to support the claim that it is common > for web applications to be deployed best in ways that have multiple > servers running application logic simultaneously. > > _______________________________________________ > Ur mailing list > [email protected] > http://www.impredicative.com/cgi-bin/mailman/listinfo/ur > -- Mobilkészülékről küldve _______________________________________________ Ur mailing list [email protected] http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
