<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1106" name=GENERATOR></HEAD>
<BODY
style="MARGIN-TOP: 2px; FONT: 10pt Tahoma; MARGIN-LEFT: 2px"><BR><BR>>>>
A.M.Bell@durham.ac.uk 12/02/02 10:28AM >>><BR><BR><BR>-----Original
Message-----<BR>From: Joe Acquisto [<A
href="mailto:ACQUISTJ@lan.newpaltz.edu]">mailto:ACQUISTJ@lan.newpaltz.edu]</A><BR>Sent:
02 December 2002 16:23<BR>To: novell@netlab1.usu.edu<BR>Subject: RE: SSL
speedup<BR><BR><BR>>> >Joe,<BR>>> ><BR>>> >the first
hand shake between the client and the server is the most<BR>>>
time<BR>>> >consuming activity and where you might notice a
significant<BR>increase<BR>>> in<BR>>> >CPU-load on the
server.<BR>>> >After the keys have been established the continued
session does not<BR><BR>>> >load the<BR>>> >server as much as
initially.<BR>>> >Although all traffic is encrypted I fail to see the
increase in<BR>the<BR>>> actual<BR>>> >data being transmitted,
apart from a few extra packets with<BR>>> SSL-session<BR>>>
>information.<BR>>> ><BR>>> >Still, the above could be a
source that you want to check out. On<BR>>> dial-up<BR>>> >the
extra information required could have a greater impact than
<BR>>being<BR>>> >suspected.<BR>>> ><BR>>> >To
solve the huge impact on the CPU-load there are many Cache and<BR>>>
>SSL-accelerators out there that does the job just nicely
(Volera<BR>and<BR>>> MS <BR>>> >ISA<BR>>> >to mention a
few). There is even a add-on card from Compaq (HP) <BR>>that <BR>>>
>does<BR>>> >the job.<BR>>> ><BR>>>
>Regards,<BR>>> ><BR>>> >/Allan<BR>>>
><BR>>> <BR>>> Thanks, the info is appreciated.<BR>>>
<BR>>> I'm not at all sure, at this point, where the slow down is
occuring.<BR><BR>>> What needs to be done is setup dial in access from a
location near<BR>the<BR>>> server, so I can watch what is happening, and
not just <BR>>> conjecture about<BR>>> it.<BR>>> <BR>>>
Don't think it is a CPU load thing, as local access (LAN) is quite<BR>>>
acceptable.<BR>>> <BR>>> While I don't yet have an answer, other
factors are suspect, such<BR>as<BR>>> browser version, PC RAM, CPU
type and speed, etc. These <BR>>> are potential<BR>>>
bottle necks I had not considered.<BR>>> <BR>>> "Blaming" SSL was
the easy route. <BR>>> <BR>>> joea/<BR>><BR>>Could it be that
once the data is encrypted then the compression <BR>>techniques<BR>>used
by the modem don't work well as the data is of a more random <BR>>nature.
<BR><BR>An interesting thought. <BR><BR>But, mmm, can something be "more
random" than something that might<BR>already be
"random"?<BR><BR>joea<BR>_______________________________________________<BR>Novell
mailing list<BR>Novell@netlab1.usu.edu<BR><A
href="http://netlab1.usu.edu/mailman/listinfo/novell">http://netlab1.usu.edu/mailman/listinfo/novell</A><BR><A
href="http://netlab1.usu.edu/novell/listinfo">http://netlab1.usu.edu/novell/listinfo</A><BR>_______________________________________________<BR>Novell
mailing list<BR>Novell@netlab1.usu.edu<BR><A
href="http://netlab1.usu.edu/mailman/listinfo/novell">http://netlab1.usu.edu/mailman/listinfo/novell</A><BR><A
href="http://netlab1.usu.edu/novell/listinfo">http://netlab1.usu.edu/novell/listinfo</A><BR></BODY></HTML>