This content has been marked as final. Show 6 replies
To clarify, the first time the feature is requested from either url
takes a long time to run, then all future requests are quick?
If that is so, then it is expected behavior if the code has been
optimized to use already generated results. So the first time the data
is requested it takes some time to put together. Once that has been
done, the same data is being returned over and over from both links as
it does not need to be generated again.
How or why this could be happening would depend greatly how your coded
is constructed and whether it is taking advantage of any intentional or
Nope. Close the browser and begin again with either first. Ontrenduniformst always takes about 20 times as long the first time as thechefzone. I could see each of them taking longer the first time and being quick the second time.
But why would one be 20 times as long the first time as the other is the first time-- consistently? Both URLs in IIS point to the same folder and same document in that folder.
Starging from scratch, ontrenduniforms takes 20+ times as long the first time as thechefzone. This is true if one starts with thechefzone. It is true if one starts first with ontrenduniforms.
> Starging from scratch, ontrenduniforms takes 20+ times as long the first time
> as thechefzone. This is true if one starts with thechefzone. It is true if one
> starts first with ontrenduniforms.
Then you are just going to have to turn on debugging and|or put
debugging tests into your code and see what, if any, path and processing
differences their might be between the two runs.
Yeah, you are right. Been doing that, too, but it is a real pain, because of granularity. There are a lot of modules being called inside loops, so trying to tiime those things is difficult.
I was just hoping against hope that it was some known issue. This is one *WEIRD* problem. We have other stores with almost identical organization and no difference-- all using the same code base, so something is different.
My guess is that it is something totally obvious in our code and someone will feel like an idiot when we find it. One of those "Duh!" moments we all get to experience from time to time! It is just hard to imagine how either ColdFusion OR our code would even know there was a difference!
But, if anyone out there does know of something CF might be doing that could cause this kind of funnyness, ...
Since it only happens the first time that page is requested per browser session, you can limit your searching down to anything that's session-specific.
Are you caching anything in the SESSION object? Are you writing anything to it that is then used in subsequent requests? Is the query that pulls up this data being cached somewhere? Any difference in the SESSION setups on these 2 sites?
That's what is weird. The only difference is that we have two IIS domains both pointing to the exact same folder with the exact same default document. They are both executing the SAME code, not just identical code. Thus any session setup would be the same. When reference needs to be made to URL information, it is always grabbed using CGI entries, such as CGI.HTTP_HOST. This must be the case since 99% of the code lives in component libraries used by all 130+ stores we host. The other 1% is the templates that generate the unique look and feel. This is a much much smaller universe of code that has been reviewed and makes no references to the URL.