> > > On Aug 27, 2016 1:46 AM, "dormando" <[email protected]> wrote: > >> > >> > Thank you for the tips guys! >> > >> > The limiting factor for us is actually memory utilization. We are using >> the default configuration on sizable ec2 nodes and pulling only like 20k >> qps per node. Which is fine >> > because we need to shard the key set over x servers to handle the mem >> req (30G) per server. >> > >> > I should have looked into that before posting. >> > >> > I am really curious about network saturation though. 200k gets at 1mb >> per get is a lot of traffic... how can you hit that mark without saturation? >> >> Most people's keys are a lot smaller. In multiget tests with 40 byte keys >> I can pull 20 million+ keys/sec out of the server. probably less than >> 10gbps at that rate too. Tends to cap between 600k and 800k/s if you need >> to do a full roundtrip per key fetch. limited by the NIC. Lots of tuning >> required to get around that. >> >> I think (but may be wrong) the 200K TPS result is based on 1K values. Dormando should be able to correct me.
20K TPS does seem a little low though. If you're bound by memory set size have you thought of the cost/tradeoff benefits of using dedicated servers for your memcache? I'm quite interested to find out more about what you're trying to optimise. Is it minimising number of servers, maximising query rate, both, none, etc? Feel free to reach out directly if you can't share this publicly. -- --- You received this message because you are subscribed to the Google Groups "memcached" 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.
