0

We have a very old web service which is called by a scheduler service. The best performance we have managed to get from it has been 300ms so the scheduler can call it 3 times a second max. We are experiencing much higher load now so we need to speed up the web service.

What the web service does is to get a massive xml and save it to many many tables in a horrendously designed database. It's been written in .NET 1.0 and we are kind of unable to recompile this code!

We will re-design and re-write this code to work better with the untouchable underlying database however for the time being we need to speed up this web service asap.

My question is that what can be done to the Windows, IIS, .NET run time etc to get a better throughput of a .NET 1.1 ASP.NET page? (without touching the code)

Aref Karimi
  • 1,822
  • 4
  • 27
  • 46

2 Answers2

0

There are a lot of tweaks you can do to help performance of IIS but they all might be useless in this instance.

Check out this article its old but still kind of applies. I would look in to a web garden maybe. There are cases where you shouldn't use one though do some research first. Make sure the box hardware isn't reaching its limits, If RAM and CPU is taking a bashing any settings you change might make it worse.

Nick
  • 1,783
  • 1
  • 15
  • 18
0

To clarify - you do plan to 'touch the code` - but the web service, not the database?

Are the XML documents coming at a steady, consistent pace or do you have periods of increased activity?

If the issue is that you can't store the XML documents fast enough, one approach might be to store the XML in its own table in an XML data type column, and then have a separate service or process that reads from that table and performs the inserts. That way the web service just receives the XML and returns a response indicating that the XML was received and it's fast. The insert process might get a little behind if inserts are slow but it can catch up during slower periods.

Scott Hannen
  • 27,588
  • 3
  • 45
  • 62
  • We plan to re-write this code in future but we cannot touch the code nor the database now. There are already two end-points. One as you said just grabs the xml and puts it in a table. The second one is hit 3 times a second by a scheduler service. we want to hit that end point say 30 times a second but it does not work fast enough to reach that. – Aref Karimi Apr 08 '16 at 02:11
  • Does "not touching the database" include not writing new stored procedures? You might get some mileage out of writing new stored procedures that perform inserts in batches using table value parameters. This works well when you have a number of tables and the primary keys generated from one insert are referenced in subsequent inserts. If that's an option I can go into some more detail. – Scott Hannen Apr 08 '16 at 02:19