Reliability: IIS 7 vs. Earlier Versions...

  • Thread starter Thread starter James Hunter Ross
  • Start date Start date
J

James Hunter Ross

Friends,

I'm not much of an ASP.NET guy. Our ASP.NET application, on IIS , has
managed DLLs call into our company's unmanaged API DLLs extensively. The
API DLL's are thread safe as far as we know, and well tested, just not well
tested under the kinds of loads they might experience being called from many
many simultaneous web sessions.

Anyway, occasionally we "lose" the aspnet_wp.exe process, with nothing
interesting logged to the event log. We are in the process of instrumenting
everything to try to collect some information to get closer to the issue.

In the meantime, as a short-term "pain reliever", we could switch hosting to
IIS 7. We would use a dedicated application pool. Do you folks find the
IIS 7 is generally more reliable for ASP.NET applications? (I know this may
not address the root cause, but if it might help, if it has proven to
generally be more stable, we'll give it try.)

Any words will be appreciated! James
 
Hello James,
Friends,

I'm not much of an ASP.NET guy. Our ASP.NET application, on IIS , has
managed DLLs call into our company's unmanaged API DLLs extensively.
The API DLL's are thread safe as far as we know, and well tested, just
not well tested under the kinds of loads they might experience being
called from many many simultaneous web sessions.

Anyway, occasionally we "lose" the aspnet_wp.exe process, with nothing
interesting logged to the event log. We are in the process of
instrumenting everything to try to collect some information to get
closer to the issue.

In the meantime, as a short-term "pain reliever", we could switch
hosting to IIS 7. We would use a dedicated application pool. Do you
folks find the IIS 7 is generally more reliable for ASP.NET
applications? (I know this may not address the root cause, but if it
might help, if it has proven to generally be more stable, we'll give
it try.)
Click to expand...

Given that the ASP.NET runtime used, is the same, I'd say it shouldn't really
matter....

the runtime is part of the framework, not the webserver, so don't expect
too much improvements if the root cause is in the code, instead of in the
server...
 
Hello James,
Friends,

I'm not much of an ASP.NET guy. Our ASP.NET application, on IIS , has
managed DLLs call into our company's unmanaged API DLLs extensively.
The API DLL's are thread safe as far as we know, and well tested, just
not well tested under the kinds of loads they might experience being
called from many many simultaneous web sessions.

Anyway, occasionally we "lose" the aspnet_wp.exe process, with nothing
interesting logged to the event log. We are in the process of
instrumenting everything to try to collect some information to get
closer to the issue.

In the meantime, as a short-term "pain reliever", we could switch
hosting to IIS 7. We would use a dedicated application pool. Do you
folks find the IIS 7 is generally more reliable for ASP.NET
applications? (I know this may not address the root cause, but if it
might help, if it has proven to generally be more stable, we'll give
it try.)
Click to expand...

Given that the ASP.NET runtime used, is the same, I'd say it shouldn't really
matter....

the runtime is part of the framework, not the webserver, so don't expect
too much improvements if the root cause is in the code, instead of in the
server...
 
James Hunter Ross said:
Friends,

I'm not much of an ASP.NET guy. Our ASP.NET application, on IIS , has
managed DLLs call into our company's unmanaged API DLLs extensively. The
API DLL's are thread safe as far as we know, and well tested, just not
well tested under the kinds of loads they might experience being called
from many many simultaneous web sessions.

Anyway, occasionally we "lose" the aspnet_wp.exe process, with nothing
interesting logged to the event log. We are in the process of
instrumenting everything to try to collect some information to get closer
to the issue.

In the meantime, as a short-term "pain reliever", we could switch hosting
to IIS 7. We would use a dedicated application pool. Do you folks find
the IIS 7 is generally more reliable for ASP.NET applications? (I know
this may not address the root cause, but if it might help, if it has
proven to generally be more stable, we'll give it try.)
Click to expand...


I would say that some application is crashing that ASP.NET Worker process
thread. The only thing that would happen is that it would follow over to
IIS7.

You need to find out what is crashing the worker process thread from an
application usage, at the time of thread crash.


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4109 (20090527) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 
James Hunter Ross said:
Friends,

I'm not much of an ASP.NET guy. Our ASP.NET application, on IIS , has
managed DLLs call into our company's unmanaged API DLLs extensively. The
API DLL's are thread safe as far as we know, and well tested, just not
well tested under the kinds of loads they might experience being called
from many many simultaneous web sessions.

Anyway, occasionally we "lose" the aspnet_wp.exe process, with nothing
interesting logged to the event log. We are in the process of
instrumenting everything to try to collect some information to get closer
to the issue.

In the meantime, as a short-term "pain reliever", we could switch hosting
to IIS 7. We would use a dedicated application pool. Do you folks find
the IIS 7 is generally more reliable for ASP.NET applications? (I know
this may not address the root cause, but if it might help, if it has
proven to generally be more stable, we'll give it try.)
Click to expand...


I would say that some application is crashing that ASP.NET Worker process
thread. The only thing that would happen is that it would follow over to
IIS7.

You need to find out what is crashing the worker process thread from an
application usage, at the time of thread crash.


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4109 (20090527) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 
Back
Top