I just installed OpenJDK 7 on Ubuntu 10.04 LTS under VirtualBox (one core, 256 MB). I wanted to run a quick test to see how the new JDK7 Async channel APIs were performing in comparison with node. A simple test of a hello world running on a single core shows that the JVM truly has what it takes to be the best runtime for network servers. Most notably, compare the distribution of response times, especially at 99%. The advantage the JVM is showing might be enough to comfortably fit Rhino onto it.…
Quick benchmark checkpoint on Java and NodeJS
January 23, 2011 – 7:46 pm
Java (my nodejs-inspired NIO/Netty based HTTP server):
Server server = Http.createServer();
server.setRequestListener(new RequestListener() {
@Override
public void service(ServerRequest request, ServerResponse response) {
HashMap<String, String> headers = new HashMap<String, String>();
headers.put("Content-Type", "text/html; charset=utf-8");
headers.put("Content-Length", "47");
response.writeHeader(200, headers);
response.end("<html><body><h1>hüllo world</h1></body></html>");
}
});
server.listen(8080);
Javascript:
http.createServer(function(req, res) {
res.writeHead(200, {"Content-Length": "47",
"Content-Type": "text/html; charset=utf-8"});
res.write("<html><body><h1>hüllo world</h1></body></html>");
res.end();
}).listen(8080);
My quick “smoke” benchmark results using ab (MBA, 2 cores, 10.6.6, 4 GB, 2.13 GHz). First Java:
$ ab -k -n 2000 -c 200 http://localhost:8080/
Time taken for tests: 0.127 seconds
Complete requests: 2000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 2000
Total transferred: 305850 bytes
HTML transferred: 95833 bytes
Requests per second: 15693.29 [#/sec] (mean)
Time per request: 12.744 [ms] (mean)
Time per request: 0.064 [ms] (mean, across all concurrent requests)
Transfer rate: 2343.65 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 1.6 0 10
Processing: 1 5 2.9 5 16
Waiting: 1 5 2.9 5 16
Total: 1 6 3.4 5 19
and then nodejs (kriszyp/multi-node using node 0.2.5 on 2 nodes):
$ ab -k -n 2000 -c 200 http://127.0.0.1:8080/
Time taken for tests: 0.225 seconds
Complete requests: 2000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 2000
Total transferred: 300150 bytes
HTML transferred: 94047 bytes
Requests per second: 8876.38 [#/sec] (mean)
Time per request: 22.532 [ms] (mean)
Time per request: 0.113 [ms] (mean, across all concurrent requests)
Transfer rate: 1300.90 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 1.9 0 11
Processing: 0 18 3.7 18 28
Waiting: 0 18 3.7 18 28
Total: 0 18 4.5 18 39
So far, so good.…
Facebook BigPipe in an Async Servlet
July 14, 2010 – 6:44 am
Since Subbu wrote BigPipe using node.js, I had to see how the same thing would look like in a Java async servlet.
Stephan Schmidt had already written Facebook BigPipe for Java, but using a synchronous servlet model, not asynchronous. I decided to implement it using Jetty continuations and the Jetty HTTP client, but the code should be easy to adapt to servlet 3.0 AsyncContext.
The code initially constructs the page with a few empty divs that will contain the pagelets, for example:
<div id='pagelet3'></div>
I keep the connection open from the browser to the server while I render pagelets.…
On Scaling node.js to Multiple Cores
July 10, 2010 – 3:29 pm
From a thread on multicore leverage in nodejs, Edwin Khodabakchian talking about feedly:
We have an “admin” node process which is started with as input the number of “feedly” node processes it should launch and monitor. When the admin starts, it spawns multiple “feedly” node processes, padding as input the port the feedly node should listen to 9701 for the first one,…9710 for the 10th one.
On the server we have a varnish server which load balances the traffic from m.feedly.com to 127.0.0.1:9701 — 127.0.0.1:9710.
…
Nodes and Jetties
July 9, 2010 – 5:59 am
I am intrigued by node.js. Others are not so much. So they ask me, why node.js, why not Jetty, or Netty, or … ? Others say, and Twisted, and EventMachine? The core of the answer lies in a simple not well understood truth: concurrent programming is really hard. Concurrent programming using threads and locks to shared memory is extremely hard. Most programmers get concurrency wrong, since they don’t quite realize that threads actually execute simultaneously.
Functional programming languages have long understood this, and designed mechanisms to avoid the risk of a programmer getting it wrong, such as immutable data structures (take a look at java.lang.String, designed by Lee Boynton, a true Lisp guy), or message passing (erlang).…
Why node.js Matters
June 13, 2010 – 3:36 pm
Since the days when I coded my first reactor [POSA2] back at MIT, I have been convinced of the conceptual simplicity of non-blocking event driven server. Aside not blocking for I/O and being able to scale well beyond polling architectures, it is harder, sometimes impossible, to make concurrent programming mistakes with an event-driven programming paradigm. However, reactor servers never took off massively, probably because event based programming of server-side applications is a more complex programming paradigm for the average programmer than a thread- or process-per-request.…
The Linked-Atom Web
May 14, 2010 – 5:02 am
The release of Facebook’s Open Graph Protocol has spurred renewed interest in the semantic web. I give credit to Facebook for pushing forward an RDFa derived format onto the world wide web. In fact, RDFa is the least interesting part. Producing semantic data has been around for a long time. Most importantly, I give Facebook credit for focusing on the interesting part of the problem: consumption of semantic data.
And although it’s a great achievement, I regret the locked-in and centralized nature of Facebook’s Open Graph Protocol.…
Android Solves Rubik in 24 Seconds
May 9, 2010 – 4:57 pm
Update (20100524): the owner of the video has removed it. That’s the “beauty” of UGC.
…