You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2018/12/06 05:27:00 UTC
[jira] [Commented] (GEODE-6084) Create real put benchmark for PDX
values
[ https://issues.apache.org/jira/browse/GEODE-6084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16710990#comment-16710990 ]
ASF GitHub Bot commented on GEODE-6084:
---------------------------------------
nabarunnag opened a new pull request #16: GEODE-6084: Refactored the benchmark code as per review.
URL: https://github.com/apache/geode-benchmarks/pull/16
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
> Create real put benchmark for PDX values
> ----------------------------------------
>
> Key: GEODE-6084
> URL: https://issues.apache.org/jira/browse/GEODE-6084
> Project: Geode
> Issue Type: New Feature
> Components: benchmarks
> Reporter: Dan Smith
> Assignee: nabarun
> Priority: Major
> Labels: pull-request-available
>
> We currently have a test PartitionedPutBenchmark class, but this has all threads updating the same integer key. We need to turn this into a real, reasonable benchmark of puts for Geode.
> This is the configuration we want to go for:
> *Workload time*
> As long as we need to get reasonable stddev numbers, targeting around 5 minutes or less.
> *Topology*
> Client/server, with single hop enabled and no SSL
> *Data*
> * PDX object with around a 1K serialized size.
> * Uniformly and randomly accessed/updated
> * as many entries as we can reasonably populate for a 5 minute test. Long or small string keys.
> * The data should be pre-populated before the workload starts.
> *Scale*
> * 4 servers, enough clients and threads to be utilizing 50-100% of the critical resource (CPU, network?)
> *Region Config*
> Create a test for both
> 1. Partitioned Region with redundancy 1
> 2. Replicated Regions
> *Geode Tuning*
> We should use Geode and JVM tuning parameters tuned for performance. This includes
>
> *Geode properties*
> {noformat}
> eviction-heap-percentage=65
> critical-heap-percentage=90
> archive-disk-space-limit=150
> archive-file-size-limit=10
> conserve-sockets=false
> enable-time-statistics=true
> jmx-manager=true
> jmx-manager-port=1099
> jmx-manager-start=true
> jmx-manager-update-rate=2000
> locator-wait-time=120
> log-disk-space-limit=100
> log-file-size-limit=10
> log-level=config
> remove-unresponsive-client=true
> statistic-archive-file=XXXX
> statistic-sample-rate=1000
> statistic-sampling-enabled=true
> log-file=XXXX
> distributed-system-id=0
> {noformat}
> *JVM flags*
> {noformat}
> -XX:CMSInitiatingOccupancyFraction=60
> -XX:+PrintGCDetails
> -XX:+PrintGCTimeStamps
> -XX:+PrintGCDateStamps
> -XX:+PrintGCApplicationStoppedTime
> -XX:+PrintGCApplicationConcurrentTime
> -XX:+UseGCLogFileRotation
> -XX:NumberOfGCLogFiles=20
> -XX:GCLogFileSize=1M
> -XX:+UnlockDiagnosticVMOptions
> -XX:ParGCCardsPerStrideChunk=32768
> '-XX:OnOutOfMemoryError='\''kill -9 %p'\'''
> -XX:+UseNUMA
> -XX:+UseConcMarkSweepGC
> -XX:+UseCMSInitiatingOccupancyOnly
> -XX:+CMSClassUnloadingEnabled
> -XX:+DisableExplicitGC
> -XX:+ScavengeBeforeFullGC
> -XX:+CMSScavengeBeforeRemark
> -server
> -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> -Dgemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true
> -Dgemfire.launcher.registerSignalHandlers=true
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)