4

I have a Windows Azure applicaion (web-role) which I'm having serious problems with.

If there are problems with one of my databases which the application connects to (in this case, SQL Azure transient errors) many exceptions are thrown in my application. Every single exception thrown is caught and handled nicely, yet the IIS service eventually shuts down, or even worse, the entire web-role becomes un-responsive.

The number of exceptions is high, anything from 30-100 per second.

My application runs happily on 3 web-role instances, whilst experiencing this problem I have upgraded to 10 instances because I'm sure I read that caught exceptions are quite heavy on resources, but this made no difference.

There are no errors or (from what I can determine) helpful warnings in the event log.

.. and just to repeat, I can guarantee there are no uncaught exceptions occurring.

Does this sound like normal server behaviour?

2 Answers 2

2

If you're convinced it's the exceptions, StackOverflow, but based on what I know: not directly. Only unhandled exceptions cause direct process termination.

But the symptoms you're describing aren't that either - "IIS Service eventually shuts down" - can you be specific about what exactly you mean by that?

Exceptions can cause exceptionally bad performance, and 30-100/sec seems like an awful lot; if they survive a GC generation they might just be fragmenting your address space but not still lingering (checked for a memory leak?)

"Or worse, the entire web-role becomes unresponsive" - you mean the VM instance? This sounds more like a resource leak that isn't getting cleaned up (memory or external resources).

1
  • You've actually given me a lot to think about. I've had this problem for a very long time and I think I may be working on lot's of assumptions now. I'm going to start with a clean sheet, really break it down today, and I'll post an update! Thanks Jan 24, 2012 at 15:43
2

After further investigation, this wasn't caused by the exceptions, although a huge number of exceptions do impact performance, this issue was simply that the database problem that led to the exception also increased the processing time for each request, the requests couldn't be processed faster than they were coming in, which was causing them to build up until IIS would say "no more! 503!!"

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .