Reliability: IIS 7 vs. Earlier Versions...

[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

 

[Jesse Houwing]

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.)

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...

 

[Jesse Houwing]

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.)

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...

 

[Mr. Arnold]

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.)

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

 

[Mr. Arnold]

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.)

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]

....this all helps.

 

[James Hunter Ross]

....this all helps.