Hi Cyprien, Glad you solved it.
With remote and/or graph operations, specially when you add multiple edges, transaction always help. Before 2.2 transactions didn't run in parallel, but after 2.2 they can. In facts, this is my next question. Are you running on multiple threads? Best Regards, Luca Garulli Founder & CEO OrientDB LTD <http://orientdb.com/> On 5 January 2017 at 15:44, Cyprien Gottstein <gottstein.cypr...@gmail.com> wrote: > Hi, > > The scripts are in java, those are not batches, and we didn't wanted to > post it online to be perfectly honest. > > But. > > Great news, problem solved ! > > I remembered something crucial, it's mainly me who is working on the > subject and at first i wanted to run the OrientDB server on my own local > machine. Since my computer is not what i would call young and powerful, i > asked to make it run on a virtual machine in our own datacenter. I work in > France. The Datacenter is in Poland. > > What was it again ? Non-Transactionnal Mode means " for every new entity > we write it immediately on disk ", it meant for every entry we were eating > the latency between our building in France and the datacenter in Poland. > > We made a proper uber-jar to run the generation code on the very same > machine holding the Orient DB server's instance. > We did some simple benchmark to check how the total execution time would > behave depending on the transaction mode and location of the program. > > Job Place - Transactionnal : 900 secs (i don't have the real number, i > just know its around that, sorry.) > Job Place - Non-Transactionnal : more than 54000 secs > Datacenter - Transactionnal : 212 secs > Datacenter - Non-Transactionnal : 2700 secs (i don't have the real number, > i just know its around that, sorry.) > > So thanks to executing the code from the right place we avoided some HUGE > loss of times. The Non-Transactionnal mode is slower but your promess was > kept, it runs with a constant amount of RAM, that means if we want to > generate 10 millions or even 50 millions of entities we can in a > reasonnable time so i would guess it's fine. > > Last question and i think this case will be closed (at least for me) : > > The OrientDB Documentation warns in http://orientdb.com/docs/last/ > Performance-Tuning.html#wise-use-of-transactions that : > > "Transactions slow down massive inserts unless you're using a "remote" >> connection. In that case it speeds up all the insertion because the >> client/server communication happens only at commit time." >> > > We can indeed see it in effect when we run our little benchmark > (Transactionnal - 212 VS Non-Transactionnal 2700) , are we in a difference > of speed that is to be expected ? Or does something still feels off ? > > Thanks again for your time, > > Cyprien Gottstein > > -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to orient-database+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
