Azure Redis SSL LRANGE performance

[Crypth]

Hi, we moved from AWS to Azure and started using SSL on Azure's Redis, however it seems there's extreme performance differences. We're doing a LRANGE with roughly 70000 values in one key. When connecting without SSL this takes about a second, with SSL it's in the area of 20 seconds. I realize encryption will have some impact on performance but this seems ridiculous.

To replicate outside the WebApp i set up a VS test and and inserted 75000 60 bytes values in a key. I timed it with both async and sync method of ListRange with the following result (obviously with network latency from me to Azure DC):

For 75k values:
NO SSL async: 4,5629118s, WITH SSL async: 6,0852014s
NO SSL sync: 2,159088, WITH SSL sync: 5,9972594s

For 150k values:
NO SSL async: 6,5748141s, WITH SSL async: 23,7710166s
NO SSL sync: 4,4326997s, WITH SSL sync: 22,8005511

I'd say our data is probably more than 60 bytes per value so the 150k result is more similar to our real data (and the 3-4 extra seconds is networking issues). Any idea if this is even remotely normal? I can't seem to find any indication that this should be the case.

[NickCraver]

@Crypth my understanding is Azure made some improvements here in the Nov/Dec timeframe last year - can you please retest?

[Crypth]

I did test again and it behaves the same. It doesn't seem to be Azure specific, as other frameworks does not have this difference (ServiceStack). So, new test with 150k values on a C1 Azure Redis instance.

Version: 1.0.316.0
With StackExchange and SSL: 28.3 seconds
With StackExchange without SSL: 5.4 seconds

Version 4.0.0.0
With ServiceStack.Redis and SSL: 5.8 seconds
With ServiceStack.Redis without SSL: 5.8 seconds oddly enough.

Would be nice if someone else could confirm, perhaps I'm doing something wrong. It's not an problem for us anymore as we use Redis in an internal network only without SSL.

[NickCraver]

@Crypth sorry I missed this update. Thanks for the repro, do you have example code by chance? We'll be testing this with the Pipelines move in 2.x, see #528 for tracking info!

[NickCraver]

Going to close this out given all the changes since - if anyone hits this still ping me and we'll re-open. Being unable to repro though, this is either resolved, or we need a better repro.