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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
