JIT on ASP.Net

[John]

Hi,

We have a large asp.net app and have a copy out on the web
on a shared server. I believe that the first time you run
any portion (.aspx) of the app for the first time the code
gets compiled. I have observed that the second time I run
the same .aspx it fires up much faster.
I guess my question is, where does this compiled code
reside, in memory or on disk? And what, aside from
changing the code, causes it to need to be recompiled.

On the shared server, if I run the code and then come back
a few days later it seems to need to be recompiled (runs
much slower the first time). If they knock down the
asp.net process will this cause it. If too many users
does the compiled version get removed from memory?

Thanks,
John

[Hermit Dave]

okay the process of JITing is pretty straight forward... it compiles what it
thinks you are going to use....
if first page is heavy.. and uses many many objects then those parts will be
compiled as well.... (it only does a partial compile of the assembly)
so yes the first time you will have an additional time for compilation...
It is stored in harddrive
The path where it stores the compiled version is somewhere in this dir
C:\WINXPPRO\Microsoft.NET\Framework\v1.1.4322\Temp orary ASP.NET Files
(replace winxppro with windows dir on your machine and v1.1.4322 with your
version of framework

the native copy is discard if it has not been used for a while. and the
first request after its discarded causes step 1... JITing... (The reason is
that it can make more optimisations)

--
Regards,

HD

Once a Geek.... Always a Geek
"John" <an*******@discussions.microsoft.com> wrote in message
news:02****************************@phx.gbl...

Hi,

We have a large asp.net app and have a copy out on the web
on a shared server. I believe that the first time you run
any portion (.aspx) of the app for the first time the code
gets compiled. I have observed that the second time I run
the same .aspx it fires up much faster.
I guess my question is, where does this compiled code
reside, in memory or on disk? And what, aside from
changing the code, causes it to need to be recompiled.

On the shared server, if I run the code and then come back
a few days later it seems to need to be recompiled (runs
much slower the first time). If they knock down the
asp.net process will this cause it. If too many users
does the compiled version get removed from memory?

Thanks,
John

[bruce barker]

asp.net actually has two phases.

1) parse and compile. when the application is loaded for the first time,
(first hit to any asp.net page), all pages in the application must be parsed
and compiled. the produced assemblies are created in a temp dir controlled
by asp.net. after parse and compile, the assembly is loaded in memory. this
needs to be done everytime an application is loaded into the asp.net worker
process. reloads are forced if the service is recycled, a file change is
made in the application directory, the application times out, or is recycled
for using too many resources.

2) jit. when an assembly is loaded into memory it must be jit'd first. the
jit'd assembly is cached on disk by the GAC. Each assembly has a unique
moniker which is used to lookup cached jit if its still there. non global
jits are deleted when space is required.

the next release will allow pages to be parsed and compiled separately
rather than all at once, and there will be support for compiling the
assembly ahead of time. the jit will work as before. a precompiled site will
only need rejitting if the GAC cache is flushed, or the assembly is updated.
-- bruce (sqlwork.com)


"John" <an*******@discussions.microsoft.com> wrote in message
news:02****************************@phx.gbl...

Hi,

We have a large asp.net app and have a copy out on the web
on a shared server. I believe that the first time you run
any portion (.aspx) of the app for the first time the code
gets compiled. I have observed that the second time I run
the same .aspx it fires up much faster.
I guess my question is, where does this compiled code
reside, in memory or on disk? And what, aside from
changing the code, causes it to need to be recompiled.

On the shared server, if I run the code and then come back
a few days later it seems to need to be recompiled (runs
much slower the first time). If they knock down the
asp.net process will this cause it. If too many users
does the compiled version get removed from memory?

Thanks,
John

Thanks for the response. Is there any way to adjust
the 'not been used for a while' time frame?

-----Original Message-----
okay the process of JITing is pretty straight forward... it compiles what itthinks you are going to use....
if first page is heavy.. and uses many many objects then those parts will becompiled as well.... (it only does a partial compile of the assembly)so yes the first time you will have an additional time for compilation...It is stored in harddrive
The path where it stores the compiled version is somewhere in this dirC:\WINXPPRO\Microsoft.NET\Framework\v1.1.4322\Tem porary ASP.NET Files(replace winxppro with windows dir on your machine and v1.1.4322 with yourversion of framework

the native copy is discard if it has not been used for a while. and thefirst request after its discarded causes step 1... JITing... (The reason isthat it can make more optimisations)

--
Regards,

HD

Once a Geek.... Always a Geek
"John" <an*******@discussions.microsoft.com> wrote in messagenews:02****************************@phx.gbl...

Hi,

We have a large asp.net app and have a copy out on the web on a shared server. I believe that the first time you run any portion (.aspx) of the app for the first time the code gets compiled. I have observed that the second time I run the same .aspx it fires up much faster.
I guess my question is, where does this compiled code
reside, in memory or on disk? And what, aside from
changing the code, causes it to need to be recompiled.

On the shared server, if I run the code and then come back a few days later it seems to need to be recompiled (runs
much slower the first time). If they knock down the
asp.net process will this cause it. If too many users
does the compiled version get removed from memory?

Thanks,
John

.

[Martin]

<an*******@discussions.microsoft.com> wrote in message
news:02****************************@phx.gbl...

Thanks for the response. Is there any way to adjust
the 'not been used for a while' time frame?

There should be through <processModel> in machine.config but none of the
options I fiddled with so far seem to have the slightest effect as to
keeping the app alive. No matter what I try, the app ends with the last
session. I am now trying to keep the app up by generating a dummy requests
automatically every so many minutes (< half the session timeout).
Considering the amount and sort of information available on the subject this
seems the only way.

I had just sorted out all kinds of nifty caching schemes for my dynamic
content. Of course that all goes down the drain (and worse) when the app
shuts down as you also experienced.

Martin.

[Martin]

<an*******@discussions.microsoft.com> wrote in message
news:02****************************@phx.gbl...

Thanks for the response. Is there any way to adjust
the 'not been used for a while' time frame?

There should be through <processModel> in machine.config but none of the
options I fiddled with so far seem to have the slightest effect as to
keeping the app alive. No matter what I try, the app ends with the last
session. I am now trying to keep the app up by generating a dummy requests
automatically every so many minutes (< half the session timeout).
Considering the amount and sort of information available on the subject this
seems the only way.

I had just sorted out all kinds of nifty caching schemes for my dynamic
content. Of course that all goes down the drain (and worse) when the app
shuts down as you also experienced.

Martin.

[Alvin Bruney]

process model settings aren't all, you need to play with the iis settings as
well depending on what version of iis you run. I've implemented this and i
can honestly say that my app takes about 3 -4 weeks before a recycling event
takes place ecause it is stateful and i'm not using the database to store
state information but it is being stored in a global static variable. i
think, not sure, that my iddle timeout AND timeout is set to infinite. I can
check for you if you really need an answer to this.

--
Regards,
Alvin Bruney
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Martin" <du***@somewhere.nl> wrote in message
news:40***********************@news.wanadoo.nl...

<an*******@discussions.microsoft.com> wrote in message
news:02****************************@phx.gbl...

Thanks for the response. Is there any way to adjust
the 'not been used for a while' time frame?
There should be through <processModel> in machine.config but none of the
options I fiddled with so far seem to have the slightest effect as to
keeping the app alive. No matter what I try, the app ends with the last
session. I am now trying to keep the app up by generating a dummy requests
automatically every so many minutes (< half the session timeout).
Considering the amount and sort of information available on the subject

this seems the only way.

I had just sorted out all kinds of nifty caching schemes for my dynamic
content. Of course that all goes down the drain (and worse) when the app
shuts down as you also experienced.

Martin.

[Martin]

Alvin,

process model settings aren't all, you need to play with the iis settings as well depending on what version of iis you run. I've implemented this and i
can honestly say that my app takes about 3 -4 weeks before a recycling event takes place
I believe you. I did look for timeout settings on the IIS tabs but didn't
find anything there regarding shatdown delays. I vaguely remembered I had
seen these settings but now I realise that was COM+. Component Services. I
would still like to know how it is done, I can hardly believe it is not
possible to manipulate through configuration.

However, I don't need it anymore. My little app that sends a requests every
user-definable couple of minutes is done and works perfectly, it is keeping
my app hot till the cows come home. I posted it here yesterday morning but I
never saw it appear. Is it impossible to post messages with file attachments
here? I guess so, I never saw any.
think, not sure, that my idle timeout AND timeout is set to infinite. I can check for you if you really need an answer to this.

What do we actually really need? :-) I would like to try. I found part of
what caused the problemjust now. As often it comes down to reading properly.
MSDN Library says:

"The managed code configuration system does not read the <processModel>
configuration settings. Instead, they are read directly by the
aspnet_isapi.dll unmanaged DLL. Changes to this section are not applied
until IIS is restarted."

which I did not do while I was trying different settings. Still, if the
default is Infinite, why does it not adhere to that? Well, there's more,
directly under the remark about restarting IIS:

"If you install ASP.NET on a domain controller, there are special steps you
must take to make the installation work properly. For more information, see
article Q315158, "ASP.NET Does Not Work with the Default ASPNET Account on a
Domain Controller," in the Microsoft Knowledge Base at
http://support.microsoft.com."

My server is a domain controller... Something with a weak acount that is not
available on domain controllers... But they fixed it with Framework version
1.1 . So, still a mistery.

It (MSDN Library) finaly says something about a suspected deadlock state as
a possible reason for an application shutdown and that I might want to try
increasing the responseDeadlockInterval setting.

Tomorrow is another day.

Martin.

[Alvin Bruney]

hey my policy is if it works well don't muck with it.

--
Regards,
Alvin Bruney
Got tidbits? Get it here...
http://tinyurl.com/3he3b
"Martin" <du***@somewhere.nl> wrote in message
news:40***********************@news.wanadoo.nl...

Alvin,

process model settings aren't all, you need to play with the iis settings

as

well depending on what version of iis you run. I've implemented this and

i can honestly say that my app takes about 3 -4 weeks before a recycling

event

takes place

I believe you. I did look for timeout settings on the IIS tabs but didn't
find anything there regarding shatdown delays. I vaguely remembered I had
seen these settings but now I realise that was COM+. Component Services. I
would still like to know how it is done, I can hardly believe it is not
possible to manipulate through configuration.

However, I don't need it anymore. My little app that sends a requests

every user-definable couple of minutes is done and works perfectly, it is keeping my app hot till the cows come home. I posted it here yesterday morning but I never saw it appear. Is it impossible to post messages with file attachments here? I guess so, I never saw any.

think, not sure, that my idle timeout AND timeout is set to infinite. I can

check for you if you really need an answer to this.

What do we actually really need? :-) I would like to try. I found part of
what caused the problemjust now. As often it comes down to reading

properly. MSDN Library says:

"The managed code configuration system does not read the <processModel>
configuration settings. Instead, they are read directly by the
aspnet_isapi.dll unmanaged DLL. Changes to this section are not applied
until IIS is restarted."

which I did not do while I was trying different settings. Still, if the
default is Infinite, why does it not adhere to that? Well, there's more,
directly under the remark about restarting IIS:

"If you install ASP.NET on a domain controller, there are special steps you must take to make the installation work properly. For more information, see article Q315158, "ASP.NET Does Not Work with the Default ASPNET Account on a Domain Controller," in the Microsoft Knowledge Base at
http://support.microsoft.com."

My server is a domain controller... Something with a weak acount that is not available on domain controllers... But they fixed it with Framework version 1.1 . So, still a mistery.

It (MSDN Library) finaly says something about a suspected deadlock state as a possible reason for an application shutdown and that I might want to try
increasing the responseDeadlockInterval setting.

Tomorrow is another day.

Martin.