Mailing-List: contact dev-help@geode.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geode.apache.org
From: upthewaterspout <git@git.apache.org>
To: dev@geode.apache.org
Reply-To: dev@geode.apache.org
References: <git-pr-450-geode@git.apache.org>
In-Reply-To: <git-pr-450-geode@git.apache.org>
Subject: [GitHub] geode issue #450: GEODE-2632: create ClientCachePutBench
Content-Type: text/plain
Message-Id: <20170420215852.9F24AF4A1F@git1-us-west.apache.org>
Date: Thu, 20 Apr 2017 21:58:52 +0000 (UTC)
archived-at: Thu, 20 Apr 2017 21:58:54 -0000

Github user upthewaterspout commented on the issue:

    https://github.com/apache/geode/pull/450
  
    Regarding putting JMH benchmarks in the core - seems fine. I think I originally made geode-benchmarks a separate project so it would be easy to share code and compare benchmarks between modules - eg comparing lucene to OQL queries. But putting the benchmarks in each module maybe makes more sense.
    
    This does seem to be somewhat stretching what JMH is designed for. JMH is targeted towards *microbenchmarks* so launching a separate server process seems a bit of a stretch. In particular, it's not clear to me here whether your server is getting restarted between benchmark iterations. JMH specifically tries to restart the JVM multiple times to deal with inconsistencies, but maybe only your client is getting restarted? In general I think we should probably be focusing on single VM, smaller unit benchmarks with JMH - benchmarking distributed systems might be better done with a different framework and multiple hosts.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---