Hello Chris Thank you so much for the feed-back. It is a very useful insight, and much appreciated!
Kind regards Harry Mantheakis London, UK > Harry, >>> Option 1 is unacceptable -- the overhead of having all of these connections >>> encrypted is not a viable option. >> >> What are the 'overheads' in using SSL? How much harder does the server have >> to work, and - in practice - what sort of performance impact does this have? > > I don't have any numbers, but... > > SSL is encrypted, so the decryption has to take place on the server to > make sense of the data. There's also the key negotiation that takes > place at the beginnign of the SSL session. This load is pretty hard on > the machine. > > Lots of apps have installed SSL acceleration boards into their servers > to speed things up -- the h/w is faster than the software. Other use > huge servers as proxies that decrypt everything so that the app servers > don't have to do the work. (The data is not encrypted near the servers, > but this is generally behind a firewall, anyway). > > I've seen performance numbers with SSL on and off, and the difference is > suprising. I think we were using some type of Sun boxes (can't remember > what type) and I think all of them had SSL accelerators in them. They > were dedicateed web servers and did the SSL on behalf of the app > servers. For even simple pages (actually, the time difference gets worse > with simple, static content), the response times were doubled or worse. > > There's another effect with HTTPS that's unfortunate, which is that most > browsers will not cache anything that comes down over SSL (including > images!), which means that everything on your page will get re-loaded > every time you show it (even images). That sucks because you now have > estra requests to the server, and they all take longer. :( > > -chris --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
