views:

1437

answers:

4
+4  A: 

If you look at your times http has bigger waiting time and smaller receiving time. https on the other hand has smaller waiting time and bigger receiving time. I would interpret this as the http port on the shared hosting server is more busy, thus a request stays longer in the queue until is accepted by the server. Once accepted, the requests is transferred faster than https. On the https port there is less traffic on the server so the request is serviced faster but takes longer to transfer.

For any https vs. http comparison you'll have to take into account the bigger time to handshake each request for https compared with http. You should see worsening when doing many small requests.

Remus Rusanu
Thanks for the info. It makes sense.I'll do the benchmark on a 1x1 pixel gif and get back to you on the times.
David Murdoch
You also need to take into accoun that SSL handshake is shortened when the same client reconnects (see http://en.wikipedia.org/wiki/Transport_Layer_Security#Resumed_TLS_handshake) so to give an accurate picture you'd need to test from across a variety of client processes and machines.
Remus Rusanu
+1  A: 

https works as follows: First a 4-way handshake is performed (at least if i remember correctly it was 4way), here client and server agree on the symmetric encryption algorithm used later on and exchange certificates (containing public keys).

They exchange a session (key for the symmetric enc later) using publickey crypto.

Now they send messages encrypted with the session key and some encryption algorithm (3des, aes, rc4, rc5, etc). Since symmetric encryptions are not that expensive operations the differences in download time are not that big.

The fact that you have less waiting time is because you probably have less traffic on http port or less traffic at the time you did the https request compared to the http requests.

So to optimize performance you should use as few https connections as possible since the handshake is a relative expensive procedure.

Henri
+6  A: 

You may also want to take into account that HTTPS documents will almost never be cached anywhere except the users browser, so you might find that while there's little difference to an individual user, an HTTP document can be significantly quicker for large numbers of people sharing a cache. (It's still quite common in some places for ISPs to put their customers through a shared proxy cache)

If it's something that you don't mind users sharing, of course.

Colin Coghill
+1 An *extremely* good point. If HTTPS is used, a large proportion of the requests will hit the website's origin web server(s) and make the site much less scalable. With HTTP, the intermediate caches will take up a substantial amount of the load and the website will scale a lot better.
Jim Ferrans
Even if the HTTP Header's Cache-Control is set to "public" with a far future expires header?e.g.Cache-Control: public, max-age=2677884Expires: Sat, 24 Oct 2009 20:50:14 GMT
David Murdoch
@David: HTTPS is HTTP tunneled through an encrypted SSL/TLS tunnel. Any HTTP attribute (like headers) are *invisible* to intermediates, since they cannot poke inside the encrypted SSL tunnel.
Remus Rusanu
A: 

Are you accessing your site through a proxy? If so, you may be seeing better performance because the proxy is being bypassed or reduced to just using handling the initial CONNECT requests.

A proxy could be checking and caching content when you use HTTP - leading to reduced performance.

HttpWatchSupport