JIT on ASP.Net

  • Thread starter Thread starter John
  • Start date Start date
J

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
 
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\Temporary 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
 
Thanks for the response. Is there any way to adjust
the 'not been used for a while' time frame?
 
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)
 
Thanks for the response. Is there any way to adjust
the 'not been used for a while' time frame?
Click to expand...

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.
 
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.
 
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
Click to expand...

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.
Click to expand...

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.
 
Back
Top