I recently learned about scenarios which require warming up an app (with high throughput requirement) before they start s开发者_运维问答erving real requests. The logic behind this was to allow JIT to do its performance magic!
Is this a norm for Java apps or is this generally done for memory heavy (footprint) apps?
If you are talking about a high traffic webapp/website then JIT is a very minor issue. The biggest problem is warming up (populating) all the cache layers you'll need to have. E.g ehcache regions which are being populated from hibernate. That's because IO related operations are orders of magnitude slower than anything that happens inside the CPU (that is unless you are calculating fractals :)
The question is, when would you want to go out of your way to do this?
If you roll out a webapp, and it is IMMEDIATELY live, then while you're "warming" it, you're adding extra load, which is counter-productive. Similar is true when a desktop app starts. No point in warming if the user is going to start immediately using it. Or worse, not allowing the user to interact while you are warming the app.
If you roll out a webapp, and you test the deployment before you point your load balancers to it, then you've already warmed it as a side result.
In addition to cherouvim's answer, I can think of a few other issues that require warm-up:
- Objects instantiation (lazy loading, singletons etc.);
- Heap allocation (if your
Xms
is smaller than yourXmx
).
I imagine that the OS attunes itself to an application's behavior as well, so that OS calls may also be affected by a warm-up period.
Most of the above (cache population, object initialization) aren't specific to Java.
精彩评论