Unrelated to original question. how do you guys cache static data in browser. I am talking about static data which changes say once every month for example monthly discount item. (I am not talking abt images, js, css etc.) Our solution is bit complicated and I am sure there are easier solutions/patterns
On Jul 16, 10:53 am, David Vree <[email protected]> wrote: > 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 -- 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.
