3. Disclaimer about me
- I like both Ruby and Python, but I dislike the generator/deferred
model they implement for non-blocking I/O
- I think node.js beats them because its better wrapped, as EM
synchrony does to EM and gevent for python.
- I don't think this model is mandatory, not even migrate from
Blocking to non-blocking I/O is needed for most cases. The best
solution may not lie in code complexity. Maybe the right architecture.
- I like Erlang, the actor/message passing model and pattern
matching. Way more. And I like message queues. Specially this one:
http://www.restmq.com
4. Disclaimer about dyslexia
From wikipedia (http://en.wikipedia.org/wiki/Dyslexia):
"... Many students reach higher education before they encounter the threshold at which they are no
longer able to compensate for their learning weaknesses.
One common misconception about dyslexia is that dyslexic readers write words backwards or move
letters around when reading. In fact, this only occurs in a very small population of dyslexic readers.
Dyslexic people are better identified by writing that does not seem to match their level of
intelligence from prior observations. Additionally, dyslexic people often substitute similar-looking,
but unrelated, words in place of the ones intended (what/want, say/saw, help/held, run/fun, fell/fall,
to/too, etc.)"
5. Basics
Asynchronous I/O - Posix aio_*
Non-Blocking I/O
Select, Poll, EPoll, KQueue
Evented I/O - Abstraction over any I/O Model
Reactor - Pattern for multiplexing I/O
Future Programming
Generator
Deferred
Event Emitters
The c10k problem - http://www.kegel.com/c10k.
html
7. Scalability, not Performance
1. Performance: same work with less effort
2. Scalability: more work with more resources
3. Scientific measures for performance: How much and How fast
4. Tricks to improve performance can hurt scalability. e.g:
Map/Reduce is scalable, not fast (not suited for real time
queries)
5. Non-Blocking I/O is not an optimization for Performance
6. The time spent waiting for an external resource can be used
to other tasks, given a known introduced complexity in the
code.
7. Most of time architectural changes can avoid deeper code
changes
(1,2,3,4 - Goetz et al, Java Concurrency in Practice, M/R example is mine)
(5,6,7 - Lucindo, R. http://slidesha.re/aYz4Mk, wording on 6 is mine)