Also I would like to point out that in the second test, the CPU consumption of machine hosting the memcached server was comparatively very low. Let me know if you see any problems with the way I am using memaslap.
Thanks a lot for you patience. Waiting eagerly for you help :) Regards kartik On Thursday, March 7, 2013 5:13:17 PM UTC+5:30, gcktk wrote: > > Additionally I would like to know if througput is a function of "value"'s > size? > > I did some tests using memaslap :- > > Test 1(each key's value is of 4 bytes only) > > memaslap -s 172.16.4.15:11211 -T 4 -c 200 -n 1 -x 10000000 -F > /home/kartik/config2 -d 200 > servers : 172.16.4.15:11211 > threads count: 4 > concurrency: 200 > execute number: 10000000 > windows size: 10k > set proportion: set_prop=0.01 > get proportion: get_prop=0.99 > cmd_get: 9900000 > cmd_set: 100000 > get_misses: 0 > written_bytes: 651948000 > read_bytes: 812848000 > object_bytes: 6800000 > > *Run time: 7.4s Ops: 10000000 TPS: 1358922 Net_rate: 189.8M/s* > * > * > Test 2:- Each key's value is 400 bytes :- > > memaslap -s 172.16.4.15:11211 -T 4 -c 200 -n 1 -x 10000000 -F > /home/kartik/config2 -d 200 > servers : 172.16.4.15:11211 > threads count: 4 > concurrency: 200 > execute number: 10000000 > windows size: 10k > set proportion: set_prop=0.01 > get proportion: get_prop=0.99 > cmd_get: 9900000 > cmd_set: 100000 > get_misses: 0 > written_bytes: 691748000 > read_bytes: 4753048000 > object_bytes: 46400000 > > *Run time: 40.7s Ops: 10000000 TPS: 245517 Net_rate: 127.5M/s* > > As it is clearly visible, the TPS difference is huge. Can someone explain > what TPS or throughput here means and why is there such a huge difference > in TPS when i change the size of value to be set/get? Is this because of > Network IO or does CPU L1/L2/L3 cache has anything to do with it? > > Does throughput measure the network time (and the time spent inside the > kernel or transmission etc?) as well? > > Regards > kartik > > > > > On Thursday, March 7, 2013 3:15:02 PM UTC+5:30, gcktk wrote: >> >> Hi, >> >> This is my first post on this mailing list, so please correct me if I am >> wrong. >> >> From the memcached wiki :- >> "On a fast machine with very high speed networking, memcached can easily >> handle 200,000+ requests per second." >> >> I want to do some benchmarking of memcached throughput for my >> application. Here is what I want :- >> >> 1) Store 10K keys in memcached(I want to use only a single server). Each >> "value" is only an integer(4 bytes only, not more). >> 2) After the 10K keys have been set. I want to measure the throughput of >> the following operation :- >> >> *multiget:- each multiget consisting of 200 random keys(out of the 10K >> keys already stored).* >> >> Can someone guide me how to do it? Do I need to write a test program or >> an existing load generator for memcached say memaslap will suffice for the >> above test? >> I have a 4 core machine with 16GB RAM and 1Gbps NIC which I can use for >> memcached and I have multiple machines which I can use as clients for load >> generation. >> Basically I am expecting a througput of 80K operations/sec, where >> OPERATION is what I have described above. >> >> Is this througput possible or will I need one more memcached >> machine?(since each *get* in my case consists of actually getting 100 >> keys)? Also, how to measure the average latency or each request on such a >> high load? >> Can someone point out the caveats or things I should take care of? >> >> Additionally I would like to know how the throughput of 200K+ is measured? >> Is it done using the following :- >> 1) Memcached receives a request from the socket. >> 2) Parses the command >> 3) Does the operation i.e get, set etc (in the hash table) >> 4) Creates the response >> 5) Writes it to the socket >> >> Please correct me if I am wrong. >> >> Thanks a lot for your patience :) >> >> Regards >> kartik >> > -- --- 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/groups/opt_out.
