A great book to read on the subject is "Scalable Internet Architectures". It shows why "common sense" applied to scalability is almost always wrong.
A coarse grained conversation will decrease the number of calls, but will increase the load per call. So there may be some small gain in scalability, but not much. There will be a gain in client performance potentially. The way to increase scalability is to ensure statelessness so you can cluster, reduce calls to the database, push static content out to specialized servers, replicate the database backend when possible, use better/different switches/routers/web servers, etc., etc., etc. IMO -- Dave On Jul 16, 12:37 pm, mk <[email protected]> wrote: > IMHO, if our design to reduce network calls, facilitates our servers > to handle growing amount of work gracefully. Than are not we improving > scalability ?. > > For example if max server load = # of requests * load per request * > CONSTANT = 1000 > Before optimication with chatty software it is (1000 requests * 1 load > per request *CONSTANT) = 1000 > After optimization with reduced network calls it is ( 500 requests * > 1.5 load per request * CONSTANT) = 750. Thus now server is available > to handle more requests. > > But above is only possible if client had enough bandwidth to receive > coarse grained data ( so that client's inital page load is not too > slow. BTW: if applicable we will have background threads to load data > in browser for upcoming screens) > > Plz correct me if above is wrong. > > BTW: web servers in cloud are idlely located with fiber channel in > tier-1 network. (so not much of issue of bandwidth at server). > And I wish we have all the data before we start software development > but currently we just have to make wise ( or stupid) guesses > > On Jul 16, 8:00 am, David Vree <[email protected]> wrote: > > > Scalability is a function of many things such as statelessness, > > clustering, latency, connection pooling, etc. the list goes on and on. > > > But scalability is NOT a function of network throughput on the client > > side....server side yes, but not client side. > > > I think the requirement you are trying to meet is performance...how > > fast the app will respond to users over a broadband connection. > > > In this case, I think your assumption of 1Mbs is a reasonable one...I > > base this on years of personal experience, but no hard data > > collection. > > > But again, this is about performance, not scalability. > > > On Jul 15, 11:21 pm, mk <[email protected]> wrote: > > > > the requirement we are trying to meet is scalability... > > > > To get scalability in our app we have to reduce network calls by each > > > user.- Hide quoted text - > > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
