We're evaluating Aerospike as one of the in-memory NoSQL solutions. The primary goal is to have very low latency and very high ingestion rate. Environment . Aerospike 3.5.x server installed on a single machine . CentOS, 20 cores (in HT mode) , so 40 virtual cores . 125Gb memory. . This is a dedicated "bare metal" machine for Aerospike. We ingested 2 million records on this instance (each record has about 7 bins, mostly integer and a couple of string type) We're using the count UDF described on your website to get a row count. Executing a query like "aggregate count() on <ns>.<set> takes 1.4 secs as measured using aql. While this query is executing, top shows barely 3/4 cores are used out of 40 with utilization around 45%. The rest are idle. Also, most of the memory on this box is also available for use. The question is - What is preventing us from getting a millsecond response time for this miniscule data when CPU/memory are obviously not a limiting factors? Do we need to tweak any other configuration parameter? These results were captured after executing "afterburner.sh" script.