This is in response to a few queries on how UO pooling is performing in a live 
environment.

Firstly a few points to remember

1. This is the use of pooling in UO.NET in an ASP.NET environment.
2. It is important you understand how iis and asp.net work b by understand I 
mean the use of application pools, and how they thread.
3. Connection pooling basically runs the connection to the database as a thread 
under the application pools worker process. Each of these connections is for an 
ip and account and takes a licence. Therefore if you have multiple worker 
processes either because you have multiple sites not sharing application pools 
or are in a web garden environment then expect multiple licences being taken up.
4. UO.NET connection pooling uses performance counters which means it needs 
access to the windows registry. You need to either update the access on the 
registry keys required for performance counters or change the user that the 
application pool runs as to one with access ! b Google on basp.net 
performance counters registryb to find out more on this.
5. There seems to have been a bug in the earlier releases of UODOTNET.DLL b I 
tested with versions 2.1.0.7137 and 2.1.1.7211. My pooling seemed to suddenly 
stop working b I think it may have been something to do with using named 
common but I never got round to testing that theory. Version 2.1.2.7232 dated  
29 Oct 2007 fixed the problem. I would recommend you use the latest 
uodotnet.dll !
6. Pooling means that each request for u2 does not need to open a new socket 
and start a new udt process. So the biggest gains in using pooling is If you 
have lots of small requests as you would have in web environment. If you open a 
UO connection and spend a minute performing actions then close it, pooling 
would not give much of a gain.

Now some stats b These are on a Windows server 2003 Standard edition server 
with 1 dual Xeon, and unidata 7.x on RHEL ES version 4 on a dual twin proc 
Xeon. Both machines hosted in a hosting centre in Manchester UK and running 
about 12  live websites written in asp.net and connecting to ud on the backend 
(example sites are http://findaholiday.timesonline.co.uk/ , 
http://holidaysearch.telegraph.co.uk/europe.xhtml , http://express.adprs.net/ , 
http://travel.theholidayplace.co.uk/cuba.xhtml , 
http://jet2holidays.adprs.net/spain.xhtml )

1. Firstly the results of a live website that is not under an especially high 
load. This is quite a good test as the asp.net side of this site does very 
little, It basically places an xhtml snippet, generated by the u2 server, into 
a xhtml page, that is inturn shown as an iframe inside a customers page 
(examples of this are the advertiser links boxes on the 
http://www.telegraph.co.uk/travel/ site). These are some stats from a ping 
service that accesses a particular page every 5 minutes. The site used 
connection pooling up until the 6th March, I then changed it to not use pooling 
for 5 days. It then uses pooling again from the 11th. As you can see there is a 
marked difference. 

Date   Avge Time   Total No Hits
1         511 ms   190,097
2         480 ms   233,044
3         540 ms   254,799
4         568 ms   217,077
5         526 ms   258,157
6       1,312 ms   277,823
7       1,677 ms   185,731
8       1,143 ms   160,699
9       1,044 ms   200,688
10      1,169 ms   263,025
11        582 ms

2. Now some performance hits b this was done using Microsoftbs Web 
Application Stress tool (WAS) on a PC connected to the internet with a normal 
domestic 8Meg ADSL line (this accounts for the high TTLB).
Two test results, both with 25 threads lasting 1 minute.  Both tests where run 
multiple times with very similar resultsb&

a. Without pooling

Hit Count: 184
Requests per Second: 6.13
Time to first byte (in milliseconds)
--------------------------------------------------------------------------------
Average:                      2884.90
Min:                          258.68
25th Percentile:              1942.94
50th Percentile:              2313.63
75th Percentile:              4264.76
Max:                          8468.82

Time to last byte (in milliseconds)
--------------------------------------------------------------------------------
Average:                      3635.09
Min:                          354.75
25th Percentile:              2106.91
50th Percentile:              3320.31
75th Percentile:              5279.63
Max:                          13653.23

b. With pooling

Number of hits: 559
Requests per Second: 18.62
Time to first byte (in milliseconds)
--------------------------------------------------------------------------------
Average:                      595.02
Min:                          166.76
25th Percentile:              272.33
50th Percentile:              316.37
75th Percentile:              606.62
Max:                          9698.60

Time to last byte (in milliseconds)
--------------------------------------------------------------------------------
Average:                      1111.46
Min:                          268.82
25th Percentile:              336.82
50th Percentile:              423.89
75th Percentile:              1956.06
Max:                          21289.83



Conclusion - pooling in our setup is about 3 times faster.


HTH 
Symeon.
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Reply via email to