Re: Task management - MapReduce & ForkJoin performance penalty

hi @yakov yakov wrote > Try attaching @ComputeTaskNoResultCache to your task. Thank you for the hint. It speeds up task management processing drastically! -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Task management - MapReduce & ForkJoin performance penalty

yakov wrote > What are your timings now? on two local nodes, after jvm is warmed up (~100 executions), it's running in average 30ms instead of 6 sec when result is returned in return/reduce phase. This is a huge improvement! I can take it now as a basis and start adding some additional behavior

Re: Task management - MapReduce & ForkJoin performance penalty

ezhuravlev wrote > Also, maybe it's better to compare your current solution with Ignite on > some real tasks? Or at least more approximate to the real use case > > Evgenii Hi @ezhuravlev Thank you for your replay! I'm preparing more "fair" comparison with our custom made solution but it can't be

Re: Task management - MapReduce & ForkJoin performance penalty

hi @yakov yakov wrote > Yes, however, you can still return results from each job and use it. > Please > see javadoc for org.apache.ignite.compute.ComputeJobResult#getData yes, it's good to have such opportunity at least on "result" step. But still I'm very curious, why the overhead is so big

Re: Task management - MapReduce & ForkJoin performance penalty

hi @yakov Thank you for your feedback. 1. yes, warming up a jvm - this is what I missed at the begging (no doubts here at all). I can confirm that it gets better in average after few dozens of run. 2. did you mean than IgniteRunnable/IgniteCallable here (efficiency for no-op task/job)? I'd like

Re: Task management - MapReduce & ForkJoin performance penalty

hi, @ezhuravlev This is what I'm looking for, many thanks! Some hints when v2.3 is planned to be release (I can't find it on wiki)? I'd rather wait for this API in Ignite then implementing it by myself an throw it later such as I'm in evaluation/prototype phase now. Best regards, ihorps

Task management - MapReduce & ForkJoin performance penalty

Hi all [brief overview] I'm evaluating Apache Ignite framework as a replacement for Hazelcast. One of usages where it's planned to be compared is task/job processing. We have implemented tasks management by ourselves based on Hazelcast but not using their MarReduce framework (such as it was very

Re: Task management - MapReduce & ForkJoin performance penalty

It was tested on: - Windows 7 SP1 - Intel I7-4700MQ 2.40GHz - 16GB RAM - SSD - java 1.8.0_112 - Apache Ignite 2.1.0 -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Task management - MapReduce & ForkJoin performance penalty

hello So here are results for NoOpTaks + NoOpJob on two different hosts (hardware spec. is the same as mentioned above) 1. 1 Task - 100 Jobs -> ~0.1 sec 2. 1 Task - 1000 Jobs -> ~4 sec 3. 1 Task - 2000 Jobs -> ~15 sec 4. 1 Task - 3000 Jobs -> ~36 sec 5. 1 Task - 5000 Jobs -> ~96 sec --

Re: Computation best practices

hi @luqmanahmad I was thinking about it as well a little bit in my project... and I'm not sure if the cluster group is the best direction here. One way to think (probably) about efficient resource usage is to bring job stealing into your cluster. In this case you do a "default" setup where data

Re: Ignite readme.io - documentation export (pdf, etc)?

hello Prachi, thanks for the response. Yes, it would work for me now. Is the documentation for Apache Ignite 2.4 finalized already? If it's true - could you please prepare *.md export for this version? If not - I'd like to wait a bit when it's ready... Thank you in advance! -- Sent from:

Ignite readme.io - documentation export (pdf, etc)?

hi all I tried to find some option on readme.io to export Apache Ignite documentation into some static form, let's say PDF but I was not successful. Is there a way (even transitive, like in few steps) to achieve this goal? Thank you in advance! -- Sent from:

Re: Cache updates slow on Linux Vs Windows

hi all I don't have exact example but I remember that I was running once my prototype ignite app on Windows (all other cases were running under Ubuntu) and I recognized that it was "slightly" faster. I did give too much attention to it by thinking that was just my personal feel and I could be

Re: Search on a composite key

hi Mikhail Thank you for your response. Yes, I've read the documentation (provided in your link) before I posted the message here but somehow I understood that there are two ways to search on composite key: 1. Scan Queries - does the job but doesn't look efficient enough such as it we have to

Search on a composite key

hi all Could somebody advise me how to query properly from Ignite cache based on composite key condition? Let's say I have a key class: public class Key { private int countryId; private Date dateKey; ... } and a Value class: public class Value { private int value1; private boolean value2;

Re: Search on a composite key

hello to just sum it up here... I've found a page which describes some queering techniques (although it was under indexes section) - https://apacheignite-sql.readme.io/docs/schema-and-indexes. To make it run I needed to annotate my Key class like: public class Key { @QuerySqlField(index =