Rapidly starting and stopping ignite for integration tests

classic Classic list List threaded Threaded
3 messages Options
Kristian Rosenvold Kristian Rosenvold
Reply | Threaded
Open this post in threaded view
|

Rapidly starting and stopping ignite for integration tests

After adding Ignite to some of our project-specific integration tests,
I was not overly happy with the performance hit this gave us. I
tweaked around a bit, and was able to find a couple of things;

- Switch to TcpDiscoverySharedFsIpFinder to avoid network service discovery.
- Reduce initial size of cache through config#setStartSize(100), since
most testcases are small.

This appears to have *some* effect although I would hardly
characterize it as wonderful, anyone else have any tips ?

Kristian
bearrito bearrito
Reply | Threaded
Open this post in threaded view
|

Re: Rapidly starting and stopping ignite for integration tests

I'm not sure how rapidly you are starting and stopping Ignite or what facilities you are using. Are you using JUnit like functionality? 

I'm made sure to start/stop ignite only once with a class level fixture and setup/teardown only caches' between tests.

-b

On Tue, Jun 14, 2016 at 8:05 AM, Kristian Rosenvold <[hidden email]> wrote:
After adding Ignite to some of our project-specific integration tests,
I was not overly happy with the performance hit this gave us. I
tweaked around a bit, and was able to find a couple of things;

- Switch to TcpDiscoverySharedFsIpFinder to avoid network service discovery.
- Reduce initial size of cache through config#setStartSize(100), since
most testcases are small.

This appears to have *some* effect although I would hardly
characterize it as wonderful, anyone else have any tips ?

Kristian

Denis Magda Denis Magda
Reply | Threaded
Open this post in threaded view
|

Re: Rapidly starting and stopping ignite for integration tests

In reply to this post by Kristian Rosenvold
Hi Kristian,

For testing purposes you can use static IP finder [1] with lists of predefined addresses. Static IP finders are widely used by Ignite unit tests. 

Also you can reduced partitions number per cache and IgniteSystemProperties.IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE. More info is here

Next, please consider this topics

Finally, you can avoid nodes restart, caches recreation if it’s ok for you to reuse them among test runs. You can also refer to Ignite unit tests to see something useful.

Denis

[1] https://apacheignite.readme.io/v1.6/docs/cluster-config#static-ip-based-discovery
On Jun 14, 2016, at 3:05 PM, Kristian Rosenvold <[hidden email]> wrote:

After adding Ignite to some of our project-specific integration tests,
I was not overly happy with the performance hit this gave us. I
tweaked around a bit, and was able to find a couple of things;

- Switch to TcpDiscoverySharedFsIpFinder to avoid network service discovery.
- Reduce initial size of cache through config#setStartSize(100), since
most testcases are small.

This appears to have *some* effect although I would hardly
characterize it as wonderful, anyone else have any tips ?

Kristian