What OS? You may need to tune loopback interface to handle the throughput. If 
you're putting 50k messages / sec you can consider that roughly 100k packets 
per sec. Is the system tuned for that? If it isn't tuned it could be that 
you're hitting a bottleneck there and unable to saturate the system.

On a more broad note though this isn't the best way to gauge performance. You 
really want to gauge what your configuration can do a production levels, that 
is some level less than fully saturated. I would target somewhere between 50% 
-75% depending on how much burst capacity you would like. You would never want 
to go to production where the system is running above 80% constantly because 
you have very little room for bursting and will easily tip over the system with 
the slightest hiccups.

-Jake


Sent from my iPhone

> On Jun 9, 2017, at 9:15 AM, Xu, Nan <[email protected]> wrote:
> 
> Thanks for pointing this out, very useful. 
>  
> I change the way I test the performance and get a result I can NOT explain.
>  
> I use 2 separate virtual machine.  1 run client, 1 run server, both siting on 
> the same physical box.
>  
> The client put small message (about 10 bytes) as quick as possible through 
> 128 threads. Both client and server have the conserve_socket=false
>  
> I can see there are 128 tcp connections between them and I send about 50,000 
> message/s
>  
> Server have 4 core and 3 out of 4 is constantly 100%, but one core is only 
> 30%. On the server, I only run 1 locator and 1 server and no other program.  
> Region is PARTITION. I publish about 2000 keys.
>  
> Why there is a core only 30%. My Point is, if I can use the last core more, I 
> might able to publisher even quicker.
>  
> Thanks,
> Nan
>  
> From: Akihiro Kitada [mailto:[email protected]] 
> Sent: Thursday, June 08, 2017 7:13 PM
> To: [email protected]
> Subject: Re: Geode Performance how to push the cpu to 100%?
>  
> Hello Nan,
>  
> Why don't you check Geode statistics
>  
> http://geode.apache.org/docs/guide/11/reference/statistics/statistics_list.html
>  
> Maybe, disk I/O or some other causes could be involved...
>  
> 
>  
> --
> Akihiro Kitada  |  Staff Customer Engineer |  +81 80 3716 3736 
> Support.Pivotal.io  |  Mon-Fri  9:00am to 5:30pm JST  |  1-877-477-2269
>      
>  
>  
> 2017-06-09 6:09 GMT+09:00 Xu, Nan <[email protected]>:
> Hi,
>  
>    I am trying to see the limit of geode performance.
>  
> Here is what I did.
>  
> Single machine:  OS: centos 7.     8 core.   2.6G.  
>  
> Create a single locator  and a single server and a single region. 
>  
> Only configuration is
> Server conserve-sockets= false
> Region is    PARTITION
> Client and server running on the same machine.
>  
>  
> In my client.  I setup a 16 thread pool to get data.  But I can only push the 
> cpu to around 90—93% on the centos.
>  
> Why I cannot push it to 100%? I am suspecting
> 1.       The tcp connection between the server and client is not fast enough. 
> Maybe increase the number of tcp connection?  I only see one connection 
> between client and server.
> 
> 2.       There are some lock at the server?  I realize that I can push the 
> cpu from 50% to 90 by just adding the setPoolThreadLocalConnections(true), so 
> maybe there are some other setting I am missing.
> 
>  
> Thanks,
> Nan
>  
> Client side program.
>  
> val cache: ClientCache = new ClientCacheFactory().addPoolLocator(host, 10334)
>     .set("log-level", "info")
>     .set("conserve-sockets", "false")
>     .setPoolMinConnections(4)
>     .setPoolMaxConnections(12)
>     .setPoolThreadLocalConnections(true)
>     .create
>  
>   val regionFactory: ClientRegionFactory[String, String] = 
> cache.createClientRegionFactory(ClientRegionShortcut.PROXY)
>   val region1: Region[String, String] = regionFactory.create(region)
>  
>   implicit val ec = 
> ExecutionContext.fromExecutorService(Executors.newFixedThreadPool(16))
>   var j = new AtomicLong(0)
>   for (i <- 1 to 16) yield Future {
>     while(true){
>       val cj = j.addAndGet(1)
>       region1.get("" + (rnd.nextInt(2000) + 1))
>     }
>   }
>  
>  
>  
> This message, and any attachments, is for the intended recipient(s) only, may 
> contain information that is privileged, confidential and/or proprietary and 
> subject to important terms and conditions available at 
> http://www.bankofamerica.com/emaildisclaimer. If you are not the intended 
> recipient, please delete this message.
>  
> This message, and any attachments, is for the intended recipient(s) only, may 
> contain information that is privileged, confidential and/or proprietary and 
> subject to important terms and conditions available at 
> http://www.bankofamerica.com/emaildisclaimer. If you are not the intended 
> recipient, please delete this message.

Reply via email to