RE: Using SQl to store aspx pages and memory problems

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

DancesWithBamboo,

Thankyou for your help - your response I believe hits the nail on the head.

I am trying to look at my options on pulling the code out of the pages and
placing it in asp.net - not sure exactly how to do it - but are looking at
different options. If you look at one of my recent replies to Klaus I have
outlined a few of my ideas.

I found the asp solution very flexible and it provided a good solution to
the issues I was having - but I was forced to move to asp.net due to
reliability issues and a need to use webservices. Asp pages still get served
occasionally from the server as they were created 3-4 years ago and the
problems I have been having with asp.net have not really caused a great
problem until recently. I guess its time to do some more up-grading.

Thanks for your help.

--
matthew


"DancesWithBamboo" wrote:

> To understand why the solution you had working in clasic asp doesn't perform
> in .net, you have to understand the internals of how these systems work.
>
> In asp, every page was intrepreted runtime. It looked for your <% %> tags
> and intrepeted the code between them real time as it ran each page. If your
> page didn't caontain much server-side code and was mostly content then there
> wasn't much to do. Basically the system was designed to look at each page
> each time it was hit as necessary. This is why almost all systems (except
> your) are faster in .net.
>
> .net on the other hand "compiles" every page into IL code when the page
> changes. This IL code is then intrepeted real time by the runtime engine.
> Compiling is a lot of work. It outputs new code, checks syntax, checks type
> casts, checks variable declarations, function calls, and another million
> things. asp would just crap out if it didn't like what it saw. The key here
> is that .aspx files are compiled once for every folder and every folder every
> time a file changes in it. On a normal system, you take a hit once for each
> folder that has a page in it requested. Then nothing changes for a long time
> so the compiler may not do anything for months.
>
> In your system, every time you push a page out from SQL to disk you are
> instructing the compiler that there is a new page that it must compile (not
> to mention the file system write which could possibly be the slowest thing
> you could do on a Windows box). Now if you start loading all 10000 pages
> into the same folder, the work it has to do will get worse as the more pages
> are requested since there will be more pages to compile.
>
> The key to making your system work is to do some major rearchitecting or
> leave it in clasic asp. Why do you want to change? If you rearchitect, you
> need to only store "data" in the database and keep code in files on the
> server compiled. Then you load the pages with data from the db. This is how
> content management systems work.
>
> An example would be your invoice pages. I assume that many of your "pages"
> in the database are invoices. You need to just store them as text along with
> whatever data you need to make the page in SQL Server (table called Invoice?)
> and then have a page called invoice.aspx on the server that uses code to grab
> the data and format it for display(including your graph control).
>
> It really has never been a "good" design to put code in a database. It just
> happens that classic asp was stupid enough that you could get away with it.
> You need to leverage the systems for what they are good at; IIS/.net for page
> serving and SQL server for data storage.
.

Relevant Pages