[Design] [cosmo] Server Restraints and the Dashboard

[Jeremy Epstein]

Hey Jared
Your absolutely right on this one. I expect, given what little Matthew 
and I talked about dash, that the server fetch impact will represent a 
bigger issue.

BTW is the 15 minute expectation based on existing usage?  From what 
I've seen in the past, ajax apps tend to be a lot chattier ( ~1-5 minute 
between requests depending on the app) Alot of it depends on how 
frequently a user "scans" ahead of behind in the calendar. 


Jared Rhine wrote:
> Mimi Yin wrote:
>> <Jared, please scroll down to see a question for you.>
>
> (Whoah, I thought I sent this out earlier, but I just found it in my 
> drafts folder; sorry for the delay in response.)
>
>> Again, I think we need some numbers for Preview. How many 
>> simultaneous requests do we expect in the Preview timeframe? Jared?
>
> We're expecting about 40 transactional requests per second at maximum 
> capacity.  But by itself, that metrics is pretty meaningless; the 
> relevant issue is the complexity of each request times the frequency 
> of those request.
>
> The most expensive operations we have right now are "webcal GET", say
> for iCal and Google Calendar users (roughly 6 seconds each on a loaded
> server), and "Atom/RSS GET" (for feeds) but the kicker is those happen 
> frequently (every 15 minutes for iCal, unknown for Google Calendar).  
> We could easily find after Preview that these operations dominate the 
> server.
>
> I get nervous if an operation (or sequence of operations) takes more
> than say 750-1500 ms (0.75-1.5 sec) and happens more than say 10 times 
> per person per day.  Too many of these expensive operations load the 
> server and make the web UI slow because the server itself is slow.
>
> I hear performance discussed in this thread, but it's critically 
> important (to me), to realize that "performance" is shared.  It's very 
> possible, given our centralized server architecture, for one user 
> doing an expensive operation to affect thousands of users just going 
> about their daily business.
>
> Since we consciously decided to defer our server-side ability to scale 
> (that is, add resources to add capacity) in the interests of 
> supporting more features by Preview, feature decisions must be made so 
> that they are lightweight against our centralized server.
>
> A good solution, from a service perspective, will make a relatively 
> few number of HTTP requests, and each will be pretty fast to complete. 
> Operations that take "seconds" to complete will be a sign of there 
> being an unacceptable performance problem.
>
> -- Jared
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
>
>