c# - Tracking Concurrent Web Service Requests with Timestamps -

i have asp.net 4.0 web service accepts transmission of xml files. in past (with different implementation of same web service) have tracked concurrency (# of xml files being received/processed @ same time) using timestamps. have replicated behavior in new version of web service such:

in constructor web service class record connectionstarttime using httpcontext.current.timestamp

public class mywebservice : system.web.services.webservice {   public mywebservice()   {     connectionstarttime = httpcontext.current.timestamp   } } 

after i'm done processing xml file within webmethod insert file database (recording connectionendtime) , return response user. execute database insert in new thread end user doesn't have wait insert occur receive response.

new thread (() =>   {     insertintodatabase(connectionstarttime, connectionendtime=datetime.now, xmlfile);   }).start(); return responsetouser; 

now i'm trying gauge how many concurrent xml transmissions we've reached 2 methods:

1. performance counters

• asp.net apps v4.0\requests executing - counter peaked @ 52.
• asp.net apps v4.0\requests queued - counter peaked @ 19.

to me means should see point have 33 records overlapping connectionstarttime , connectionendtime.

2. querying against timestamps - in this question reference query i'm using calculate number of concurrent transmissions based on connectionstarttime , connectionendtime. these datetime fields in sql server database. note: query in question reworked version of algorithm we've been using past 3 years determine concurrency may not 100% correct other implementations of algorithm (excel macros, etc) have been validated.

my problem 2 methods never align. maximum results querying timestamps hit 10 while performance counters suggested maximum should 30+. i'm having hard time locating discrepancy is. making mistake in how i'm recording timestamps? httpcontext.current.timestamp value not record beginning of transmission web service?

using thread start cause discrepancy between data , asp.net counters (mainly because of way you've written thread function. change to:

datetime endtime = datetime.now new thread (() => {     insertintodatabase(connectionstarttime, connectionendtime=endtime, xmlfile); }).start(); return responsetouser; 

not sure if source of difference, code measuring time takes process request , spin thread , issue command database record times.

my code measures time process request capturing endtime in closure before spinning thread. should come out closer asp.net performance counters. not sure if account entire discrepancy, should help.

i agree previous commenters shouldn't starting new thread every request this. spinning new threads takes time , memory intensive. if high performance application have effect. using queueuserworkitem better, although using threadpool comes own set of concerns , limitations.

as final comment, pattern using has other potential gotchas surface request rate increases (queuing, concurrency , bottleneck issues). i'd bet in current implementation discrepancy grows request rate. if high performance or performance sensitive application use different approach measuring concurrency entirely.