SSL performance

  • Thread starter Thread starter jvandenbroek
  • Start date Start date
J

jvandenbroek

Hi,

I'm currently testing the appserver over WAN and it's working very good. The only disadvantage now is the added delay when using SSL instead of Regular gateway. Of course, SSL is the preferred way when directly connecting over the internet without a VPN. The delay is especially noticable when clicking on buttons or typing some text, which does feel much less "native".

I understand that using any kind of encryption will always slow things down, but couldn't this be minimized to almost unnoticable? The appserver's system specs, nor the available bandwidth do seem to have any influence on it.

Thanks a lot,

Joost
 
jvandenbroek said:
Hi,

I'm currently testing the appserver over WAN and it's working very good. The only disadvantage now is the added delay when using SSL instead of Regular gateway. Of course, SSL is the preferred way when directly connecting over the internet without a VPN. The delay is especially noticable when clicking on buttons or typing some text, which does feel much less "native".

I understand that using any kind of encryption will always slow things down, but couldn't this be minimized to almost unnoticable? The appserver's system specs, nor the available bandwidth do seem to have any influence on it.

Thanks a lot,

Joost
Click to expand...

might be a performance problem on either the server or the client machine. check whih one is consuming the highest cpu usage. also check your key length, making it smaller will make encryption works faster
 
Checked both sides (also tried multiple servers / clients) and none of them seem to have any issues with their CPU usage. I don't think this has anything to do with the processing power on both sides, but with the implementation of the SSL protocol.

However, using a 1024 bit key does make a very little difference, but it's not as satisfying as using a direct unencrypted connection (over a MPPE128 encrypted PPTP dail-in connection). The mentioned delay is especially noticable when typing really fast in some textfield.
 
I've noticed this too.
If using SSL, performance, especially when typing text is horrible on most accounts. I've switched most of these clients from SSL to standard connections, but i'd feel a lot safer when using SSL.
 
dennes said:
I've noticed this too.
If using SSL, performance, especially when typing text is horrible on most accounts. I've switched most of these clients from SSL to standard connections, but i'd feel a lot safer when using SSL.
Click to expand...

Same here. applications are simply not usable when connected over SSL. Popup windows are not showing and buttons are missing. Dragging a dialog does help displaying the missing objects. SSL switched off works very good, so it's defenitely a SSL problem. Running latest versions.
 
It's been a while that I started this topic, but after testing the latest and greatest version 6 the problem still exists.

Maybe I now know what this problem causes. I've experienced the same kind of lag with other SSL solutions when the Nagle's TCP algorithm was enabled. I think Microsoft's RDP library disabled this algorithm by default, so the latency is much lower. Many applications today disable the algorithm by default, such as webservers, samba, putty etc etc. So my guess is that enabling TCP_NODELAY, which is the same as disabling Nagle's algorithm, would solve this problem.
 
jvandenbroek said:
Maybe I now know what this problem causes. I've experienced the same kind of lag with other SSL solutions when the Nagle's TCP algorithm was enabled. I think Microsoft's RDP library disabled this algorithm by default, so the latency is much lower. Many applications today disable the algorithm by default, such as webservers, samba, putty etc etc. So my guess is that enabling TCP_NODELAY, which is the same as disabling Nagle's algorithm, would solve this problem.
Click to expand...
Can someone of 2x test / confirm this? I really need SSL but as of this moment all i get is complaints about the slow screen rendering. I am using the lowest encryption setting (128bit) so that's not helping. Hopefully the TCP_NODELAY option is working!
 
TCP_NODELAY is enabled....

From the console you cannot generate self-signed certificates with less then 1024 bits.

You need to make use of some other application to generate 128bit certficates.

Nixu
 
nixu said:
TCP_NODELAY is enabled....

From the console you cannot generate self-signed certificates with less then 1024 bits.

You need to make use of some other application to generate 128bit certficates.

Nixu
Click to expand...

Well, then help me in creating such a certificate. I have asked this exact question through support (Ticket ID: BAQ-902157) and this was the response i received:

Dear Frans,
You can use 1024-bit one and it will create what you need.
Sergei Zibarov

So maybe you can do a better job in helping me solve the problems!
 
nixu said:
TCP_NODELAY is enabled....
Click to expand...

Is it really enabled for the SSL socket? The way things are rendered are so much alike as with a stunnel without the TCP_NODELAY 'tweak'. When it's enabled, the speed is just as fast as a direct non-SSL connection. Why don't you install stunnel4 on both sides to see it for yourself. Just change these values in stunnel.conf:

socket = l:TCP_NODELAY=0
socket = r:TCP_NODELAY=0

With these settings, defined at server side, the rendering behavior is identical as when using 2X's build-in SSL tunnel. However, changing above values to stunnel's default '1', thus enabling TCP_NODELAY, there is almost no latency anymore.

I don't believe this speed issue has anything to do with the key strength, at least not significantly. I tested stunnel with a 1024-bits certificate which works just as fast as a direct non-SSL session.

Just saw that 2X also uses the OpenSSL libraries, just like stunnel. I even tried to copy the libraries from the stunnel dir to 2X, but that has no influence at all.
 
jvandenbroek said:
nixu said:
TCP_NODELAY is enabled....
Click to expand...

Is it really enabled for the SSL socket? The way things are rendered are so much alike as with a stunnel without the TCP_NODELAY 'tweak'. When it's enabled, the speed is just as fast as a direct non-SSL connection. Why don't you install stunnel4 on both sides to see it for yourself. Just change these values in stunnel.conf:

socket = l:TCP_NODELAY=0
socket = r:TCP_NODELAY=0

With these settings, defined at server side, the rendering behavior is identical as when using 2X's build-in SSL tunnel. However, changing above values to stunnel's default '1', thus enabling TCP_NODELAY, there is almost no latency anymore.

I don't believe this speed issue has anything to do with the key strength, at least not significantly. I tested stunnel with a 1024-bits certificate which works just as fast as a direct non-SSL session.
Click to expand...

Great work Joost, looks like 2x can solve this instead of the keystrength. I looked at the manual of openssl; i cannot generate a SSL-request with a private key below 472 bits. So your suggestion in the knowlegde base isn't even possible.
Please look at / test Joost's suggestions so we can finally get over this limitation.
Also i want to mention: I know for sure this problem did not exists with earlier versions of 2x application server. I think it was introduced with the release of the latest 4.x versions as far as i can remember.
 
nixu said:
Hi there,

This issues has been solved, could you please download the latest client from: http://www.2x.com/downloads.

Nixu
Click to expand...

Nixu, at what time was the client updated on the downloads section? I have downloaded the client (same version, 6.0.416) at 14.25 today, so one hour ago. Do i have the correct client already? Also do i have to update the server?

Thanks!

Frans
 
Currently there is build 419.

Installing the client should be enough but i recommend to install both.

Nixu
 
Yes, it looks like it's finally solved! Great work and many thanks to Joost!
 
You must log in or register to reply here.
Back
Top