Hi Aaron, I am taking the liberty of forwarding my response to Axis mailing list ( may be we can get some more perspectives ...). Hope you don't mind.
> I am encountering very bad performance using JAX-RPC over HTTPS in an > applet. For every single call, I encounter what seem to be multiple > checks against various certificates. The following is an > example of one First call is likely to take a very long time ( few tens of seconds ) on account of loading all the different certificates and initializing the SecureRandom class ). Subsequent calls should have expected performance. I mean there will be slowdown due to SSL handshake, but that is well understood. So, I would suspect the following: 1. There is an SSL handshake taking place for every call. SSL handshake involves public-key cryptography which is "very slow". Actual speed will depend upon the cipher suite used. I am attaching a section from my work on Java SSL performance which should give you some idea of the overhead involved. 2. You have a Cryptographic Service Provider ( I see some references to JPI which I am not familiar with ) that does proper PKIX validation. The validation performed by J2SDK1.4 is rudimentary and doesn't follow the PKIX guidelines. PKIX guidelines call for validation against a CRL ( the location of the CRL is usually in the certificate ). Downloading this and doing a proper validation could be expensive. 3. The network is introducing delays. I have noticed a delay of 200ms on every TCP communication on-and-off on some machines attributed to something known as Nagle's algorithm. This happens even when both the client and server machine are running on the same machine. ------------------- Excerpt from SSL Performance Work ----------------------- PERFORMANCE ISSUES It should come as no surprise that, SSL, on account of all the cryptographic processing, is slower than TCP. Security doesn't come free! Given that, you, an implementer and designer, would like to understand the extent and nature of this slowness and be able to assess its impact on user experience or response time and system capacity or number of concurrent users. As SSL adds no additional functionality on top of TCP, it is fairly straightforward to get an idea of the overhead by simply running the same program twice, once over TCP and then over SSL. We will use a simple benchmark program, consisting of a client and server, to observe the overhead of SSL for making connections and for exchanging messages. However, you must be careful in interpreting and applying these results to your spe-cific application scenario. Micro-benchmarks, like the one we are going to talk about, tend to execute a small set of operations repeatedly, and suffer from a number of known problems, the most notable being that the benchmark may not simulate a real usage scenario. A real world application does more than just transmitting messages and hence the overhead of SSL, although significant with respect to communication time, may be a very small percentage of overall processing time. Nevertheless, there is value in understanding the performance trade-offs of basic operations for better system design. Let us first define our benchmark and the measurement conditions: we will measure the performance of SSL and TCP for two different types of activities - exchanging data and establishing connections. The performance of exchanging data over an established connec-tion is measured at the client program by sending 8KB blocks of data to a server program, which acted as a sink, in a loop with an iteration count of 2048, and computing the data transfer rate in MB/second. Similarly, the rate of connection establishment is measured at the client program establishing connection with the server program in a loop and is expressed in terms of connections/second. JSTK utility ssltool was used to simulate client and server programs. Table 6-1 presents the measured figures for data transfer rate over TCP and SSL con-nections with different cipher suites under three different scenarios: (I) both client and server programs run on the same machine; (II) client and server program run on different machines connected to a 100 Mbps (Mega bits per second) Ethernet LAN; (III) same as II but with 10 Mbps Ethernet LAN. Both machines were equipped with 450 MHz Pentium II CPU, 256 MB RAM, were running Windows 2000 with Service Pack3 and had J2SDK v1.4 from Sun. Table 6-1 Data Transfer Rate ( MB/second) - TCP and SSL Connection Protocol/Cipher Suite (I) (II) (III) TCP 11.50 11.3 1.10 SSL_RSA_WITH_RC4_128_MD5 1.50 3.00 1.00 SSL_RSA_WITH_RC4_128_SHA 1.20 2.30 1.00 SSL_RSA_WITH_NULL_MD5 2.85 5.40 1.00 SSL_RSA_WITH_NULL_SHA 2.80 3.50 1.00 SSL_RSA_WITH_3DES_EDE_CBC_SHA 0.27 0.55 0.48 SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA 0.27 0.55 0.48 SSL_RSA_WITH_DES_CBC_SHA 0.55 1.14 0.93 SSL_DHE_DSS_WITH_DES_CBC_SHA 0.55 1.14 0.90 A number of observations are in order: � Measured TCP data transfer rate for scenarios (II) and (III) is close to the raw bandwidth offered by Ethernet wire. In fact, a popular native benchmarking tool for TCP performance, pcattcp, downloadable from http://www.pcausa.com/Utilities/pcattcp.htm, simulating the same load as our ssltool based benchmark, reported a bandwidth of 11.4 MB/sec and 1.1 MB/sec, respectively, between these two machines. � SSL data transfer rate is worse when both client and server are running on the same machine than when they are running on different machines for 100 Mbps LAN. This speedup can be explained by the fact that the benchmark simulates a continuous stream of data flow, allowing parallel cryptographic processing at both the machines. � As expected, SSL data transfer rate depends on the cipher suite. In most practi-cal cases, SSL slows the data transfer by 90 to 95 percent for 100 Mbps LAN and by 10 to 50 percent for 10 Mbps LAN. How do we explain this? For 100 Mbps LAN, CPU is the bottleneck whereas for 10 Mbps LAN, the network bandwidth becomes the bottleneck. � Cipher suites using MD5 for computing MAC are faster than the corresponding ones using SHA. Now let us look at connection overhead of SSL under the same scenarios. These per-formance figures for TCP and certain selected cipher suites are presented in Table 6-2. Table 6-2 Connection Rate (connections/second) - TCP and SSL Connection Protocol/Cipher Suite (I) (II) (III) TCP 330.0 500.0 500.0 SSL_RSA_WITH_RC4_128_MD5 6.5 3.2 3.2 SSL_RSA_WITH_RC4_128_SHA 6.5 3.2 3.2 SSL_RSA_WITH_3DES_EDE_CBC_SHA 6.5 3.2 3.2 SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA 1.15 1.14 1.12 The impact of SSL is even more profound on rate of connection creation, with DSS based authentication performing significantly worse than RSA. This is expected, as DSS is much slower than RSA. In fact, now that RSA patent has expired, there is no valid reason to use DHE and DSS in place of RSA. Other things to notice: network bandwidth plays no role here as the public-key cryptography dominates the overall connection setup time. Also, unlike data transfer rate, the connection rate is not better for two-machine scenario. This is only to be expected as the connection setup involves sequential processing by both machines. In a real application the data transfer rate or connection time alone is rarely of much concern. What you really care about is the response time (how long does it take to satisfy a request?) and the capacity of the system (how many requests can be processed per unit time?). The impact of SSL on both of these metrics would depend on the structure of specific application, average load, type of interactions, network latency, specific J2SE platform and many other things besides CPU speed, network bandwidth and transport protocol. Still, use of SSL could have pronounced adverse impact on response time and system capacity. The good news is that this processing can be significantly speeded by specialized crypto accelerators and separate SSL connections can be processed in parallel on different machines, improving the response time and scaling the capacity. ---------------------------------------------------------------------------- ---------- Hope this helps. Pankaj Kumar. Personal Website: http://www.pankaj-k.net > -----Original Message----- > From: Aaron Rustad [mailto:arustad@;anassina.com] > Sent: Saturday, October 26, 2002 4:33 PM > To: [EMAIL PROTECTED] > Subject: Jax-RPC HTTPS Performance Problems... > > > > I hope you don't mind my contacting you, but you are the only > person I > can find that seems to have experience working with HTTPS and > WebServices (Axis/JAX-RPC) . > > I am encountering very bad performance using JAX-RPC over HTTPS in an > applet. For every single call, I encounter what seem to be multiple > checks against various certificates. The following is an > example of one > call: > > ------------- > Connecting https://localhost:8443/connect/service/NominationServiceIF > with no proxy > > Connecting https://localhost:8443/connect/service/NominationServiceIF > with cookie "JSESSIONID=2506A7777ECA8D3680E758DB40FE8A83" > > Loading Root CA certificates from > C:\PROGRA~1\Java\J2RE14~1.0\lib\security\cacerts > > Loaded Root CA certificates from > C:\PROGRA~1\Java\J2RE14~1.0\lib\security\cacerts > > Loading Https Root CA certificates from > C:\PROGRA~1\Java\J2RE14~1.0\lib\security\jssecacerts > > Https Root CA certificates file not found: > C:\PROGRA~1\Java\J2RE14~1.0\lib\security\jssecacerts > > Loaded Https Root CA certificates from > C:\PROGRA~1\Java\J2RE14~1.0\lib\security\jssecacerts > > Loading JPI Https certificates from C:\Documents and > Settings\arustad\.java\jpihttpscerts140 > > Loaded JPI Https certificates from C:\Documents and > Settings\arustad\.java\jpihttpscerts140 > > Loading certificates from JPI session certificate store > > Loaded certificates from JPI session certificate store > > Checking if certificate is in JPI session certificate store > ------------- > > > Any advice would be greatly appreciated!! > Thanks! > Aaron. >
