2. My experience
• 10 years of web development
• 2009-2012 own projects
• 3 years of NodeJS on production, starting
from earliest versions
• Full-stack-JS projects
3. Eventr, 2010
• Have ~70k RSS/Atom up to date
• Tricky TTL logic
• ~10 feeds per second (in peak)
• A lot of I/O, less CPU
• On PHP was a lot of processes, and a lot of
redundancy
• http://habrahabr.ru/post/95526/
4. Eventr, 2010
• NodeJS v0.1.x
• Rewritten feeds updating on Node
• Performance x25 vs PHP
• Despite the newness of technology, it was
successful
5. Tactoom, 2011
• Being inspired, I decided to write the next
project completely on JS
• NodeJS v0.4.x
• It was a failure, the technology wasn’t
justified in this context
• http://habrahabr.ru/post/130345/
6. NodeJS, 2012
• Successful experience with NodeJS
• Realtime solutions for IP-telephony
• Big data exchange on S3
7. Efficient use of NodeJS
• NodeJS is easy-going, but it's unpredictable
outside of your laptop
• NodeJS though seems to be multipurpose,
but for my opinion, has a rather narrow
scope of effective usage
• You better not use NodeJS in cases where
Ruby, PHP, etc. will do it easily
8. Mythology
Node.js is a platform built on Chrome's JavaScript runtime for easily
building fast, scalable network applications. Node.js uses an event-
driven, non-blocking I/O model that makes it lightweight and
efficient, perfect for data-intensive real-time applications that run
across distributed devices.
(c) nodejs.org
9. Fast?
• V8 - yes, fast, but this speed is not the main
bottleneck today
• non-blocking I/O - makes sense, if you really
have a lot of I/O
10. A typical task
User’s page
• Display a page with following data:
1. Posts
2. Following
3. Followers
11. Arithmetics
User’s page: Ti me
• db.getUserFeed() CPU
10%
• db.getUserFollowing()
• db.getUserFollowers()
I/O
Time: 90%
• I/O - query to DB
• CPU - handling data
15. Arithmetics
120ms 50ms
S e qu en ti al Parallel
5+3+4=
12ms
CPU
10% CPU
21%
I/O
I/O 79%
90%
CPU utilization
16. Arithmetics
Your laptop Production
CPU
21%
CPU
100%
I/O
79%
While CPU is free,
parallelism is efficient
17. Arithmetics
concurrency
CPU 21% ~ Response time
benchmark expected real
ab -n 1 -c 1 50ms 52ms
ab -n 100 -c 1 50ms 50ms
ab -n 100 -c 10 50ms 123ms
x2
ab -n 100 -c 100 50ms 981ms
x20
https://github.com/0ctave/node-bench 120ms x 8
18. Arithmetics
concurrency
CPU Response time Response time under load
21% 50ms 981ms
10% 120ms 1212ms
+23%
ab -n 100 -c 100
http://www.slideshare.net/yurabogdanov/nodejs-8223169
19. Arithmetics
PHP NodeJS
Time
CPU/IO CPU I/O
thread thread threads
20. Arithmetics
conclusions
• As more I/O part, as more profitable to use
NodeJS
• And vice-versa :)
• Parallelism within a single request does
nothing (under load)
• That is, synchronous Ruby have done better
with given task
• But there are other problems...
21. Language & Platform
• JavaScript is super flexible, which is not
always an advantage for the server
technology
• There are many non-obvious nuances of
the technology itself, which must always be
considered
• In the absence of a clear convention it’s
difficult to design a great app
22. JavaScript
getUserNetwork: function(callback) {
var db = this.getDb();
userId = this.getSessionUserId();
db.getUserFollowing(userId, function(err, following){
if (err) return callback(err);
db.getUserFollowers(userId, function(err, followers){
if (err) return callback(err);
callback(null, {
following: following,
followers: followers
});
});
});
}
23. JavaScript
• CoffeeScript
• JSLint
• node --use_strict (starting from 0.9.х)
$ node --use_strict app.js
./node_modules/express/node_modules/debug/lib/debug.js:119
+ ' +' + humanize(ms) + '033[0m'
SyntaxError: Octal literals are not allowed in strict mode.
24. Language & Platform
• monkey-patching is convenient, but it
leads to difficulties when debugging
• event emitter difficult to debug and it is
often misused
• Difficult to avoid memory leaks, especially
with the use of third-party libraries
• There is no decent way to debug, especially
on production
25. Language & Platform
JavaScript is much easier on front-end:
• No multi-user aspect
• Memory leaks is not a such problem
• Less async stuff
• Mature frameworks and standards
26. Language & Platform
Bad reliability
• One process serves many request at the time
• Therefore, the error in a single request can:
• lead to loss / collision of data
• hanging the hundreds of other requests
• compromise the integrity of the system
• No guaranteed isolation stack for each request /
session (as, for example, in erlang)
27. Language & Platform
Bad reliability
CPU1 CPU2 CPU3 CPU4
node1 node2 node3 node4
-250
1,000
connections
http://mr-aleph.livejournal.com/322682.html
28. Shared state
var counter = 0;
app.get('/', function(req, res){
res.send('Counter: ' + counter);
counter++;
});
• Very convenient for a sort of tasks
• Loses favor when scaling
• Difficult to make reliable
29. So what to do with NodeJS?
• Far from users as possible
• Where thethroat" predictable, where you
can "pinch
load is
• I/O intensive, CPU free
• Do «kill -9» reliable
• have a persistence data layer
• do atomic operations
• use transactions when possible
• Not for a vital features
• Things you can not do without it
30. Yuriy Bogdanov
About.me: http://about.me/bogdanov
Github: https://github.com/0ctave
Twitter: http://twitter.com/yuriybogdanov
LinkedIn: http://linkedin.com/in/yuriybogdanov
Habrahabr: http://octave.habrahabr.ru/
Email: octave@tactoom.com
Thanks for your attention
