C
Christian Correa
Has anyone experienced a performance decrease after migrating a project to
..NET? We migrated our code from ASP to ASP.NET, modifying sintax whenever
needed. Basically, the application is the same but it now has its code
separated into the .aspx and codebehind (.aspx.vb) files. After compiling
the DLL in /bin and some debugging, the application runs just fine and takes
advantage of having the codebehind compiled. Migration will continue so that
eventually we use all the benefits of .NET, like web controls or ADO.NET.
We ran benchmarks comparing our pre-.NET application and the newly migrated
..NET one, and .NET has proved to have faster execution times. Slightly
faster, but that will only improve after continuing migration of Interop
components, and as we use more of the native ASP.NET features.
However, one of our customers that is trying out the ASP.NET version and is
running benchmarks of their own has experienced the exact opposite scenario:
Their ASP.NET implementation runs slower than the regular ASP one. We have
duplicated their environment on our test servers to the greatest extent
possible (same OS, Service Packs, etc) and we always get better execution
times on the ASP.NET version.
Needless to say, we are still tuning-up the application, but we wanted to
know if anyone has experienced a similar problem, where an ASP application
performs better than an almost "copy and paste" version on ASP.NET. We still
use ADO thru COM Interop and there are no plans to move to ADO.NET in the
near future.
I am looking for any thoughts as to what to have in mind when using ASP.NET
with ADO Interop to run an application that was originally created in ASP
with ADO. What are the common pitfalls you might have experienced that
caused a slower performance with .NET? What could cause an ASP page to run
faster than its codebehind-compiled-equivalent in ASP.NET?
Thanks,
-Christian Correa
..NET? We migrated our code from ASP to ASP.NET, modifying sintax whenever
needed. Basically, the application is the same but it now has its code
separated into the .aspx and codebehind (.aspx.vb) files. After compiling
the DLL in /bin and some debugging, the application runs just fine and takes
advantage of having the codebehind compiled. Migration will continue so that
eventually we use all the benefits of .NET, like web controls or ADO.NET.
We ran benchmarks comparing our pre-.NET application and the newly migrated
..NET one, and .NET has proved to have faster execution times. Slightly
faster, but that will only improve after continuing migration of Interop
components, and as we use more of the native ASP.NET features.
However, one of our customers that is trying out the ASP.NET version and is
running benchmarks of their own has experienced the exact opposite scenario:
Their ASP.NET implementation runs slower than the regular ASP one. We have
duplicated their environment on our test servers to the greatest extent
possible (same OS, Service Packs, etc) and we always get better execution
times on the ASP.NET version.
Needless to say, we are still tuning-up the application, but we wanted to
know if anyone has experienced a similar problem, where an ASP application
performs better than an almost "copy and paste" version on ASP.NET. We still
use ADO thru COM Interop and there are no plans to move to ADO.NET in the
near future.
I am looking for any thoughts as to what to have in mind when using ASP.NET
with ADO Interop to run an application that was originally created in ASP
with ADO. What are the common pitfalls you might have experienced that
caused a slower performance with .NET? What could cause an ASP page to run
faster than its codebehind-compiled-equivalent in ASP.NET?
Thanks,
-Christian Correa