| |||||||||||||
Server side impact of SPDYServer side impact of SPDYPosted Nov 20, 2009 12:16 UTC (Fri) by zmi (guest, #4829)Parent article: Reducing HTTP latency with SPDY
What I'm missing from the article is the server side view. Will it improve server throughput as well? If you have a server that manages 1000 requests/s now, will that be more, less, or equal with SPDY?
Will CPU usage of the server increase dramatically because of compression?
Also, for efficient push methods, the client would have to fill it's cache with server push. That would be a great benefit for sites with many pictures: Initially the first page with all pix is sent, and while the browser displays that page and the user searches for the next link to click, the server could push content in the background. So when the users clicks on the next page, the browser already has most pictures (or other content) and just needs the HTTP page data, resulting in much better browser experience. But there would need to be a server-wide control over that feature, because 200 simultaneous "background pushes" could grind the server to a halt. Could be really nice if used correctly, though.
(Log in to post comments)
Server side impact of SPDY Posted Nov 26, 2009 8:21 UTC (Thu) by jengelh (subscriber, #33263) [Link]
I see what you did there. X-Associated-Content being used as a server push for ads. No thanks.
Server side impact of SPDY Posted Nov 26, 2009 8:58 UTC (Thu) by zmi (guest, #4829) [Link]
Hm, I didn't think about ads. That could really be a problem. I use Adblock Plus and NoScript plugins in Firefox, so I don't see a lot of these, and I'm sure they could also help to filter unwanted push.
So the protocol should allow the client to filter the push list *before* it's actually sent. A simple handshake would help:
server: I want to send x.html, ad.html, pic.jpg, ad.swf
And so the filter works before the push. After all, we want things faster, so filtering things the client won't see anyway before it's pushed seems necessary.
|
|||||||||||||