sorry,didn't get you. are you suggesting to do it in same process ? On Saturday, July 5, 2014 4:39:58 PM UTC+5:45, Michael Hunger wrote: > > Can you try it to with an embedded setup? > > Sent from mobile device > > Am 05.07.2014 um 12:19 schrieb ashish jindal <[email protected] > <javascript:>>: > > it is hosted as a webapp in tomcat7 with maxThreads = 100 and > minSpareThreads = 10 > and the load test shoots N threads > using java.util.concurrent.ExecutorService with fixed size of N threads. > > On Saturday, July 5, 2014 2:34:31 PM UTC+5:45, Michael Hunger wrote: >> >> How do you schedule the threads? >> >> Sent from mobile device >> >> Am 05.07.2014 um 10:28 schrieb ashish jindal <[email protected]>: >> >> Hi Michael, >> I tried what you suggested, it has increased the performance by a factor >> of ~5 but the time spent still increase linearly with the number of threads. >> >> On Saturday, July 5, 2014 2:22:47 AM UTC+5:45, ashish jindal wrote: >>> >>> let me try that. >>> >>> On Saturday, July 5, 2014 2:15:38 AM UTC+5:45, Michael Hunger wrote: >>>> >>>> I just saw. ... If you have already n >>>> >>>> Then it should be much faster to check outgoing rels by property than a >>>> index lookup. >>>> >>>> Sent from mobile device >>>> >>>> Am 04.07.2014 um 22:25 schrieb ashish jindal <[email protected]>: >>>> >>>> yes, each thread has its own transaction. >>>> >>>> On Saturday, July 5, 2014 2:08:45 AM UTC+5:45, Michael Hunger wrote: >>>>> >>>>> But tge tx is created per thread? >>>>> >>>>> >>>>> >>>>> Sent from mobile device >>>>> >>>>> Am 04.07.2014 um 22:20 schrieb ashish jindal <[email protected]>: >>>>> >>>>> It is in a single transaction, which is on the outermost layer. >>>>> >>>>> On Saturday, July 5, 2014 2:01:44 AM UTC+5:45, Michael Hunger wrote: >>>>>> >>>>>> What is your transactional scope? >>>>>> >>>>>> Michael >>>>>> >>>>>> Sent from mobile device >>>>>> >>>>>> Am 04.07.2014 um 22:06 schrieb ashish jindal <[email protected]>: >>>>>> >>>>>> Hi Michael, >>>>>> number of rels returned is 10-50 . Yes, i close the hits iterator as >>>>>> soon as its purpose is served. >>>>>> >>>>>> On Saturday, July 5, 2014 1:08:09 AM UTC+5:45, Michael Hunger wrote: >>>>>>> >>>>>>> How many rels are returned from the call? >>>>>>> >>>>>>> Do you close the hits afterwards to release resources? >>>>>>> >>>>>>> Sent from mobile device >>>>>>> >>>>>>> Am 04.07.2014 um 10:51 schrieb ashish jindal <[email protected]>: >>>>>>> >>>>>>> Hi, >>>>>>> I am relatively new to neo4j. I have implemented a traversal >>>>>>> algorithm using neo4j as underlying graph storage. >>>>>>> Graph has about 40K nodes and about 2M edges. >>>>>>> Using 2.1.2 community version of neo4j embedded. It is hosted as >>>>>>> service in tomcat7 with allocated 6Gb of memory on 14.04 Ubuntu. >>>>>>> Following is a piece of code which does numeric index queries. >>>>>>> >>>>>>> *RelationshipIndex numericIndex >>>>>>> = graphDb.index().forRelationships(Constants.RELATIONSHIP_INDEX);* >>>>>>> * public Relationship getRelationship(Node n, int lowerlimit, int >>>>>>> upperlimit) throws Exception {* >>>>>>> >>>>>>> >>>>>>> * long t1 = System.currentTimeMillis();* >>>>>>> * IndexHits<Relationship> hits = >>>>>>> numericIndex.query(QueryContext.numericRange("start_time", lowerlimit, >>>>>>> upperlimit, true, true), n, null);* >>>>>>> * long t2 = System.currentTimeMillis();* >>>>>>> * time_spent_in_numeric_index_queries += t2-t1; // global >>>>>>> variable* >>>>>>> * // do something on hits and return a >>>>>>> relationship from it* >>>>>>> >>>>>>> * }* >>>>>>> for a single threaded traversal time_spent_in_numeric_index_queries >>>>>>> ~= 1 sec. >>>>>>> but if i do multiple traversals ( same traversal ) in parallel , >>>>>>> time_spent_in_numeric_index_queries increases linearly . for 10 calls >>>>>>> in >>>>>>> parallel it takes ~= 5 sec. >>>>>>> Also, i am only doing read operations throughout . >>>>>>> I want to know, how does querying work? Does it each query lock the >>>>>>> entire index? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Ashish >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Neo4j" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Neo4j" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Neo4j" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Neo4j" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "Neo4j" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > For more options, visit https://groups.google.com/d/optout. > >
-- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
