ISP Session Performance behavior

All three ISP Session products, have similar performance characteristics

Performance Test SETUP

Numbers given here, are no absolute numbers. As with any statistics, numbers differ.

As a client, performance load web stress test, Htt Test 2.14.
The HTT test emulates 80 clients running the default page. Script below

_LOOP 2000
_REQ SSL:443
__GET /cookieweb/Default.aspx HTTP/1.1
__Cookie: AUTO
_EXPECT . "200 OK"
#_EXPECT . "ISP Session"
#_RAND 50 500 timeout
#_SLEEP $timeout
_SET timeout=10

Note that to get realistic stress, at the server side, a server-side delay has been added, just by sleeping at an average of 250ms, because our ASP.NET code, does nothing special but setting some arrays and Session data.
Since Classic ASP cannot 'sleep' a thread, the testscript delays the execution.

The Server was Windows 2012 Sp2, with 1GB RAM, hosted at the cloud. The Web process, was set to 64-bit, thus reducing the bits of 32-bit overhead that this kind of CPU stress implicitly introduces.

Redis (2.8) Server stress has not been shown here, but was monitored as well. For all 3 frameworks, Redis, running on the Web Server had some peeks of 10% but averaged at 3% CPU stress. In a real live situation, Redis should be deployed on a different server.

ISP Sesssion utilizes Redis Connection Pooling, combined with Multiplexing (.NET only)

ISP Session performance graphs

ISP Session Classic Asp performance

ISP Session Performance classic ASP Characteristics.

CPU stress avg 75%
AVG 180 requests p.s.

ISP Session Classic ASP.NET performance

ISP Session Performance with ASP.NET Classic

CPU stress avg 94%
AVG 175 requests p.s.

ISP Session ASP.NET MVC 5.2 performance

ISP Session Performance with ASP.NET MVC 5.2

CPU stress avg 93%
AVG 170 requests p.s.


As you can see, performance for the products are very similar. (Black = requests per second) In the three tests, private bytes (green line) for the W3WP.exe process, are flat and should be flat.
For .NET because it shows that garbage collection hardly occurs. For the 'unmanaged COM' component, you want to be sure there are no memory leaks.


How many REDIS connections were in use? Since the average script execution time was 250ms, and there were 80 HTTP clients simulated, the Redis connection pool stabilized at about 20 connections. The ASP.NET session size, unpacked, was about 20KB in size, so, for each page request, 20KB was fetched from Redis and 20KB was written back.