On Aug 1, 2012 6:47 AM, "Jitu Padhye" <padhye@microsoft.com> wrote: > We have done a bit of work on looking at how SPDY works for apps (mostly simple trace analysis), but we don’t have anything significant to report yet. But this is indeed something that needs looking into. The use case where SPDY should offer an advantage is when many requests are in transit concurrently and there is significant variability in response times. Responsiveness of both http and SPDY will depend on the protocol stack's ability to keep the TCP buffer full of messages, and the real test cases might be between proxies at the edges of data centres or on other high volume links. I have had success with pipelined http as part of SCADA user interfaces. In this use case we want to bring up a display containing ten thousand individual data points that each have individual urls. With ordinary pipelined http/1.1 and a good http implementation I can complete the initial GET requests plus establish subscriptions and perform all rendering within a couple of seconds on commodity hardware. In this case response times are very consistent so server push aside SPDY should not offer significant raw performance improvement. For workloads with variable response times I use draft- mogul- http- ooo- 00, which works very well when supported consistently across the architecture. I wonder a little as to whether browser protocol stacks will be appropriately tuned for high message loads to provide good baseline http figures. A fairer comparison might be obtained by essentially dumping bytes across the network and comparing on that basis. Alternatively SPDY should be compared not to http but instead to existing enterprise message queuing protocols. In fact when it comes down to it if we're defining a new http primarily for the purposes of improving performance then existing http isn't really a good baseline. Instead we should probably be looking at the best performing available protocols and comparing against those as baselines. It's potentially very easy to be faster. The question is have we achieved "fast" such that it would be pointless for anyone to build and use custom protocols in place of http for transporting http message content except in extreme cases? I think enterprise experience as to what constitutes "fast" or "fast enough" and what constitutes an ordinary workload should be considered. Benjamin
Received on Wednesday, 1 August 2012 01:43:05 UTC