Hi,
Are there any plans for an SPDY [1] test on the Wikimedia servers?
I'm currently doing some speed tests on a robot and I found out (not quite to my surprise) that it's much quicker to get whole pages (hundreds at a time) than to ask the API for each page's last edit time. I would love to see how would the results compare when using SPDY.
Have a nice Sunday, Strainu
Since Apache tends to be the main web server people use, in order to make MediaWiki use SPDY, we'd have to work with mod_spdy. Does anybody know how stable this is? *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sat, Oct 27, 2012 at 2:52 PM, Strainu strainu10@gmail.com wrote:
Hi,
Are there any plans for an SPDY [1] test on the Wikimedia servers?
I'm currently doing some speed tests on a robot and I found out (not quite to my surprise) that it's much quicker to get whole pages (hundreds at a time) than to ask the API for each page's last edit time. I would love to see how would the results compare when using SPDY.
Have a nice Sunday, Strainu
[1] http://en.wikipedia.org/wiki/SPDY
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Not to mention varnish/squid.
-Chad On Oct 27, 2012 2:59 PM, "Tyler Romeo" tylerromeo@gmail.com wrote:
Since Apache tends to be the main web server people use, in order to make MediaWiki use SPDY, we'd have to work with mod_spdy. Does anybody know how stable this is? *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sat, Oct 27, 2012 at 2:52 PM, Strainu strainu10@gmail.com wrote:
Hi,
Are there any plans for an SPDY [1] test on the Wikimedia servers?
I'm currently doing some speed tests on a robot and I found out (not quite to my surprise) that it's much quicker to get whole pages (hundreds at a time) than to ask the API for each page's last edit time. I would love to see how would the results compare when using SPDY.
Have a nice Sunday, Strainu
[1] http://en.wikipedia.org/wiki/SPDY
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
We don't even do HTTP/1.1 yet - lack of Transfer-Encoding: Chunked has bit me badly before.
On Sat, Oct 27, 2012 at 12:38 PM, Yuvi Panda yuvipanda@gmail.com wrote:
We don't even do HTTP/1.1 yet - lack of Transfer-Encoding: Chunked has bit me badly before.
Well, nginx didn't support this until fairly recently. We plan on testing this fairly soon. I upgraded one of the ssl boxes yesterday and re-pooled it. Once I'm confident it's not causing any issues I'll upgrade the rest and then we can start testing some of the new features (including http 1.1).
- Ryan
On Oct 28, 2012 1:54 AM, "Ryan Lane" rlane32@gmail.com wrote:
Well, nginx didn't support this until fairly recently. We plan on testing this fairly soon. I upgraded one of the ssl boxes yesterday and re-pooled it. Once I'm confident it's not causing any issues I'll upgrade the rest and then we can start testing some of the new features (including http 1.1).
- Ryan
Wonderful! Thanks for this, Ryan.
27 Октябрь 2012 г. 23:20:39 пользователь Chad (innocentkiller@gmail.com) написал:
Not to mention varnish/squid.
Varnish author on SPDY: http://developers.slashdot.org/story/12/07/13/1327235/varnish-author-suggest...
"The author of Varnish, Poul-Henning Kamp, has written an interesting critique of SPDY and the other draft protocols trying to become HTTP 2.0. He suggests none of the candidates make the cut. Quoting: 'Overall, I find the design approach taken in SPDY deeply flawed. For instance identifying the standardized HTTP headers, by a 4-byte length and textual name, and then applying a deflate compressor to save bandwidth is totally at odds with the job of HTTP routers which need to quickly extract the Host: header in order to route the traffic, preferably without committing extensive resources to each request. ... It is still unclear for me if or how SPDY can be used on TCP port 80 or if it will need a WKS allocation of its own, which would open a ton of issues with firewalling, filtering and proxying during deployment. (This is one of the things which makes it hard to avoid the feeling that SPDY really wants to do away with all the "middle-men") With my security-analyst hat on, I see a lot of DoS potential in the SPDY protocol, many ways in which the client can make the server expend resources, and foresee a lot of complexity in implementing the server side to mitigate and deflect malicious traffic.'
Yeah, I have to agree on this one. I was never a particular fan of SPDY. Yes, HTTP needs a reworking, but only the concepts behind SPDY are good, not its actual implementation. I'd sooner implement some sort of WebSocket interface for MW, such as having the server push load.php resources over a socket, or maybe having an improved edit form that tells your browser when another user edits the page. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sun, Oct 28, 2012 at 2:03 AM, Dmitriy Sintsov questpc@rambler.ru wrote:
27 Октябрь 2012 г. 23:20:39 пользователь Chad (innocentkiller@gmail.com)
написал:
Not to mention varnish/squid.
Varnish author on SPDY:
http://developers.slashdot.**org/story/12/07/13/1327235/** varnish-author-suggests-spdy-**should-be-viewed-as-a-**prototypehttp://developers.slashdot.org/story/12/07/13/1327235/varnish-author-suggests-spdy-should-be-viewed-as-a-prototype
"The author of Varnish, Poul-Henning Kamp, has written an interesting critique of SPDY and the other draft protocols trying to become HTTP 2.0. He suggests none of the candidates make the cut. Quoting: 'Overall, I find the design approach taken in SPDY deeply flawed. For instance identifying the standardized HTTP headers, by a 4-byte length and textual name, and then applying a deflate compressor to save bandwidth is totally at odds with the job of HTTP routers which need to quickly extract the Host: header in order to route the traffic, preferably without committing extensive resources to each request. ... It is still unclear for me if or how SPDY can be used on TCP port 80 or if it will need a WKS allocation of its own, which would open a ton of issues with firewalling, filtering and proxying during deployment. (This is one of the things which makes it hard to avoid the feeling that SPDY really wants to do away with all the "middle-men") With my security-analyst hat on, I see a lot of DoS potential in the SPDY protocol, many ways in which the client can make the server expend resources, and foresee a lot of complexity in implementing the server side to mitigate and deflect malicious traffic.'
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sat, 27 Oct 2012 23:22:04 -0700, Tyler Romeo tylerromeo@gmail.com wrote:
Yeah, I have to agree on this one. I was never a particular fan of SPDY. Yes, HTTP needs a reworking, but only the concepts behind SPDY are good, not its actual implementation. I'd sooner implement some sort of WebSocket interface for MW, such as having the server push load.php resources over a socket, or maybe having an improved edit form that tells your browser when another user edits the page.
Of course this is pretty much impossible with PHP.
Of course this is pretty much impossible with PHP. Of course this is pretty much impossible with PHP.
No it's not. You use PHP's sockets functions, albeit PHP is probably not the most optimal language for setting up a websocket server. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sun, Oct 28, 2012 at 3:13 AM, Daniel Friesen daniel@nadir-seen-fire.comwrote:
On Sat, 27 Oct 2012 23:22:04 -0700, Tyler Romeo tylerromeo@gmail.com wrote:
Yeah, I have to agree on this one. I was never a particular fan of SPDY.
Yes, HTTP needs a reworking, but only the concepts behind SPDY are good, not its actual implementation. I'd sooner implement some sort of WebSocket interface for MW, such as having the server push load.php resources over a socket, or maybe having an improved edit form that tells your browser when another user edits the page.
Of course this is pretty much impossible with PHP.
-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com
On Sun, Oct 28, 2012 at 2:03 AM, Dmitriy Sintsov questpc@rambler.ru wrote:
27 Октябрь 2012 г. 23:20:39 пользователь Chad (innocentkiller@gmail.com )
написал:
Not to mention varnish/squid.
Varnish author on SPDY:
http://developers.slashdot.****org/story/12/07/13/1327235/** varnish-author-suggests-spdy-****should-be-viewed-as-a-****prototype< http://developers.**slashdot.org/story/12/07/13/** 1327235/varnish-author-**suggests-spdy-should-be-**viewed-as-a-prototypehttp://developers.slashdot.org/story/12/07/13/1327235/varnish-author-suggests-spdy-should-be-viewed-as-a-prototype
"The author of Varnish, Poul-Henning Kamp, has written an interesting critique of SPDY and the other draft protocols trying to become HTTP 2.0. He suggests none of the candidates make the cut. Quoting: 'Overall, I find the design approach taken in SPDY deeply flawed. For instance identifying the standardized HTTP headers, by a 4-byte length and textual name, and then applying a deflate compressor to save bandwidth is totally at odds with the job of HTTP routers which need to quickly extract the Host: header in order to route the traffic, preferably without committing extensive resources to each request. ... It is still unclear for me if or how SPDY can be used on TCP port 80 or if it will need a WKS allocation of its own, which would open a ton of issues with firewalling, filtering and proxying during deployment. (This is one of the things which makes it hard to avoid the feeling that SPDY really wants to do away with all the "middle-men") With my security-analyst hat on, I see a lot of DoS potential in the SPDY protocol, many ways in which the client can make the server expend resources, and foresee a lot of complexity in implementing the server side to mitigate and deflect malicious traffic.'
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sat, Oct 27, 2012 at 09:52:34PM +0300, Strainu wrote:
Are there any plans for an SPDY [1] test on the Wikimedia servers?
I'm currently doing some speed tests on a robot and I found out (not quite to my surprise) that it's much quicker to get whole pages (hundreds at a time) than to ask the API for each page's last edit time. I would love to see how would the results compare when using SPDY.
Some of us have talked a few times about SPDY -nothing too formal, no time allocated or work being done- and checked out the options right now. Unfortunately, a proper deployment isn't that simple:
• There aren't many implementations out there, and even less so mature ones. Nginx is a good candidate for us because we already use it for SSL termination, but its SPDY implementation was first release ~2 months ago -- albeit with a large website behind it.
• SPDY is young and is being developed as a living specification; there are already three incompatible versions out there, with SPDY/1 not being used anymore and SPDY/3 being supported by Firefox 15 and Chrome 22 (released just 10 days ago!). Its security hasn't been proven yet either, with an attack on it called CRIME being released a month ago. It's a moving target and this doesn't make things easier.
• To really take advantage of SPDY and connection multiplexing, you need to undo any domain sharding that you might have (which is for HTTP of course a standard/best practice for everyone, incl. us). This is a significant change in our architecture, one that can't be done from one day to the other.
• SPDY as it is right now requires SSL. Our SSL cluster is not scaled up yet and not ready to serve a significant portion (or all) of our traffic. There are various problems in doing so and the solution to some of them are in direct conflict with SPDY.
• Finally, SPDY is a bit controversial right now. A lot of smart people are discussing about HTTP/2.0 on IETF lists and SPDY is a big part of those discussions with various proponents but also oponnents.
For example, It looks like Varnish —that we use a lot and planning to use even more— isn't going to support SPDY natively ever but is instead planning architectural changes to better support HTTP/2.0, when that comes. More on Poul-Henning Kamp's mail¹ and keynote at the recent VUG²; I was there and asked specifically about SPDY and from the answer I got, it doesn't seem likely that Varnish will implement SPDY any time soon.
Now, none of this is to say that we won't try! We need all the help we can get, so if there are interested people around there that are willing to help, Labs is open :) We'll make sure to try and provide all the support you might need!
Regards, Faidon
¹: https://www.varnish-cache.org/docs/trunk/phk/http20.html ²: https://www.varnish-cache.org/vug6/
wikitech-l@lists.wikimedia.org