Node.js

compared to traditional
Java EE Application Servers

Niko Köbler

Independent Software-Architect, Developer & Trainer

niko@n-k.de            > www.n-k.de            > @dasniko

Why?

> Java app servers are dead!?

> Node.js hipster app!

> Java is slow... (and Node.js is fast?)

 

But is that all true?

Which one is faster/better/hipster?

Some research...

> Node.js performance +20% vs. Java

...but no async code in Java...!

http://blog.shinetech.com/2013/10/22/performance-comparison-between-node-js-and-java-ee/

Rock-solid foundation

Cross-compiling from one to the other

Node.js

Java

Topic winning

Remote debugging

Database queries

JSON

Solid engineering

Speed

Threads

Momentum

Ubiquity

Better IDEs

Build process simplified

Libraries

What was the challenge?

About UseCases and MicroServices

The Customer

> conservative

> anxious, frightened

> standards are 10-15 years behind

> beware of all "new" (tech bubbles)

> "enterprise chief architect"

The UseCase

> key management, use every key only once

> ~10.000.000 keys per day
   (avg. 115 req/sec, max. 900 req/sec)

> business analysts advised MongoDB

> no NoSQL database used so far

Create a MicroService!

> bounded (api) context

> independendly deployable

> own datastore (we used Redis key/value store)

> resilience (w/ use of Sentinel)

> scalable

> lightweight

> own process

I'm a JavaScript fanboy!

(server-side, not necessarily front-end!)

Let's use Node.js!

> one, lightweight, independent process

> good and easy-to-use redis/sentinel communication
   (also asnychronously)

> few lines of code

> solution was ready after 30mins of coding

No!

Unfortunately, the customer said:

But..!

I tried to convince:

You have to use Java!

> Can I use Vert.x?

> No, only JBoss EAP 6 (Java EE 6 with Java 7)

> But that's a heavy-weighted, old-fashioned application      server, and everybody is claiming:

> App Servers are dead!

> Do I really have to use such a rhinoceros for such a            small "no-brainer"?

How did we solve it?

Let's have a look into the code...

Thanks to @Suspend!

> Java EE 6 / JAX-RS 1.x doesn't support async requests

> synchronous requests result in many HTTP worker            threads

> Resteasy provides @Suspend annotation

> Asynchronous processing becomes true in JAX-RS 1.x

> For the sake of completeness:
   use an asynchronous redis connector 

 

> Node.js: 1 OS thread

> JBoss EAP: 1 JVM thread,

   only ~3 http-worker-threads used

 

> load/stress tests were performed with Gatling.io

50 threads min tps
Node.js 1ms ~2.000 req/sec
JBoss EAP 1ms ~2.000 req/sec

Where to next?

Think about...

> using more http-worker-threads

> optimizing your code/infrastructure

> scaling your services

> using Wildfly Swarm (or Spring Boot, Vert.x, whatever) instead of EAP

> ...you name it!

It doesn't matter

which technology you use.

Use it right!

Thank you!

Any Questions?

Niko Köbler

Independent Software-Architect, Developer & Trainer

niko@n-k.de            > www.n-k.de            > @dasniko

Made with Slides.com