I have written a web service that returns an XmlDocument. The code is similar
to the example below, except it returns an XmlDocument rather than an
XmlDataDocument. When I run the service from the test harness in VS (or from
a client page), CPU utilization on the Web server spikes to over 50% and
returns quickly to around 0-5% after it has completed. I have tried the
following:
1) Changed the type returned by the web service to type string.
2) Turned off Session State on the web server
3) Turned off logging on the Web server
4) Use anonymous authentication.
I would like to limit the amount of processor used on the web server when
the service is called. My client is concerned about this, because eventually
there will be hundreds of concurrent users. What other steps can I take to
limit the amount of CPU used?
[WebMethod( Description="Returns Northwind Customers",EnableSession =false)]
public XmlDocument GetData()
{
SqlConnection conn = new SqlConnection("Integrated Security=SSPI;Persist
Security Info=False;Initial Catalog=Northwind;Data Source=xxxxxxx");
SqlDataAdapter cmd = new SqlDataAdapter("Select * from Customers",conn);
DataSet ds = new DataSet();
cmd.Fill(ds,"Orders");
XmlDataDocument doc = new XmlDataDocument(ds);
return doc;
Randy A. Ynchausti - 17 Dec 2005 23:24 GMT
John Doe,
> What other steps can I take to
> limit the amount of CPU used?
[quoted text clipped - 11 lines]
> XmlDataDocument doc = new XmlDataDocument(ds);
> return doc;
Have you tried database connection pooling? Otherwise, you may want to time
each statement in the web-service and determine what is causing the CPU
load -- where is all the processing time spent.
Regards,
Randy
dbottjer - 18 Dec 2005 06:41 GMT
In the example you give your query users a "select *" I realize this is
likely just an example but I would look at the query you are using and make
sure you are returning only the data you need. For example, specify each
collumn you need and do not use a select *. Furthermore, use a where clause
to eliminate unwanted data.
I would also suggest possibly applying indexes to the table or tables you
are returning data from. Indexes can help the database find the results you
are looking for faster.
As previously suggested caching might be a good option to look at.
Another suggestion would be to possibly look at using Data Transfermation
Objects (DTO) instead of a data set. Datasets can get rather large and do
have some overhead. Populating a collection of objects could possibly reduce
some overhead.
> I have written a web service that returns an XmlDocument. The code is similar
> to the example below, except it returns an XmlDocument rather than an
[quoted text clipped - 23 lines]
> XmlDataDocument doc = new XmlDataDocument(ds);
> return doc;
John Doe - 18 Dec 2005 12:46 GMT
The actual web service does not connect to a database, it connects to a
proprietary API gateway which also uses .Net. I apologize for the confusion,
but I was trying to illustrate the fact that, as in the example, when
returning an XML document with approximately 90 rows, that processor
utilization spikes to about 50%. The actual format of the XML Document is
similar to the following
<quotes><quote symbol="msft" close="26.8"></quote></quotes>
> In the example you give your query users a "select *" I realize this is
> likely just an example but I would look at the query you are using and make
[quoted text clipped - 40 lines]
> > XmlDataDocument doc = new XmlDataDocument(ds);
> > return doc;
GCR - 19 Dec 2005 07:56 GMT
The problem is taht you still don't know if the spike is caused by the
service logic or by the logic you called through the API! Maybe you could
build and use a mock object instead of calling the API, to see if the high
processing load is in the service logic.
> The actual web service does not connect to a database, it connects to a
> proprietary API gateway which also uses .Net. I apologize for the confusion,
[quoted text clipped - 48 lines]
> > > XmlDataDocument doc = new XmlDataDocument(ds);
> > > return doc;