From: Toni on
I have a massive ASP (VBScript) application on a heavily trafficked website that I need
to optimize before considering moving to a more powerful server.

With IIS6 and an ASP application, I understand that if I have the following ASP
expression:

Const SomeString = "Some Long Data String"

that if I have 3,000 visitors, SomeString will be created and destroyed at the beginning
and end of each user's connection, with a THEORETICAL limit of 3,000 constants existing
at the same time.

But, if my GLOBAL.ASA creates Application("SomeString") = (something), is it created
just once, with a theoretical limit of existing just once?

Or is SomeString duplicated from the Application variable every time I use it (which
would eliminate the efficiency advantage I'm looking for)?

Thanks!!!




From: Evertjan. on
Toni wrote on 14 apr 2010 in microsoft.public.inetserver.asp.general:

> I have a massive ASP (VBScript) application on a heavily trafficked
> website that I need to optimize before considering moving to a more
> powerful server.
>
> With IIS6 and an ASP application, I understand that if I have the
> following ASP expression:


There are no asp expressions, this is a VBS expression.

> Const SomeString = "Some Long Data String"
>
> that if I have 3,000 visitors, SomeString will be created and
> destroyed at the beginning and end of each user's connection, with a
> THEORETICAL limit of 3,000 constants existing at the same time.

So what?

And no, there is no "at the same time", unless you talk about say 10
milisecionds as "same", in which case you will have 6000 visitors per
minute, or 36.000 visitors per hour. You probably will have other memory
worries long before 100 x 20 characters memory use per second will get
you into trouble.

> But, if my GLOBAL.ASA creates Application("SomeString") = (something),
> is it created just once, with a theoretical limit of existing just
> once?

> Or is SomeString duplicated from the Application variable every time I
> use it (which would eliminate the efficiency advantage I'm looking
> for)?

It must be duplicated for each page, as each page must have it's own
scope. The calling of session_start in itself will hade more detrimental
effect on performance.

In VBs just making constants global in the sense it would have to be made
available outside tghe scope, would be such an enormous overhead, I
connot imagine that IIS would accomodate for that.

There even is no need for constants in such scripting languages that have
no sepereat string constant type, but for the ease of a sloppy
programmer. A variable will do just as nicely, so I suspect a constant is
just a variable with a read-only tag.




--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
From: Toni on
"Evertjan." wrote...
> Toni wrote on 14 apr 2010 in microsoft.public.inetserver.asp.general:
>
>> I have a massive ASP (VBScript) application on a heavily trafficked
>> website that I need to optimize before considering moving to a more
>> powerful server.
>>
>> With IIS6 and an ASP application, I understand that if I have the
>> following ASP expression:
>
>
> There are no asp expressions, this is a VBS expression.

Ah - Evertjan starts off with a pretentious correction.

Of course, he doesn't understand the server issues involving highly popular websites.



From: Bob Barrows on
Toni wrote:
> I have a massive ASP (VBScript) application on a heavily trafficked
> website that I need to optimize before considering moving to a more
> powerful server.
>
> With IIS6 and an ASP application, I understand that if I have the
> following ASP expression:

"vbscript expression", not "ASP expression"

>
> Const SomeString = "Some Long Data String"
>
> that if I have 3,000 visitors, SomeString will be created and
> destroyed at the beginning and end of each user's connection, with a
> THEORETICAL limit of 3,000 constants existing at the same time.

No. This constant is created and destroyed by each page that has it in
its scope. Not at the beginning and end of each connection or session.
it is unlikely that there will be 3000 instances of it existing at any
particular time. Out of the box, IIS only uses 10 threads, I think, so
theoretically, only 10 copies of it would exist at any time (there may
be more than ten since garbage collection does not occur
instantaneously, but there certainly will not be 3000), unless you
configure IIS to use more threads than that.
Or unless memory is leaking, in which case you have more problems than a
minor constant declaration.

>
> But, if my GLOBAL.ASA creates Application("SomeString") =
> (something), is it created just once, with a theoretical limit of
> existing just once?

No. Each page that uses it will create its own copy of it in memory.
That copy will be destroyed when the page goes out of scope.
>
> Or is SomeString duplicated from the Application variable every time
> I use it (which would eliminate the efficiency advantage I'm looking
> for)?

Yes. Each page that uses it reserves a location in memory to store its
own copy. That copy gets destroyed when the page goes out of scope.

The advantage to storing it in application is that if the value needs to
change at some point, all you need to edit is the global.asa definition,
unless you are using a server-side include file to contain your constant
declarations.

With that many site visitors, session variables are the place to look
for resource conservation. The less you use session variables, the less
memory will be used.


--
HTH,
Bob Barrows


From: Toni on

"Bob Barrows" wrote...
:
>> Or is SomeString duplicated from the Application variable every time
>> I use it (which would eliminate the efficiency advantage I'm looking
>> for)?
>
> Yes. Each page that uses it reserves a location in memory to store its
> own copy. That copy gets destroyed when the page goes out of scope.

Ah - that's the answer I was looking for, thanks!

> The advantage to storing it in application is that if the value needs to
> change at some point, all you need to edit is the global.asa definition,
> unless you are using a server-side include file to contain your constant
> declarations.
>
> With that many site visitors, session variables are the place to look
> for resource conservation. The less you use session variables, the less
> memory will be used.

Interesting. The application I am looking at could do with a few less Session variables,
thanks, Bob!



>
> --
> HTH,
> Bob Barrows
>
>