Faster Node.js Application

So our users have happily deployed node.js applications to production, for months! Despite some minor issues, node.js have been proven to be quite perform, and even reliable (thanks to cluster management). Given a break, I got some chances to look at more aspects of the application, framework and beyond to squeeze out more from node. And this will be a growing list, as i hoped.

http://www.docker.io/ caught my attention as soon as my colleague first mentioned for some php deployment experiment. docker isn’t much of a performance tuning, but rather a scalability at a different level. Unfortunately, my initial test indicates that there’re noticeable overhead, possibly from the extra bridging. Nevertheless, it’s so neat, i’ll keep watching, and hope their ‘production ready’ build could arrive sooner.

service invocations are ubiquitous in a node.js application, the faster they get handled, the faster the transaction, apart from the well-known max sockets limit. i found ‘missing’ keep-alive settings could hurt badly, using ‘request’ module’s forever option, a dozen of restful/soa services calls per request got a 20%+- performance boost, without a single line of application logic change, making it an easy sell to our app developers.

soa services in addition to restful, has another problem of its own, the xml payload, parsing xml is not as trivial as parsing JSON obviously, and the node-expat lib we used was quite performant, still, we’re experimenting https://github.com/vflash/easysax for the purity of javascript and possible performance gain.

now https://github.com/msgpack/msgpack-node is a bit controversial, its saving of the bandwidth may or may not justify its deserialization cost depends on the volume of the data, for simplicity (and the fact that this is a binary module) i leave it out.

sth more fundamental would be the use of promise, we adopted promise over callbacks for a couple of reasons:

  • readability
  • error handling
  • orchestration
  • easier to explain to a java developer (yes, it’s something like Future<?>, only more powerful)

but one thing we couldn’t defy was its unpromising performance, for the Q lib we used, it’s perf wasn’t that impressive at all, and got us in trouble while arguing with some callback advocates even in the same organization. Given https://github.com/petkaantonov/bluebird, we’re much more confident of promise, even before it gets into Ecmascript spec.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s