You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Alexey Goncharuk <al...@gmail.com> on 2016/11/28 16:38:03 UTC
Re: Performance question
Hi Alisher,
As Nicolae suggested, try parallelizing your scan using per-partition
iterator. This should give you almost linear performance growth up to the
number of available CPUs.
Also make sure to set CacheConfiguration#copyOnRead flag to false.
--AG
2016-11-28 19:31 GMT+03:00 Marasoiu Nicolae <Ni...@cegeka.com>:
> Regarding CPU load, a single thread of execution exists in the program so
> (at most) one core is used. So if you have 8 cores, it means that it is 8
> to 16 times slower than a program able to use all the cores & CPU
> redundancy of the machine.
>
> In my tests, indeed, a core looks fully utilized. To me, scanning 1M
> key-values per second is pretty ok, but indeed, if LMAX got 6M transactions
> per core per second, it can perhaps go up, but something tells me this will
> not be the limitation of the typical application.
>
>
> Met vriendelijke groeten / Meilleures salutations / Best regards
>
> *Nicolae Marasoiu*
> *Agile Developer*
>
> *E* *Nicolae.Marasoiu@cegeka.com <Ni...@cegeka.com>*
>
> CEGEKA 15-17 Ion Mihalache Blvd. Tower Center Building,
> 4th,5th,6th,8th,9th fl
> RO-011171 Bucharest (RO), Romania
> *T* +40 21 336 20 65
> *WWW.CEGEKA.COM <http://www.cegeka.com>* [image: LinkedIn]
> <https://www.linkedin.com/company/cegeka-romania>
> ------------------------------
> *De la:* Alisher Alimov <al...@gmail.com>
> *Trimis:* 28 noiembrie 2016 15:27
> *Către:* user@ignite.apache.org
> *Subiect:* Performance question
>
> Hello!
>
> I have write and run a simple performance test to check
> IgniteCache#localEntries and found that current method is not enough fast.
>
> Ignite ignite = Ignition.start();
>
>
> CacheConfiguration<UUID, UUID> cacheConfiguration = new CacheConfiguration<>();
> cacheConfiguration.setBackups(0);
>
> IgniteCache<UUID, UUID> cache = ignite.getOrCreateCache("test.cache");
>
> for (int i = 0; i < 1_000_000; i++) {
> cache.put(UUID.randomUUID(), UUID.randomUUID());
> }
>
> long startTime = System.currentTimeMillis();
>
> cache.localEntries(CachePeekMode.PRIMARY).forEach(entry -> {
> });
>
> System.out.println(String.format("Complete in: %dms", System.currentTimeMillis() - startTime));
>
>
> Reading local entries take about 1s (1000 rows per ms) that’s is low.
> Test was run on server with provided configuration with default Ignite
> configs, load average was about 0 and CPU was not busy more than 10%
> Intel(R) Xeon(R) CPU E5645 @ 2.40GHz
>
>
> May be I do or configure something wrong or current speed is normal?
>
>
> With best regards
> Alisher Alimov
> alimovalisher@gmail.com
>
>
>
>
>
Re: Performance question
Posted by Alisher Alimov <al...@gmail.com>.
> int[] partitions =
> this.ignite.affinity("test.cache").primaryPartitions(this.ignite.cluster().node());
>
> cluster().node() returns a random node from the group, it should be
> localNode() instead if I understand your approach correctly.
Because I have only one node in cluster, current method will return instance of local node.
> I would also try to manually start threads to make sure that parallelization
> works properly. I'm not sure how it works if you use streams.
Parallel stream will use fork join model and use more than 1 CPU
Here is screenshot from profiler
I have tried to use Executor but I didn't achieve more performance
With best regards
Alisher Alimov
alimovalisher@gmail.com <ma...@gmail.com>
> On 29 Nov 2016, at 00:52, vkulichenko <valentin.kulichenko@gmail.com <ma...@gmail.com>> wrote:
>
> Alisher,
>
> This line does not look correct to me:
>
> int[] partitions =
> this.ignite.affinity("test.cache").primaryPartitions(this.ignite.cluster().node());
>
> cluster().node() returns a random node from the group, it should be
> localNode() instead if I understand your approach correctly.
>
> I would also try to manually start threads to make sure that parallelization
> works properly. I'm not sure how it works if you use streams.
>
> -Val
>
>
>
> --
> View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Performance-question-tp9218p9239.html <http://apache-ignite-users.70518.x6.nabble.com/Performance-question-tp9218p9239.html>
> Sent from the Apache Ignite Users mailing list archive at Nabble.com <http://nabble.com/>.
Re: Performance question
Posted by vkulichenko <va...@gmail.com>.
Alisher,
This line does not look correct to me:
int[] partitions =
this.ignite.affinity("test.cache").primaryPartitions(this.ignite.cluster().node());
cluster().node() returns a random node from the group, it should be
localNode() instead if I understand your approach correctly.
I would also try to manually start threads to make sure that parallelization
works properly. I'm not sure how it works if you use streams.
-Val
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Performance-question-tp9218p9239.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Performance question
Posted by vkulichenko <va...@gmail.com>.
Alisher,
Since you're scanning the cache, time will always depend on number of
entries and amount of CPU resources, so it's really hard to tell whether
your result is good or bad. Having said that, the only effective way to
improve this is to scale. If you add more nodes with the same dataset, you
should have almost linear performance improvement.
-Val
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Performance-question-tp9218p9273.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Performance question
Posted by Alisher Alimov <al...@gmail.com>.
In according to your suggestions I try to rewrite benchmark tests using jmh, here is link benchmark: https://github.com/aysheka/ignite-benchmarks/blob/master/test/src/test/java/com/example/ignite/IgniteCacheLocalReadTest.java <https://github.com/aysheka/ignite-benchmarks>
Warmup partially resolve problem with cold start and speed was increased up to 40% but I don’t think that it’s enough good.
Now reading 1 million records take about 200 ms (~5000 entries per ms) can I improve this parameters and how?
With best regards
Alisher Alimov
alimovalisher@gmail.com
> On 29 Nov 2016, at 11:41, Yakov Zhdanov <yz...@apache.org> wrote:
>
> I think it is a bad idea to set number of threads greater than CPU count given you do not block on any IO operations
>
> However, benchmark itself seems totally incorrect to me. The most important issues are
> 1. total time is too low. try to put it to a loop body and measure each iterations. you can also (moreover, I would like you to) use jmh for local operations benchmarks
> 2. you don't have any warm up phase.
>
> Please refer to http://stackoverflow.com/questions/504103/how-do-i-write-a-correct-micro-benchmark-in-java <http://stackoverflow.com/questions/504103/how-do-i-write-a-correct-micro-benchmark-in-java> or any other resource explaining on how to create benchmarks.
>
> --Yakov
>
> 2016-11-29 15:14 GMT+07:00 Vladislav Pyatkov <vldpyatkov@gmail.com <ma...@gmail.com>>:
> Hi Alisher,
>
> It look doubt for me. You parallelize the job, but got a performance decrease.
> I recommend to use a java profiler and try to separate long time methods.
>
> How are you get a list of local partition (can it contain excess numbers)?
> And please check, has forckjoin pool enough size:
>
> -Djava.util.concurrent.ForkJoinPool.common.parallelism=1024
>
>
> On Nov 28, 2016 8:39 PM, "Alisher Alimov" <alimovalisher@gmail.com <ma...@gmail.com>> wrote:
> I found only one way to parallelize read via ScanQuery
>
> int[] partitions = this.ignite.affinity("test.cache").primaryPartitions(this.ignite.cluster().node());
>
> startTime = System.currentTimeMillis();
>
> Arrays.stream(partitions)
> .parallel()
> .forEach(partition -> {
> ScanQuery<Object, Object> qry = new ScanQuery<>(partition);
> qry.setLocal(true);
> qry.setPageSize(5_000);
>
> QueryCursor<Cache.Entry<Object, Object>> query = cache.query(qry);
> List<Cache.Entry<Object, Object>> all = query.getAll();
> });
>
> System.out.println(String.format("Complete in: %dms", System.currentTimeMillis() - startTime));
>
> But it’s doesn’t help a lot (speed was downgrade on 10-20%) or there is another good solution to do it?
>
>
>
> With best regards
> Alisher Alimov
> alimovalisher@gmail.com <ma...@gmail.com>
>
>
>
>
>> On 28 Nov 2016, at 19:38, Alexey Goncharuk <alexey.goncharuk@gmail.com <ma...@gmail.com>> wrote:
>>
>> Hi Alisher,
>>
>> As Nicolae suggested, try parallelizing your scan using per-partition iterator. This should give you almost linear performance growth up to the number of available CPUs.
>> Also make sure to set CacheConfiguration#copyOnRead flag to false.
>>
>> --AG
>>
>> 2016-11-28 19:31 GMT+03:00 Marasoiu Nicolae <Nicolae.Marasoiu@cegeka.com <ma...@cegeka.com>>:
>> Regarding CPU load, a single thread of execution exists in the program so (at most) one core is used. So if you have 8 cores, it means that it is 8 to 16 times slower than a program able to use all the cores & CPU redundancy of the machine.
>> In my tests, indeed, a core looks fully utilized. To me, scanning 1M key-values per second is pretty ok, but indeed, if LMAX got 6M transactions per core per second, it can perhaps go up, but something tells me this will not be the limitation of the typical application.
>>
>> Met vriendelijke groeten / Meilleures salutations / Best regards
>>
>> Nicolae Marasoiu
>> Agile Developer
>>
>> E Nicolae.Marasoiu@cegeka.com <ma...@cegeka.com>
>>
>> CEGEKA 15-17 Ion Mihalache Blvd. Tower Center Building, 4th,5th,6th,8th,9th fl
>> RO-011171 Bucharest (RO), Romania
>> T +40 21 336 20 65
>> WWW.CEGEKA.COM <http://www.cegeka.com/> <https://www.linkedin.com/company/cegeka-romania>
>> De la: Alisher Alimov <alimovalisher@gmail.com <ma...@gmail.com>>
>> Trimis: 28 noiembrie 2016 15:27
>> Către: user@ignite.apache.org <ma...@ignite.apache.org>
>> Subiect: Performance question
>>
>> Hello!
>>
>> I have write and run a simple performance test to check IgniteCache#localEntries and found that current method is not enough fast.
>>
>> Ignite ignite = Ignition.start();
>>
>> CacheConfiguration<UUID, UUID> cacheConfiguration = new CacheConfiguration<>();
>> cacheConfiguration.setBackups(0);
>>
>> IgniteCache<UUID, UUID> cache = ignite.getOrCreateCache("test.cache");
>>
>> for (int i = 0; i < 1_000_000; i++) {
>> cache.put(UUID.randomUUID(), UUID.randomUUID());
>> }
>>
>> long startTime = System.currentTimeMillis();
>>
>> cache.localEntries(CachePeekMode.PRIMARY).forEach(entry -> {
>> });
>>
>> System.out.println(String.format("Complete in: %dms", System.currentTimeMillis() - startTime));
>>
>> Reading local entries take about 1s (1000 rows per ms) that’s is low.
>> Test was run on server with provided configuration with default Ignite configs, load average was about 0 and CPU was not busy more than 10%
>> Intel(R) Xeon(R) CPU E5645 @ 2.40GHz
>>
>>
>> May be I do or configure something wrong or current speed is normal?
>>
>>
>> With best regards
>> Alisher Alimov
>> alimovalisher@gmail.com <ma...@gmail.com>
>>
>>
>>
>>
>>
>
>
Re: Performance question
Posted by Yakov Zhdanov <yz...@apache.org>.
I think it is a bad idea to set number of threads greater than CPU count
given you do not block on any IO operations
However, benchmark itself seems totally incorrect to me. The most important
issues are
1. total time is too low. try to put it to a loop body and measure each
iterations. you can also (moreover, I would like you to) use jmh for local
operations benchmarks
2. you don't have any warm up phase.
Please refer to
http://stackoverflow.com/questions/504103/how-do-i-write-a-correct-micro-benchmark-in-java
or any other resource explaining on how to create benchmarks.
--Yakov
2016-11-29 15:14 GMT+07:00 Vladislav Pyatkov <vl...@gmail.com>:
> Hi Alisher,
>
> It look doubt for me. You parallelize the job, but got a performance
> decrease.
> I recommend to use a java profiler and try to separate long time methods.
>
> How are you get a list of local partition (can it contain excess numbers)?
> And please check, has forckjoin pool enough size:
>
> -Djava.util.concurrent.ForkJoinPool.common.parallelism=1024
>
>
> On Nov 28, 2016 8:39 PM, "Alisher Alimov" <al...@gmail.com> wrote:
>
>> I found only one way to parallelize read via ScanQuery
>>
>> int[] partitions = this.ignite.affinity("test.cache").primaryPartitions(this.ignite.cluster().node());
>>
>> startTime = System.currentTimeMillis();
>>
>> Arrays.stream(partitions)
>> .parallel()
>> .forEach(partition -> {
>> ScanQuery<Object, Object> qry = new ScanQuery<>(partition);
>> qry.setLocal(true);
>> qry.setPageSize(5_000);
>>
>> QueryCursor<Cache.Entry<Object, Object>> query = cache.query(qry);
>> List<Cache.Entry<Object, Object>> all = query.getAll();
>> });
>>
>> System.out.println(String.format("Complete in: %dms", System.currentTimeMillis() - startTime));
>>
>>
>> But it’s doesn’t help a lot (speed was downgrade on 10-20%) or there is
>> another good solution to do it?
>>
>>
>>
>> With best regards
>> Alisher Alimov
>> alimovalisher@gmail.com
>>
>>
>>
>>
>> On 28 Nov 2016, at 19:38, Alexey Goncharuk <al...@gmail.com>
>> wrote:
>>
>> Hi Alisher,
>>
>> As Nicolae suggested, try parallelizing your scan using per-partition
>> iterator. This should give you almost linear performance growth up to the
>> number of available CPUs.
>> Also make sure to set CacheConfiguration#copyOnRead flag to false.
>>
>> --AG
>>
>> 2016-11-28 19:31 GMT+03:00 Marasoiu Nicolae <Ni...@cegeka.com>
>> :
>>
>>> Regarding CPU load, a single thread of execution exists in the program
>>> so (at most) one core is used. So if you have 8 cores, it means that it is
>>> 8 to 16 times slower than a program able to use all the cores & CPU
>>> redundancy of the machine.
>>>
>>> In my tests, indeed, a core looks fully utilized. To me, scanning 1M
>>> key-values per second is pretty ok, but indeed, if LMAX got 6M transactions
>>> per core per second, it can perhaps go up, but something tells me this will
>>> not be the limitation of the typical application.
>>>
>>>
>>> Met vriendelijke groeten / Meilleures salutations / Best regards
>>>
>>> *Nicolae Marasoiu*
>>> *Agile Developer*
>>>
>>> *E* *Nicolae.Marasoiu@cegeka.com <Ni...@cegeka.com>*
>>>
>>> CEGEKA 15-17 Ion Mihalache Blvd. Tower Center Building,
>>> 4th,5th,6th,8th,9th fl
>>> RO-011171 Bucharest (RO), Romania
>>> *T* +40 21 336 20 65
>>> *WWW.CEGEKA.COM <http://www.cegeka.com/>* [image: LinkedIn]
>>> <https://www.linkedin.com/company/cegeka-romania>
>>> ------------------------------
>>> *De la:* Alisher Alimov <al...@gmail.com>
>>> *Trimis:* 28 noiembrie 2016 15:27
>>> *Către:* user@ignite.apache.org
>>> *Subiect:* Performance question
>>>
>>> Hello!
>>>
>>> I have write and run a simple performance test to check
>>> IgniteCache#localEntries and found that current method is not enough fast.
>>>
>>> Ignite ignite = Ignition.start();
>>>
>>>
>>> CacheConfiguration<UUID, UUID> cacheConfiguration = new CacheConfiguration<>();
>>> cacheConfiguration.setBackups(0);
>>>
>>> IgniteCache<UUID, UUID> cache = ignite.getOrCreateCache("test.cache");
>>>
>>> for (int i = 0; i < 1_000_000; i++) {
>>> cache.put(UUID.randomUUID(), UUID.randomUUID());
>>> }
>>>
>>> long startTime = System.currentTimeMillis();
>>>
>>> cache.localEntries(CachePeekMode.PRIMARY).forEach(entry -> {
>>> });
>>>
>>> System.out.println(String.format("Complete in: %dms", System.currentTimeMillis() - startTime));
>>>
>>>
>>> Reading local entries take about 1s (1000 rows per ms) that’s is low.
>>> Test was run on server with provided configuration with default Ignite
>>> configs, load average was about 0 and CPU was not busy more than 10%
>>> Intel(R) Xeon(R) CPU E5645 @ 2.40GHz
>>>
>>>
>>> May be I do or configure something wrong or current speed is normal?
>>>
>>>
>>> With best regards
>>> Alisher Alimov
>>> alimovalisher@gmail.com
>>>
>>>
>>>
>>>
>>>
>>
>>
Re: Performance question
Posted by Vladislav Pyatkov <vl...@gmail.com>.
Hi Alisher,
It look doubt for me. You parallelize the job, but got a performance
decrease.
I recommend to use a java profiler and try to separate long time methods.
How are you get a list of local partition (can it contain excess numbers)?
And please check, has forckjoin pool enough size:
-Djava.util.concurrent.ForkJoinPool.common.parallelism=1024
On Nov 28, 2016 8:39 PM, "Alisher Alimov" <al...@gmail.com> wrote:
> I found only one way to parallelize read via ScanQuery
>
> int[] partitions = this.ignite.affinity("test.cache").primaryPartitions(this.ignite.cluster().node());
>
> startTime = System.currentTimeMillis();
>
> Arrays.stream(partitions)
> .parallel()
> .forEach(partition -> {
> ScanQuery<Object, Object> qry = new ScanQuery<>(partition);
> qry.setLocal(true);
> qry.setPageSize(5_000);
>
> QueryCursor<Cache.Entry<Object, Object>> query = cache.query(qry);
> List<Cache.Entry<Object, Object>> all = query.getAll();
> });
>
> System.out.println(String.format("Complete in: %dms", System.currentTimeMillis() - startTime));
>
>
> But it’s doesn’t help a lot (speed was downgrade on 10-20%) or there is
> another good solution to do it?
>
>
>
> With best regards
> Alisher Alimov
> alimovalisher@gmail.com
>
>
>
>
> On 28 Nov 2016, at 19:38, Alexey Goncharuk <al...@gmail.com>
> wrote:
>
> Hi Alisher,
>
> As Nicolae suggested, try parallelizing your scan using per-partition
> iterator. This should give you almost linear performance growth up to the
> number of available CPUs.
> Also make sure to set CacheConfiguration#copyOnRead flag to false.
>
> --AG
>
> 2016-11-28 19:31 GMT+03:00 Marasoiu Nicolae <Ni...@cegeka.com>:
>
>> Regarding CPU load, a single thread of execution exists in the program
>> so (at most) one core is used. So if you have 8 cores, it means that it is
>> 8 to 16 times slower than a program able to use all the cores & CPU
>> redundancy of the machine.
>>
>> In my tests, indeed, a core looks fully utilized. To me, scanning 1M
>> key-values per second is pretty ok, but indeed, if LMAX got 6M transactions
>> per core per second, it can perhaps go up, but something tells me this will
>> not be the limitation of the typical application.
>>
>>
>> Met vriendelijke groeten / Meilleures salutations / Best regards
>>
>> *Nicolae Marasoiu*
>> *Agile Developer*
>>
>> *E* *Nicolae.Marasoiu@cegeka.com <Ni...@cegeka.com>*
>>
>> CEGEKA 15-17 Ion Mihalache Blvd. Tower Center Building,
>> 4th,5th,6th,8th,9th fl
>> RO-011171 Bucharest (RO), Romania
>> *T* +40 21 336 20 65
>> *WWW.CEGEKA.COM <http://www.cegeka.com/>* [image: LinkedIn]
>> <https://www.linkedin.com/company/cegeka-romania>
>> ------------------------------
>> *De la:* Alisher Alimov <al...@gmail.com>
>> *Trimis:* 28 noiembrie 2016 15:27
>> *Către:* user@ignite.apache.org
>> *Subiect:* Performance question
>>
>> Hello!
>>
>> I have write and run a simple performance test to check
>> IgniteCache#localEntries and found that current method is not enough fast.
>>
>> Ignite ignite = Ignition.start();
>>
>>
>> CacheConfiguration<UUID, UUID> cacheConfiguration = new CacheConfiguration<>();
>> cacheConfiguration.setBackups(0);
>>
>> IgniteCache<UUID, UUID> cache = ignite.getOrCreateCache("test.cache");
>>
>> for (int i = 0; i < 1_000_000; i++) {
>> cache.put(UUID.randomUUID(), UUID.randomUUID());
>> }
>>
>> long startTime = System.currentTimeMillis();
>>
>> cache.localEntries(CachePeekMode.PRIMARY).forEach(entry -> {
>> });
>>
>> System.out.println(String.format("Complete in: %dms", System.currentTimeMillis() - startTime));
>>
>>
>> Reading local entries take about 1s (1000 rows per ms) that’s is low.
>> Test was run on server with provided configuration with default Ignite
>> configs, load average was about 0 and CPU was not busy more than 10%
>> Intel(R) Xeon(R) CPU E5645 @ 2.40GHz
>>
>>
>> May be I do or configure something wrong or current speed is normal?
>>
>>
>> With best regards
>> Alisher Alimov
>> alimovalisher@gmail.com
>>
>>
>>
>>
>>
>
>
Re: Performance question
Posted by Alisher Alimov <al...@gmail.com>.
I found only one way to parallelize read via ScanQuery
int[] partitions = this.ignite.affinity("test.cache").primaryPartitions(this.ignite.cluster().node());
startTime = System.currentTimeMillis();
Arrays.stream(partitions)
.parallel()
.forEach(partition -> {
ScanQuery<Object, Object> qry = new ScanQuery<>(partition);
qry.setLocal(true);
qry.setPageSize(5_000);
QueryCursor<Cache.Entry<Object, Object>> query = cache.query(qry);
List<Cache.Entry<Object, Object>> all = query.getAll();
});
System.out.println(String.format("Complete in: %dms", System.currentTimeMillis() - startTime));
But it’s doesn’t help a lot (speed was downgrade on 10-20%) or there is another good solution to do it?
With best regards
Alisher Alimov
alimovalisher@gmail.com
> On 28 Nov 2016, at 19:38, Alexey Goncharuk <al...@gmail.com> wrote:
>
> Hi Alisher,
>
> As Nicolae suggested, try parallelizing your scan using per-partition iterator. This should give you almost linear performance growth up to the number of available CPUs.
> Also make sure to set CacheConfiguration#copyOnRead flag to false.
>
> --AG
>
> 2016-11-28 19:31 GMT+03:00 Marasoiu Nicolae <Nicolae.Marasoiu@cegeka.com <ma...@cegeka.com>>:
> Regarding CPU load, a single thread of execution exists in the program so (at most) one core is used. So if you have 8 cores, it means that it is 8 to 16 times slower than a program able to use all the cores & CPU redundancy of the machine.
> In my tests, indeed, a core looks fully utilized. To me, scanning 1M key-values per second is pretty ok, but indeed, if LMAX got 6M transactions per core per second, it can perhaps go up, but something tells me this will not be the limitation of the typical application.
>
> Met vriendelijke groeten / Meilleures salutations / Best regards
>
> Nicolae Marasoiu
> Agile Developer
>
> E Nicolae.Marasoiu@cegeka.com <ma...@cegeka.com>
>
> CEGEKA 15-17 Ion Mihalache Blvd. Tower Center Building, 4th,5th,6th,8th,9th fl
> RO-011171 Bucharest (RO), Romania
> T +40 21 336 20 65
> WWW.CEGEKA.COM <http://www.cegeka.com/> <https://www.linkedin.com/company/cegeka-romania>
> De la: Alisher Alimov <alimovalisher@gmail.com <ma...@gmail.com>>
> Trimis: 28 noiembrie 2016 15:27
> Către: user@ignite.apache.org <ma...@ignite.apache.org>
> Subiect: Performance question
>
> Hello!
>
> I have write and run a simple performance test to check IgniteCache#localEntries and found that current method is not enough fast.
>
> Ignite ignite = Ignition.start();
>
> CacheConfiguration<UUID, UUID> cacheConfiguration = new CacheConfiguration<>();
> cacheConfiguration.setBackups(0);
>
> IgniteCache<UUID, UUID> cache = ignite.getOrCreateCache("test.cache");
>
> for (int i = 0; i < 1_000_000; i++) {
> cache.put(UUID.randomUUID(), UUID.randomUUID());
> }
>
> long startTime = System.currentTimeMillis();
>
> cache.localEntries(CachePeekMode.PRIMARY).forEach(entry -> {
> });
>
> System.out.println(String.format("Complete in: %dms", System.currentTimeMillis() - startTime));
>
> Reading local entries take about 1s (1000 rows per ms) that’s is low.
> Test was run on server with provided configuration with default Ignite configs, load average was about 0 and CPU was not busy more than 10%
> Intel(R) Xeon(R) CPU E5645 @ 2.40GHz
>
>
> May be I do or configure something wrong or current speed is normal?
>
>
> With best regards
> Alisher Alimov
> alimovalisher@gmail.com <ma...@gmail.com>
>
>
>
>
>