P
Phil Davidson
This is a question about threading design and performance of an ASP.NET
page. My ASP.NET page works like this:
public class WebForm : System.Web.UI.Page {
private static My_external_COM_Class myObject = new
My_external_COM_Class ();
private void Page_Load(object sender, System.EventArgs e) {
System.Threading.Monitor.Enter(myObject);
myObject.SlowOperation(e.CertainMembers);
System.Threading.Monitor.Exit(myObject);
Response.Write(answerFromSlowOperation);
}
}
When hitting the page with HTTP POST once in isolation, response takes
about 70 seconds. When hitting the page five times in quick succession,
the responses all take 280 to 350 seconds to return. The total elapsed
time is still close to 350 seconds, the same as if the POSTs were sent
one at a time. This implies that when even one of the threads is still
in SlowOperation, this can delay any thread that has completed
SlowOperation and is trying to return.
My question: Is there a way to configure the code or the threading
parameters so that the threads that have completed SlowOperation can
return immediately, rather than be held back by another thread that is
performing SlowOperation? Once they complete SlowOperation they need
not wait any longer.
(It also seems possible that my timing measurements are artifacts of
the client process that performs the HTTP POST.)
-- Phil Davidson, Oakland, CA
page. My ASP.NET page works like this:
public class WebForm : System.Web.UI.Page {
private static My_external_COM_Class myObject = new
My_external_COM_Class ();
private void Page_Load(object sender, System.EventArgs e) {
System.Threading.Monitor.Enter(myObject);
myObject.SlowOperation(e.CertainMembers);
System.Threading.Monitor.Exit(myObject);
Response.Write(answerFromSlowOperation);
}
}
When hitting the page with HTTP POST once in isolation, response takes
about 70 seconds. When hitting the page five times in quick succession,
the responses all take 280 to 350 seconds to return. The total elapsed
time is still close to 350 seconds, the same as if the POSTs were sent
one at a time. This implies that when even one of the threads is still
in SlowOperation, this can delay any thread that has completed
SlowOperation and is trying to return.
My question: Is there a way to configure the code or the threading
parameters so that the threads that have completed SlowOperation can
return immediately, rather than be held back by another thread that is
performing SlowOperation? Once they complete SlowOperation they need
not wait any longer.
(It also seems possible that my timing measurements are artifacts of
the client process that performs the HTTP POST.)
-- Phil Davidson, Oakland, CA