Slooow!

[swiftee]

I am trialing the Agave android app and while I find the UI generally flexible and nice to use, it's painfully slow to change status of a device. I am finding 5 seconds or so after key press to turn a light on or off for example. This is on LAN connection.

 

Are others experiencing the same? 

[G W]

I get almost instant response with Agave. it's always less than half a second.

 

I apologize for this not being a 1000 word rant but I have a wife.

 

Best regards,

Gary Funk

[MWareman]

LAN/WAN should not make much difference. SSL/HTTP will make far more difference.

 

Make sure on the LAN you are not using SSL.

[James Peterson]

I am trialing the Agave android app and while I find the UI generally flexible and nice to use, it's painfully slow to change status of a device. I am finding 5 seconds or so after key press to turn a light on or off for example. This is on LAN connection.

 

Are others experiencing the same? 

I have not noticed any issues like this on any connection.  SSL or not.  I will defer to others experience on this matter for advice.   

[G W]

The only thing slow about Agave is James Peterson. He insists on having a life and not working on the application 23 hours a day.

 

Other than the issue with him having time to work on Agave, the application is solid and he has been very responsive to bugs and adding new features.

 

I apologize for this not being a 1000 word rant but I have a wife.

 

Best regards,

Gary Funk

[swiftee]

ok thanks guys this is interesting. I just went and tried without SSL and it is dramatically faster - almost instantaneous which is great. So my use of SSL is having a 5 second impact. I think this warrants some debugging as I would like to have SSL on for WAN access. Anything I can help with debugging to get SSL working at same speed? 

 

Another unrelated issue is that one of my lighting scenes is reporting its on at 132% when on maximum. Obviously this can't be true - anyone seen this before?

[G W]

Yes. You can exclude the responses in the scene and it will report correctly.

 

I apologize for this not being a 1000 word rant but I have a wife.

 

Best regards,

Gary Funk

[giesen]

SSL response times have always been a problem for me. Non-SSL is near instantaneous, but SSL is very slow to negotiate. I wonder if Agave is opening a new socket every time, as I know the ISY supports Http session re-use so you don't have to go through the (slow) SSL negotiation every time

 

Sent from my SM-N910W8 using Tapatalk

[MWareman]

ok thanks guys this is interesting. I just went and tried without SSL and it is dramatically faster - almost instantaneous which is great. So my use of SSL is having a 5 second impact. I think this warrants some debugging as I would like to have SSL on for WAN access. Anything I can help with debugging to get SSL working at same speed?

 

Another unrelated issue is that one of my lighting scenes is reporting its on at 132% when on maximum. Obviously this can't be true - anyone seen this before?

How many bits did you use when generating your SSL cert?

A 4096 bit cert takes many seconds longer than a 2048 bit certificate, with 1024 being very quick. Problem is most browsers now consider 1024 to be 'too 'weak'.

 

If you have 4096, best advise is to reissue the cert at 2048 and see if it's better.

 

Michael.

[James Peterson]

Another unrelated issue is that one of my lighting scenes is reporting its on at 132% when on maximum. Obviously this can't be true - anyone seen this before?

 

Yes, this is definitely possible.  If you have devices that the On Level is 70% for the scene,  but that device is currently set to 100% then its going to read something like 143%.  I would check the on levels for the devices in the scene and let me know if this is the cause.   I would suspect that it is. 

 

The only thing slow about Agave is James Peterson. He insists on having a life and not working on the application 23 hours a day.

 

Yes, I do apologize for this.   I do get a bit selfish sometimes.

[swiftee]

How many bits did you use when generating your SSL cert?

A 4096 bit cert takes many seconds longer than a 2048 bit certificate, with 1024 being very quick. Problem is most browsers now consider 1024 to be 'too 'weak'.

 

If you have 4096, best advise is to reissue the cert at 2048 and see if it's better.

 

Michael.

 

Thanks for the suggestion however I am using 2048 bits in my cert. I also use a Windows app called Snap Switch and never have these delays with SSL connections.

[G W]

Thanks for the suggestion however I am using 2048 bits in my cert. I also use a Windows app called Snap Switch and never have these delays with SSL connections.

A Windows PC is about 10,000 times faster than the ISY.

 

Best regards,

Gary Funk

[MWareman]

Thanks for the suggestion however I am using 2048 bits in my cert. I also use a Windows app called Snap Switch and never have these delays with SSL connections.

Establishing SSL connections depends on VERY complex math at the server side of the connection. At the time ISY994 was built, it was prohibitive to have a hardware solution to do this math fast. Not so much today.

 

A 2048bit key will take 2-4 seconds to get established on an ISY. 4096 closer 6-10 seconds. This is 'normal' for the platform.

 

For use with Agave, I use an Apache reverse proxy, so the external solution terminates the SSL. It also has the benefit of allowing me to use alternate credentials for Agave to access my ISY. It's documented in the Wiki...

 

Michael.

[swiftee]

ok thanks guys. Gary - I am not using a windows server, just the ISY994i. What I meant is that if I use a windows Phone with client app called Smart Switch to connect with ISY with SSL it's instantaneous. However when I use Agave client app with SSL it's 5 secs or so to connect. Both these are running on two phones with relatively same CPU performance (actually the Android is newer and faster so in theory Agave be faster than my 2 yr old Windows Phone).

 

I am hoping the developer can see there may be an issue here. Or are you guys saying this 2-4 seconds is going to be normal if I want a secure connection? if that is the case why does the Snap switch app not have this delay - could it be something to do with the requirement of that app to have the cert loaded locally on the phone?

 

I guess I could setup one profile for local LAN without SSL as its not important within my LAN and if I am accessing remotely then a 2-4 second delay is not such a big deal either. I was just looking for a one size fits all approach like I had working with the other app.

 

thanks guys I appreciate the support (I am no expert in SSL/certs etc)

[swiftee]

For use with Agave, I use an Apache reverse proxy, so the external solution terminates the SSL. It also has the benefit of allowing me to use alternate credentials for Agave to access my ISY. It's documented in the Wiki...

Thanks Michael I may try that. I am using Zywall gateway and I am sure I can do something like that.

regards

Tarquin

[G W]

ok thanks guys. Gary - I am not using a windows server, just the ISY994i. What I meant is that if I use a windows Phone with client app called Smart Switch to connect with ISY with SSL it's instantaneous. However when I use Agave client app with SSL it's 5 secs or so to connect. Both these are running on two phones with relatively same CPU performance (actually the Android is newer and faster so in theory Agave be faster than my 2 yr old Windows Phone).

 

I am hoping the developer can see there may be an issue here. Or are you guys saying this 2-4 seconds is going to be normal if I want a secure connection? if that is the case why does the Snap switch app not have this delay - could it be something to do with the requirement of that app to have the cert loaded locally on the phone?

 

I guess I could setup one profile for local LAN without SSL as its not important within my LAN and if I am accessing remotely then a 2-4 second delay is not such a big deal either. I was just looking for a one size fits all approach like I had working with the other app.

 

thanks guys I appreciate the support (I am no expert in SSL/certs etc)

Hummmm. Interesting.....

 

Crap... I can see no logic in that.

 

Short and to the point.

Best regards,

Gary Funk

[James Peterson]

ok thanks guys. Gary - I am not using a windows server, just the ISY994i. What I meant is that if I use a windows Phone with client app called Smart Switch to connect with ISY with SSL it's instantaneous. However when I use Agave client app with SSL it's 5 secs or so to connect. Both these are running on two phones with relatively same CPU performance (actually the Android is newer and faster so in theory Agave be faster than my 2 yr old Windows Phone).

 

I am hoping the developer can see there may be an issue here. Or are you guys saying this 2-4 seconds is going to be normal if I want a secure connection? if that is the case why does the Snap switch app not have this delay - could it be something to do with the requirement of that app to have the cert loaded locally on the phone?

 

I guess I could setup one profile for local LAN without SSL as its not important within my LAN and if I am accessing remotely then a 2-4 second delay is not such a big deal either. I was just looking for a one size fits all approach like I had working with the other app.

 

thanks guys I appreciate the support (I am no expert in SSL/certs etc)

PM me.  I'd like to discuss getting temp access to your system so that I can take a peek and see if anything is timing out.  If that is alright with you.  

 

SSL is not my specialty by any means.  I use an SSL connection on my local LAN as well and have never noticed any issues with latency and commands are near instantaneous.  If there is an issue I will do what I can to locate it.  I will still defer to others more experienced in this topic to suggest fixes or possible avenues to search for resolving this.  I include myself in that as if it is a problem on my end, I tend to listen to my users opinions.  

[MWareman]

@James, Does Agave use SSL Session Resumption (or sometimes called 'reuse')? If not, you may want to consider adding it. It should allow ISY to only have to do the computationally expensive bit once...

[James Peterson]

@James, Does Agave use SSL Session Resumption (or sometimes called 'reuse')? If not, you may want to consider adding it. It should allow ISY to only have to do the computationally expensive bit once...

Probably not.  I'll make an exception on summer work to take a look into this since it will affect so many people.

[James Peterson]

@James, Does Agave use SSL Session Resumption (or sometimes called 'reuse')? If not, you may want to consider adding it. It should allow ISY to only have to do the computationally expensive bit once...

After a wee bit of research.  Android and specifically (HttpURLConnection) which I am using is supposed to cache SSL connections automatically.  I have viewed the connections in wireshark, but it appears to be renegotiating the connection each time.  If someone can verify this who is more versed in wireshark or some IP sniffer I would appreciate it.  Either way, it still takes no more then a second for SSL requests on my side.

[MWareman]

After a wee bit of research. Android and specifically (HttpURLConnection) which I am using is supposed to cache SSL connections automatically. I have viewed the connections in wireshark, but it appears to be renegotiating the connection each time. If someone can verify this who is more versed in wireshark or some IP sniffer I would appreciate it. Either way, it still takes no more then a second for SSL requests on my side.

What keysize do you have on your ISY?

[swiftee]

PM me. I'd like to discuss getting temp access to your system so that I can take a peek and see if anything is timing out. If that is alright with you.

 

SSL is not my specialty by any means. I use an SSL connection on my local LAN as well and have never noticed any issues with latency and commands are near instantaneous. If there is an issue I will do what I can to locate it. I will still defer to others more experienced in this topic to suggest fixes or possible avenues to search for resolving this. I include myself in that as if it is a problem on my end, I tend to listen to my users opinions.

thanks for looking into this James but please note it's not super urgent for me, so please don't disrupt your summer work! I am happy to take you up on direct access to my isy to help debug but would not be able to get to that for a few days. Thanks!

 

Sent from my SM-G935F using Tapatalk

[James Peterson]

What keysize do you have on your ISY?

I was using a 1024.  I just tried a 2048 and my app could not connect at all.  Reverted back to 1024 for now.   Seems I have issues to work out after all.  

[MWareman]

I was using a 1024. I just tried a 2048 and my app could not connect at all. Reverted back to 1024 for now. Seems I have issues to work out after all.

Yeah. It's a significant jump in horsepower needed on a server to terminate 2048 vs 1024 - much more than double. Each doubling increases the difficulty by the jump squared (double bit size is 4 times more difficult). I think the two things you can do are:

 

1) longer timeout

2) persistent connection

 

For 2 - I know you have a service that subscribes to the websocket service. To upstream commands use this existing socket (if that's even possible!) - or do they cause a new connection to be made for the command? Once a command is issued, do you keep the socket open for any period of time, or close it right away? SSL reuse I have already suggested - this would speed reconnection (but not the first connection).

 

Personally, I have a 2048 bit key on a reverse proxy, and Agave works fine against it (partly because the reverse proxy has a crypto accelerator). This is possible because you use websockets and the RESat API (so I thank you!). The external proxy is likely the only way to make SSL perform well...

[James Peterson]

Yeah. It's a significant jump in horsepower needed on a server to terminate 2048 vs 1024 - much more than double. Each doubling increases the difficulty by the jump squared (double bit size is 4 times more difficult). I think the two things you can do are:

 

1) longer timeout

2) persistent connection

 

For 2 - I know you have a service that subscribes to the websocket service. To upstream commands use this existing socket (if that's even possible!) - or do they cause a new connection to be made for the command? Once a command is issued, do you keep the socket open for any period of time, or close it right away? SSL reuse I have already suggested - this would speed reconnection (but not the first connection).

 

Personally, I have a 2048 bit key on a reverse proxy, and Agave works fine against it (partly because the reverse proxy has a crypto accelerator). This is possible because you use websockets and the RESat API (so I thank you!). The external proxy is likely the only way to make SSL perform well...

 

1) Timeout has been increased and is allowing connections.  I'll have this in the next update.  

2) Its not possible to send commands through the subscription socket as far as I know.  I have read posts about this on the forums and all have stated not possible.  Each command is sent though its own socket and disconnected afterwards.  I am attempting to implement (https://developer.android.com/reference/android/net/SSLSessionCache.html) but not having much luck.