content static for 24hrs

Hello,
I have been creating sql server driven web sites for a few years.
I now have to create one which will have over 20-40 thousand sessions per
day, on servers that are not ideal.

The main content changes once a day.
I've read contradictory advice for improving the performance. e.g wrt mixing
html and asp/application variables.

My normal way of coding is to
-open connections and recordsets late and close early
-using stored procedures
-response.buffer=true
-option explicit


The servers will have connection pooling by default.

The same recordsets will be returned thousands of times a day.

Can anyone advise on further good practice.

Thank Soc.

Re: content static for 24hrs

"Sean O'Connor" wrote in message
news:eV7VVtr0HHA.5380@TK2MSFTNGP04.phx.gbl...
>
> The main content changes once a day.
> I've read contradictory advice for improving the performance. e.g wrt
> mixing html and asp/application variables.
>

If the content's effectively static, and what's returned doesn't vary user
to user (that is, you're not actually tailoring the output to a specific
user's query), you might want to consider running a scheduled routine to
generate static HTML pages from the database once a day when the content's
updated.

--
Bob Milutinovic
Cognicom - "Australia's Web Presence Specialists"
http://www.cognicom.net.au/
telephone (0417) 45-77-66
facsimile (02) 9824-2240

Re: content static for 24hrs

Would application variables storing the html be advisable?

"Sean O'Connor" wrote in message
news:eV7VVtr0HHA.5380@TK2MSFTNGP04.phx.gbl...
> Hello,
> I have been creating sql server driven web sites for a few years.
> I now have to create one which will have over 20-40 thousand sessions per
> day, on servers that are not ideal.
>
> The main content changes once a day.
> I've read contradictory advice for improving the performance. e.g wrt
> mixing html and asp/application variables.
>
> My normal way of coding is to
> -open connections and recordsets late and close early
> -using stored procedures
> -response.buffer=true
> -option explicit
>
>
> The servers will have connection pooling by default.
>
> The same recordsets will be returned thousands of times a day.
>
> Can anyone advise on further good practice.
>
> Thank Soc.
>
>
>
>

Re: content static for 24hrs

"Sean O'Connor" wrote in message
news:%23KOGHd10HHA.3400@TK2MSFTNGP03.phx.gbl...
> Would application variables storing the html be advisable?
>

Just knowing there will be 20-40 thousand requests per day (you meant
requests right?) is it enough info.

Is this simply content delivery or is there some application element where a
client needs a session?

How many and how large are the pages would you want to cache?

Is this a hosted site or do you own the server(s)?

In what way are they not ideal? (e.g if they have limited memory or many
other applications on them then loading up memory based application
variables may not be what you want to do).

Do you expected to parameterise the content sent by means of querystring
values?



--
Anthony Jones - MVP ASP/ASP.NET

> "Sean O'Connor" wrote in message
> news:eV7VVtr0HHA.5380@TK2MSFTNGP04.phx.gbl...
> > Hello,
> > I have been creating sql server driven web sites for a few years.
> > I now have to create one which will have over 20-40 thousand sessions
per
> > day, on servers that are not ideal.
> >
> > The main content changes once a day.
> > I've read contradictory advice for improving the performance. e.g wrt
> > mixing html and asp/application variables.
> >
> > My normal way of coding is to
> > -open connections and recordsets late and close early
> > -using stored procedures
> > -response.buffer=true
> > -option explicit
> >
> >
> > The servers will have connection pooling by default.
> >
> > The same recordsets will be returned thousands of times a day.
> >
> > Can anyone advise on further good practice.
> >
> > Thank Soc.
> >
> >
> >
> >
>
>

Re: content static for 24hrs

Thank you,

20k visitors, 250k hits per day.

Largely content delivery, some of which will be subscription based. So some
kind of session info would be required.

There are about new 200 pages per day, but the majority of these would be
unpopular, most users only visit a page or two. The new site should be more
sticky, with usage perhaps multiplying by 2-5.

The servers are in house. The are single purpose servers.
sqlserver, w2000,sp4,pentium3,1gb ram, 2 hard drives(one for backups, 1 for
everything else)
web server, w2003,sp1,pentium3,1gb ram, 3 hard drives.

Yes I plan to parameterise using querystrings.

SOC.


"Anthony Jones" wrote in message
news:eRV0gp10HHA.5408@TK2MSFTNGP02.phx.gbl...
> "Sean O'Connor" wrote in message
> news:%23KOGHd10HHA.3400@TK2MSFTNGP03.phx.gbl...
>> Would application variables storing the html be advisable?
>>
>
> Just knowing there will be 20-40 thousand requests per day (you meant
> requests right?) is it enough info.
>
> Is this simply content delivery or is there some application element where
> a
> client needs a session?
>
> How many and how large are the pages would you want to cache?
>
> Is this a hosted site or do you own the server(s)?
>
> In what way are they not ideal? (e.g if they have limited memory or many
> other applications on them then loading up memory based application
> variables may not be what you want to do).
>
> Do you expected to parameterise the content sent by means of querystring
> values?
>
>
>
> --
> Anthony Jones - MVP ASP/ASP.NET
>
>> "Sean O'Connor" wrote in message
>> news:eV7VVtr0HHA.5380@TK2MSFTNGP04.phx.gbl...
>> > Hello,
>> > I have been creating sql server driven web sites for a few years.
>> > I now have to create one which will have over 20-40 thousand sessions
> per
>> > day, on servers that are not ideal.
>> >
>> > The main content changes once a day.
>> > I've read contradictory advice for improving the performance. e.g wrt
>> > mixing html and asp/application variables.
>> >
>> > My normal way of coding is to
>> > -open connections and recordsets late and close early
>> > -using stored procedures
>> > -response.buffer=true
>> > -option explicit
>> >
>> >
>> > The servers will have connection pooling by default.
>> >
>> > The same recordsets will be returned thousands of times a day.
>> >
>> > Can anyone advise on further good practice.
>> >
>> > Thank Soc.
>> >
>> >
>> >
>> >
>>
>>
>
>

Re: content static for 24hrs

"Sean O'Connor" wrote in message
news:unmaTf20HHA.3536@TK2MSFTNGP06.phx.gbl...
> Thank you,
>
> 20k visitors, 250k hits per day.
>
> Largely content delivery, some of which will be subscription based. So
some
> kind of session info would be required.
>
> There are about new 200 pages per day, but the majority of these would be
> unpopular, most users only visit a page or two. The new site should be
more
> sticky, with usage perhaps multiplying by 2-5.
>
> The servers are in house. The are single purpose servers.
> sqlserver, w2000,sp4,pentium3,1gb ram, 2 hard drives(one for backups, 1
for
> everything else)
> web server, w2003,sp1,pentium3,1gb ram, 3 hard drives.
>
> Yes I plan to parameterise using querystrings.
>

Would upgrading your servers and writing standard ASP be an acceptable
answer? We're looking at something like 15 requests per second here which
isn't a particularly amazing but those pentium 3 machines may struggle (I've
never seen 2003 run on a pentium 3).

A goal to have in mind if you want to cache what is essentially static
content is to remove ASP from the majority of the requests for this content
altogether. ASP performs poorly even if all its doing is copying bytes from
an array or a file to the response. Making the majority of the responses
handled purely by IIS can significantly improve the performance of your
site.

The simplest is as Bob has said build the content on a scheduled basis. The
downside to that approach is that the matrix of content you build could be
quite large and potentially much of it may not be visited at all.

Here is another option:-

Lets take an example of /MyFolder/MyPage.asp?valA=x&valB=y.

We could re-arrange the URL like this:-

/MyFolder/MyPage/x/y.htm

This page won't actually exist but /folder/MyPage.asp does.

Now we have a custom 404 handler /404.asp in the root of the site.

It takes /MyFolder/MyPage from the URL that was requested and checks that
/MyFolder/MyPage.asp exists. If not it continues with a 404 response.

If it does it simply server executes /MyFolder/MyPage.asp.

MyPage.asp needs to handle the parsing of "Querystring" values from the rest
of the path. It can then create the x/y.htm file. It sets the
response.status back to 200 OK and then chunks the content of x/y.htm to the
client.

Any subsequent attempts to fetch this page will find a static file and be
handled purely by IIS without any ASP/SQL Server intervention at all.

This doesn't help to protect subscribed content. This technique could be
refined and expanded to cover subscribed content by using a custom ISAPI
filter if you have that option open to you (I.e. C++).


--
Anthony Jones - MVP ASP/ASP.NET

Re: content static for 24hrs

Thanks Anthony,
That seems to be good advice.
I think I will pursue a combination of these ideas.
-improve hardware
-good asp practice
-generate html for content pages




So would flow be?-
-xxx/yyy/zzz.htm is sent to 404.asp if it doesn't exist
-404.asp extracts querystrings (does it pick up error page from http_referer
in servervariables?)
and requests data from database. if data found the html page is created
(filesystemobject)
404.asp then redirects to zzz.htm
otherwise redirects to 404.htm. (for stats)



Another issue is a requirement for a list of most popular pages, like
bbcnews for example.
Writing each hit to a database is what springs to my mind. This will surely
hurt database performance and wouldn't be possible if pages were html?
Would this be best done using the iis logging to database?

Many Thanks Soc.
"Anthony Jones" wrote in message
news:eSOC2g30HHA.5160@TK2MSFTNGP05.phx.gbl...
> "Sean O'Connor" wrote in message
> news:unmaTf20HHA.3536@TK2MSFTNGP06.phx.gbl...
>> Thank you,
>>
>> 20k visitors, 250k hits per day.
>>
>> Largely content delivery, some of which will be subscription based. So
> some
>> kind of session info would be required.
>>
>> There are about new 200 pages per day, but the majority of these would be
>> unpopular, most users only visit a page or two. The new site should be
> more
>> sticky, with usage perhaps multiplying by 2-5.
>>
>> The servers are in house. The are single purpose servers.
>> sqlserver, w2000,sp4,pentium3,1gb ram, 2 hard drives(one for backups, 1
> for
>> everything else)
>> web server, w2003,sp1,pentium3,1gb ram, 3 hard drives.
>>
>> Yes I plan to parameterise using querystrings.
>>
>
> Would upgrading your servers and writing standard ASP be an acceptable
> answer? We're looking at something like 15 requests per second here which
> isn't a particularly amazing but those pentium 3 machines may struggle
> (I've
> never seen 2003 run on a pentium 3).
>
> A goal to have in mind if you want to cache what is essentially static
> content is to remove ASP from the majority of the requests for this
> content
> altogether. ASP performs poorly even if all its doing is copying bytes
> from
> an array or a file to the response. Making the majority of the responses
> handled purely by IIS can significantly improve the performance of your
> site.
>
> The simplest is as Bob has said build the content on a scheduled basis.
> The
> downside to that approach is that the matrix of content you build could be
> quite large and potentially much of it may not be visited at all.
>
> Here is another option:-
>
> Lets take an example of /MyFolder/MyPage.asp?valA=x&valB=y.
>
> We could re-arrange the URL like this:-
>
> /MyFolder/MyPage/x/y.htm
>
> This page won't actually exist but /folder/MyPage.asp does.
>
> Now we have a custom 404 handler /404.asp in the root of the site.
>
> It takes /MyFolder/MyPage from the URL that was requested and checks that
> /MyFolder/MyPage.asp exists. If not it continues with a 404 response.
>
> If it does it simply server executes /MyFolder/MyPage.asp.
>
> MyPage.asp needs to handle the parsing of "Querystring" values from the
> rest
> of the path. It can then create the x/y.htm file. It sets the
> response.status back to 200 OK and then chunks the content of x/y.htm to
> the
> client.
>
> Any subsequent attempts to fetch this page will find a static file and be
> handled purely by IIS without any ASP/SQL Server intervention at all.
>
> This doesn't help to protect subscribed content. This technique could be
> refined and expanded to cover subscribed content by using a custom ISAPI
> filter if you have that option open to you (I.e. C++).
>
>
> --
> Anthony Jones - MVP ASP/ASP.NET
>
>
>