Child pages
  • Using SPDY instead of HTTP to increase page load drasticly
Skip to end of metadata
Go to start of metadata

Imported From: http://groups.google.com/group/in-portal-dev/browse_thread/thread/a88d59907855c991#

To show website at requested url to a user web browser (e.g. Google Chrome) makes HTTP request to a web server (e.g. Apache) and that's all in general. Version of HTTP protocol that is currently in use is HTTP 1.1, which was developed 13 years ago. Much has changed on the internet, but not this protocol. Today it only slows down loading times of modern websites.

Version HTTP 2.0 being developed right now, which will use ideas suggested by Google and Microsoft. While it's not ready let's focus on what is ready - SPDY protocol. This protocol is an alternative to HTTP that most interesting features are:

  • Next Protocol Negotiation (NPN)
  • Framing and header compression
  • Stream multiplexing
  • Server push

Interesting facts:

Want to know if website is using SPDY or not? Just install this extension into Google Chrome.

6 Comments

  1. Hi Alex,

    Very interesting - thanks for finding and sharing.

    Question 1 - what's faster / better / earlier to setup and use - NGINX or
    SPDY? Considering you mentioned SPDY speeds up the Static files same as
    NGINX.

    Question 2 - PHP won't be working by default as we have it configured now
    (as apache module) and has to be reconfigured as Fast-CGI script - what are
    implications of this - for server with many websites? for server with just
    a few websites?

    DA

  2. *Question 1 - what's faster / better / earlier to setup and use - NGINX or
    SPDY? Considering you mentioned SPDY speeds up the Static files same as
    NGINX. *

    There is module for Nginx as well. We don't need to switch. Since it's a
    still relatively new protocol then some problems might be happening.

    *Question 2 - PHP won't be working by default as we have it configured now
    (as apache module) and has to be reconfigured as Fast-CGI script - what are
    implications of this - for server with many websites? for server with just
    a few websites?*

    I'm no system administrator to know such details, but I bet google can shed
    some light on it. Besides php as FastCGI is connected to Nginx. If there
    were some problems there, then same problems might be on Apache as well.

  3. I've found interesting article in Russian on the Internet about FastCGI and
    PHP: http://dklab.ru/chicken/nablas/49.html

  4. Very insteresting Article Alex - thank you!

    I believe we should research on this in more details and do some test cases.

    Also, as you noticed there is something we have overlooked in eAccelerator
    before - *control.php *file.

    At this point, do we create a task or just run some concepts on the side?
    The implementation obvoiusly should be included in In-Portal 5.3.x

    DA

  5. Thanks Valentin - very interesting article that shads some light on this
    technology.

    I guess we won't hurry with this for now.

    DA