3 ms·
Well, local I/O, and sometimes even LAN I/O, tend to behave close to non-blocking. The latency is very small, unless your database is under heavy load, but then
by FooBarWidget 13y ago
Well, local I/O, and sometimes even LAN I/O, tend to behave close to non-blocking. The latency is very small, unless your database is under heavy load, but then you have other problems anyway.
With blocking I/O I mean I/O calls which put the process to sleep for a while. This is in contrast to I/O calls which succeed immediately.
- jrochkind1 13y agoIn most of the web apps I've written, the majority of the request-response latency is waiting on the database, rather than cpu. I _think_ this is not uncommon? In other contexts, people talk about "non-blocking IO" and "blocking IO" to mean, well, 'blocking IO' is where the process or thread is _not_ put to sleep, it's not being switched out _even though_ it's waiting on IO. For instance, most ruby database drivers used to be broken in this way with respect to multi-threading, but were fixed to be "non-blocking IO", so threads would actually be unscheduled (even in MRI) when waiting on IO. For examples of this use of "blocking IO" vs "non-blocking IO" see http://en.wikipedia.org/wiki/Asynchronous_I/O http://en.wikipedia.org/wiki/Asynchronous_I/O (Ha, look what wikipedia URL did to "I/O"). That usage is pretty common, so I think your different use of 'blocking IO' is confusing.