It is not a meaningful test I believe. In your previous posting you showed
that you were only testing with one node:
final Entity u2 = new Entity(graphDb.getNodeById(1));
You are using a for-loop to read a property 1,000,000 times, one after the
other. Ignore whether it is one million or one thousand times. It
is happening sequentially, not concurrently, so only one read is happening
at a time. However, because you introduce threading, you are making 100
things happen at a time. So, only 100 reads are happening at once. I just
want to make that clear.
In your test you are reading the following property:
underlyingNode.getProperty("fansnum", 0);
Each thread of the 100 threads is reading "fansnum" from a single node, u2.
Some times it takes 15ms, but which times? Does the whole test take 250
minutes, 25 minutes, 5 minutes? Whatever time that is, you know your mean
average. You also need to know the mean average for the first, second, third
and fourth group of 250,000 reads. Also, you are logging after your read
which is making your concurrency something less than the full 100. You may
only be reading the node property 25 times concurrently while 75 threads are
busy logging. This would cause you to overestimate the performance of Neo4j!
You do not need to see the performance of any individual read (except for
the min and the max read time of all reads), so do not log until the final
output. Keep track of the system time of the fastest read and the slowest
read. As you loop and get new winners for fastest and slowest read throw out
the old read times and old system time for those reads.
Once you get a good look at basic min, max and mean average for groups of
250,000 then you will have a good idea of when the JVM and database and
caches are warmed up. Change your test to then perform enough reads to warm
everything up. Then run a concurrency test for something like 100 threads
with 1000 reads per thread. Keep track of the system times of the start and
end of each read in 100 arrays of long[2000]. At the end of the run,
calculate the min, max, mean, median, standard deviation, and quartile of
all the reads.
That test will be meaningful, but even still, it will have a
some confounding variables. Was 1000 reads enough time to really get 100
reads happening at any given time? You can compare the system times to
answer that question.
However, in the end you will find that a mutable, persistant, transactional
database is a poor substitute for an immutable, in-memory, simple Java
value. You will want to use caching in your application for the type of
scenario in your test. Regardless, if you calculate statistics on your tests
and share them maybe they will reveal a scenario where Neo4j needs to be
better.
Kind regards,
McKinley
On Tue, Sep 27, 2011 at 1:00 AM, iamyuanlong <yuanlong1...@gmail.com> wrote:
>
> run the Test you will found get node's property will cost more then 15ms
> sometimes. May this test is not meaningful.But it can representing my
> problem. I need frequent access node's property.And I think I just read it
> ,so whatever i have how many threads, access the node's property should be
> very fast less then 1ms.
>
>
_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
