[Design] [cosmo] Server Restraints and the Dashboard

[Jared Rhine]

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