Aerospike performance with node.js driver (on AWS c3.2xlarge)

Client Libraries Node.js Client
1

Hi team,

I’m exploring migrating our database to AeroSpike. To test performance I created a cluster of 3 c3.2xlarge servers using 80G SSD disks (not EBS). I’m using the cluster as SSD database.

I read and implemented your suggestions on improving performance such as network configuration using the afterburner script etc.

When I test the performance I get about 1k reads/sec from every node and about 1.4k writes per node.

these numbers are not even close to what people are talking about … Any idea?

Thanks Rafi

2

How are you testing? A single thread doing inserts or reads in a loop will pretty much always be around 1-2k transactions per second.

3

in ‘thread’ you mean a single client instance or a single (in my case) node.js thread?

4

I mean an actual thread. Some of the other client drivers support multiple threads but node.js is all single-threaded and a single thread will only push about that many transactions per second.

You can try lowering the commit requirement on the cluster for a little speed up or using async without waiting on acks for lots of speedup. Either way, it’s not a limit with Aerospike, it’s just how fast threads can go.

5

Ok…so the next obvious question is how…I tried using the aerospike node.js module in jxcore but it failed…do you have any suggestions on that?

Thanks Rafi

6

Can you describe what you’re trying to measure and what kind of project you’re working on?

You know the performance of each thread, so X threads will give you X times more transactions - until you hit CPU/ram/network resources limits and and ultimately your Aerospike cluster transaction limits. Aerospike will handle plenty of transactions but such high usage is through multiple clients (like dozens of application servers with hundreds of threads each) all interacting with the same cluster.

If you’re asking about how to run multiple threads in node.js (via jxcore) then unfortunately that’s out of my expertise. I’ve changed the topic title and moved it to the node.js forum category so there should be others like @gayathri who can help.

1 Like
7

Thanks for the quick reply. The issue with jxcore is referenced since the AeroSpike driver does not load in jxcore. When I try to load it, it produces the following error:

node.js:670 var gpath = process._dlopen(module, filename); ^ Error: /var/www/node_modules/aerospike/build/Release/aerospike.node: undefined symbol: node_module_register at Object.process.dlopen as .node at Module.load (module.js:346:36) at Function.Module._load (module.js:313:12) at Module.require (module.js:378:17) at require (module.js:396:17) at Object. (/var/www/node_modules/aerospike/lib/aerospike.js:1:106) at Module._compile (module.js:519:26) at Object.Module._extensions…js (module.js:549:10) at Module.load (module.js:346:36) at Function.Module._load (module.js:313:12)

I also posted a question on the jxcore forums.

Rafi

8

Hi Rafi. In our recommendations for Amazon we mention instances in the i2 and r3 family due to their SSD, networking and other capabilities that are superior to instances from other families. Just to isolate whether the issue is mostly in how the node.js app is set up, or the EC2 instance itself, can you run the benchmark tool mentioned in the tuning section (steps 10-12) of our Amazon deployment article?

Thanks, Ronen

9

Hi Ronen,

c3.xlarge servers also have SSD drives so in this respect they are not that different from r3 servers.

Rafi

10

Hi Rafi,

That is true, but i2 offers direct-attached SSD which have higher throughput and better quality. See this related discussion thread: Documentation on recommended setup for SSD Storage Engine on Amazon EC2?

Other reasons we recommend i2 and r3 are stated in the recommendations section of the Amazon deployment article.

11

Hi Rafiton,

I’ll look into how to integrate aerospike nodejs driver with jxcore library. Meanwhile, could you look at our benchmark suite. It is implemented using native cluster object from node.js API. Cluster | Node.js v18.8.0 Documentation. The benchmark spawns so many worker process to push the load to the server. Number of worker threads spawned can be controlled. By default, the number of workers spawned is the number of cores the system has. Using this benchmark, with a single nodejs worker, on an 8GB RAM machine, the server TPS was 88-90K. If you have trouble setting up the benchmark please do let me know. And also, if you could share the code snippet you are using to measure Aerospike server TPS, it would help me debug further.

12

Hi gayathri,

unfortunately using Node.JS cluster will not work for me as I’m reading a huge set of data, analyze it and need to push the results to AeruSpike. However, I managed to get jxCore working and I’m able to split DB PUT to child processes - which works nicely.

Cheers Rafi

13

Hi Rafilton,

That’s cool. Kindly let us know, in case you need anything related to performance improvement.

Thanks

14

@rafiton,

Thanks for your update on Twitter (copied below). Looks like you are up and running nicely! Please let us know if we can help with anything else.

Cheers,

Maud (Twitter: @Mnemaudsyne)

#nosql DB update - running a week with @aerospikedb while processing 1M entries/min. All I can say is bye bye @MongoDB. Hello @aerospikedb!

— rafiton (@rafiton) June 21, 2015
15

Rafiton - I hope you enjoy our new Node client. With full asynchrony and a better interface, we expect better performance and more idiomatic node code. Let us know if you like it.

Here’s a blog post from the developer to whet your appetite: