Klaus,
Thankyou for your help - I must admit that at the beginning I was a little
taken back by people's negative responses to the problem - I believe that
people were far to quick to make judgement without bothering to understand
the problem - I mentioned - I think in almost every response I mentioned that
I have around 10,000 pages - and no one bothered to provide much help with
the specific problem - I think the method I have used is not too bad - just
needs to be modified to work efficiently with asp.net.
Yes - most of the pages have mostly content and there is not allot of code
in each page. So I am trying to work out how to implement something similar
to your suggestion - but still provide the flexibility of enabling server
side code where needed.
What can make this is a little difficult is my lack of experience in asp.net
- but hopefully that will improve.
The solution I was looking at would be to create some specific server side
asp.net controls for some of the more specific tasks that I have - for
instance - I need to load charts at the server and therefore need to be able
to provide the data to these charts - sometimes this could be allot of data.
I want the data to be saved in the page so I thought that a asp.net control
could be the way to go - I could pass the data to the control and this
control would already be defined on the server.
So - if I have a string of HTML text with a embedded asp.net server control
and I use the response.write function will asp.net recognize that there is a
control with in the document and load it accordingly??
So there wouldn't be any <% %> within the html - just the server controls.
If this don't work that only way that I can image doing it would be to
implement my own method of tags - search from them at run-time and extract
the code between them and use the Eval function to evaluate the code. Does
not seem like a good solution - but I think it would work.
Part of my aim is to limit the dependence of the need to store data - once
the invoice or file is produced ideally I need future requests to only look
at this one file for it to display correctly - therefore the reasoning on
imbedding the data within the file - but that does not mean that the code
could be pulled out of the file and placed elsewhere. Having as few
dependencies as possible on what is required to display the page was part of
the original design and one that ensures that future system changes will not
inadvertently make viewing older invoices fail. Something that has worked
well over the past 5 years.
Are these the sorts of ideas you were thinking off??
--
matthew
"Klaus H. Probst" wrote:
[color=blue]
> The following suggestion may or may not work for you, but I'll chime in.
>
> First off, to the folks that called the approach your existing app uses
> "idiotic", I've seen classic ASP applications design this way that work
> extremely well, are scalable and extremely manageable. However, the devil is
> in the details. Just putting "pages" in IMAGE or TEXT fields on a SQL
> database isn't some sort of magic pixie dust that solves all problems. It
> takes a lot of thought and experimentation to get just right, and the
> rewards in most cases offset the negative aspects of these designs.
>
> Having said that, your approach is, as you've figured out by now, wrong.
> Others have already mentioned the perf hit you're taking by forcing ASP.NET
> to function in a way it wasn't designed to. But there are ways to get around
> the problem.
>
> First off, I'll assume that you have more content than code. That is, *most*
> of your existing ASP/ASPX pages in the database contain stuff, like invoices
> and whatnot, that do not require intervention by the parser to load and
> display. If this is not the case then stop reading now =)
>
> There are a lot of web applications nowadays that use their databases as
> primary content storage repositories. Blogs are a good example of this.
> However, they do not store code in the database, they store content. If you
> can adapt to this type of scenario then all you have to do is create a sort
> of "master page" or maybe an IHttpHandler implementation that looks at the
> request (even a path), pulls the *content* from the database and then
> displays it on a sort of templated page container. Think of a site like
> MSDN. Lots of articles, yet all the pages look the same. The content is what
> varies. The trick is to simply treat your "pages" as opaque chunks of
> content, and "stream" them into a placeholder page that is rendered the same
> way every time. You can pretty much do anything you want once you're hooked
> into the ASP.NET processing pipeline.
>
> If you do this you'll get rid of your perf problem and you'll still have the
> flexibility and manageability of the database storage. This is web
> application design 101 - always separate content from function and
> structure.
>
> Of course getting from point A to point B could be tricky, but maybe this
> gives you some ideas =)
>
> --
> Klaus H. Probst, MVP
>
http://www.simulplex.net/
>
>
> "matvdl" <matvdl@discussions.microsoft.com> wrote in message
> news:DF375EB0-8373-4D91-B7F3-0400A8AE22E9@microsoft.com...[color=green]
> > DLM,
> >
> > Thanks for your response.
> >
> > I don't believe that SQL is my problem - the time it takes to do the[/color]
> remote[color=green]
> > calls to the external program has not presented any real limitations or
> > caused any significant time-delays. The problem that I have is trying to
> > deal with the quanitity of files that I have and the combiling of those[/color]
> pages[color=green]
> > once they have been returned. Any time issues that I have had are the[/color]
> result[color=green]
> > of parsing and compilling the page.
> >
> > I understand your point - that asp.net was designed to have the pages
> > pre-compiled before requests where made for the pages - I guess this is[/color]
> one[color=green]
> > of the fundamental differances between asp and asp.net. From experiance[/color]
> the[color=green]
> > design that has been implemented had no significant disadvantages when
> > working with asp - in fact I believe that it had some very significant
> > advantages - mainly due to the unlimited number of files it could manage.
> >
> > Question - is it practicale to have 10,000 pages in a single asp.net
> > application. I wouldn't have thought so?
> >
> > I have no alternative but to deal with this many files as it is a legal
> > requirment of the industry I work in is to be able to provide the original
> > copies of invoices to clients - I can't go back to the original data and
> > attempt to re-produce the same invoice just in case the data has changed.
> >
> > So - considering this is what I am stuck with - my problem mainly relates[/color]
> to[color=green]
> > the memory increases - the slowness of the request could be dealt with by[/color]
> the[color=green]
> > more grunt - but the ever increasing memory is more difficult. I believe
> > that this is the result of the creation of a new class each time a new[/color]
> page[color=green]
> > is displayed - although this page gets un-loaded once the info is[/color]
> returned -[color=green]
> > are the increases in memory the result of the new class definition in the
> > asp.net application?
> >
> > If this is the case - is it possible to remove this class definition once[/color]
> it[color=green]
> > has been created? I have tried to delete the file - but this does not[/color]
> appear[color=green]
> > to fix the problem.
> >
> > Does any of this make sense.
> >
> >
> > --
> > matthew
> >
> >
> > "DLM" wrote:
> >[color=darkred]
> > > Go to this link:
> > >
http://www.theserverside.net/books/i...ngPerf/pag.tss
> > >
> > > We all know that there is an initial performance 'hit' the first time a[/color][/color]
> ASP[color=green][color=darkred]
> > > .NET Page is requested, and this is true with the page sitting in it's
> > > virtual directory on IIS. What you seem to be doing is increasing the[/color][/color]
> round[color=green][color=darkred]
> > > trip time for any given request/response for a page to include the time[/color][/color]
> it[color=green][color=darkred]
> > > takes to get the page from SQL Server. And this added time is database[/color][/color]
> access[color=green][color=darkred]
> > > time which is probably longer than any HTTP request.
> > >
> > > I have never seen this kind of architecture before. The whole idea is to
> > > serve pages from a highly scalable architecture such as IIS from the[/color][/color]
> very[color=green][color=darkred]
> > > start, and not make the ASP .NET worker process wait for the files[/color][/color]
> before it[color=green][color=darkred]
> > > can dynamically compile pages. In a sense you are using SQL Server as a[/color][/color]
> web[color=green][color=darkred]
> > > server to your web server, which is highly unusual. You need to find a[/color][/color]
> way to[color=green][color=darkred]
> > > place all your pages on the web server and use SQL Server only for data
> > > retrieval/update.
> > >
> > > TAKE A LOOK AT MICROSOFT PATTERNS & PRACTICES
> > >
> > >[/color][/color]
>
>
>[/color]
