search

gridgain / gridgain-old

268 stars 85 forks source link

Application Warmup #61

Open sirinath opened 10 years ago

sirinath commented 10 years ago

Sometimes it makes sense to be able to warm up an application before starting the processing the live data. So it would be good to provide a method to: 1) warm up GG itself 2) warm up User code mocking any IO related operations

The warm up methodology should not result in a de optimisation when switching to live mode.

sirinath commented 10 years ago

Warm up should ensure that all code paths are touched multiple times so JIT can kick in. Perhaps this can be build like what you would do for code coverage and unit testing, though it should be much faster and make the JIT kick in. After this phase perhaps you can set in a stream of cases which would be used in normal usage for further JIT optimisation.

For the client code it would be good to provide a GG specific test and warm up harness to do the same.

Basically during the warm up period / warm up sequence you should 1) do multiple code coverage runs for JIT to kick in 2) Simulate normal usage patterns for JIT optimisation 3) Repeat for client code using the harness.

dsetrakyan commented 10 years ago

I think warm up should be part of user code not internal GG operation. Otherwise user's logic would not be pre-compiled and would require separate warm up, which does not make sense.

sirinath commented 10 years ago

I think it should be cooperative between user code and GG specific warm up framework. User code for warm up can call the GG warm up harness and then evoke the Harness specifically used to warm up user code.

The harnesses need not be internal to GG they can be another project derived from what you use to stress / unit / CC test GG but aimed at just warming up GG than testing it. Since this already exist in some for or the other why reinvent the wheel. Easier to repackage and re use than user writing everything again from scratch. It is matter of making this into a holistic framework.

Also this would help in improving the quality of the unit testing / stress testing / CC framework and this might end up being a superset of this project, and the same framework can be used by the users. Also ideally it should target less boilerplate and simplicity for the user.