search

mashupbots / socko

A Scala web server powered by Netty networking and AKKA processing.
Other
255 stars 51 forks source link

SPDY not performing as expected with the StaticContentHandler #74

Closed Bongani closed 10 years ago

Bongani commented 10 years ago

I've been testing Socko with its different connection layers (HTTP, HTTPS and SPDY). I used the benchmarking code provided on the website, all I did was change the connections. I used http://www.webpagetest.org/ to test the latency.

Of course HTTPS had a more an overhead than HTTP because of the connection time. But when I tested SPDY, SPDY had more of an overhead than HTTPS. I found this to be really strange, because earlier on I had an application which just generated a small dynamic webpage and SPDY was shown to be quicker than HTTPS.

What was the difference between these two applications, my application just used a generic actor to serve the content. The only thing I can guess is that somehow the StaticContentHandler is not operating correctly with the SPDY connection. Has anyone else tested the response times of the StaticContentHandler when using SPDY and HTTPS?

Another thing I found strange is that the webpagetest noted that non of my content is being cached and my images were not being compressed (though the images were around 60 KB each). I will try another set of tests were I use larger images.

veebs commented 10 years ago

Hi,

For caching with the static content handler, see configuration http://sockoweb.org/docs/0.3.1/api/#org.mashupbots.socko.handlers.StaticContentHandlerConfig.

The browserCacheTimeoutSeconds property uses the Expires and Cache-Control HTTP headers to control browser side caching. Can you please check if your browser correctly received these headers in the response.

If you images are only 60K, they should also be cached in memory on the server side - hence no reading from hard disk when serving the file.

Compression of HTTP content is dependent on the HTTP request made by the browser. If the browser does not send an Accept-Encoding request header, the compressed content will not be sent.

Hope this helps.

BTW - I've not forgotten about your other issues. My day job has finally slowed down for Christmas. You'll see some commits soon. I'm 1/2 way through it. Sorry it has taken soooo long.

Bongani commented 10 years ago

Hi @veebs ,

It seems caching was being done. I just discovered that WebPagetest judges a good cached site if the expiry date is more than 30 days. So that was my mistake.

But despite me playing around with the configuration file, a SPDY connection still seems to exhibit a higher latency than a standard HTTPS connection. Would you happen to know why this is happening?

Also, thanks for the work you are putting into this project.

Bongani commented 10 years ago

I've tried different variations of the StaticContentHandler (i.e. changing the type of dispatcher used) but still SPDY seems to be performing the same as with a HTTPS connection. Excuse the multiple posts, it is kind of urgent for me to figure this out as I'm planning a live demo early January.

As I pointed out in my first post, SPDY seems to perform as expected when I'm not using the StaticContentHandler. That is, I'm just servicing normal content for an actor. But it is difficult to get a proper time difference with the method I used, were as using the StaticContentHandler I can serve an html page which contains several items that have to be fetched as well.

veebs commented 10 years ago

Just trying to understand your issues with SPDY.

Can you please explain in detail the tests that you ran to compare SPDY with HTTPS and the results you got.

Thanks

Bongani commented 10 years ago

Hi @veebs,

My issue is that SPDY is not showing the performance I was expecting i.e. loading a webpage faster. The tests where performed using webpagetest. I used the socko benchmark app to load up a website with several pictures. On each run I tested a different type of connection: HTTP, HTTPS and SPDY. SPDY shows the same wbe page load time as HTTPS. Here is a link to each result:

HTTP: http://www.webpagetest.org/result/131221_NP_759/ HTTPS: http://www.webpagetest.org/result/131221_GQ_76Z/ SPDY: http://www.webpagetest.org/result/131221_FD_79F/

veebs commented 10 years ago

I'm not too sure of the reasons but I've just committed an update that will support SPDY 3 and 3.1. Maybe these are faster.

I'll need to write more test cases before I can release it.

veebs commented 10 years ago

One possible explanation is that v0.3 only supports SPDY2 so I may have reverted to HTTPS. v0.4 will supports SPDY3.

Bongani commented 10 years ago

@veebs I've been doing further tests and I actually found out that there was a bottleneck on my ISP network. Once I changed ISP everything worked well. Sorry for the inconvenience.

veebs commented 10 years ago

@Bongani no problems. glad it all worked out.