
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Max,<div><br><div><div>On 12 Jun 2013, at 09:42, Max Lapshin wrote:</div><blockquote type="cite"><div>I thought that video streaming, when you need to read about half of<br>gigabyte per second from disk, repack it and write to network, is the<br>good place for mmap.<br>It was a mistake. If you get slow mmap disk read, than whole erlang<br>sticks and you get PHP-like performance when whole thread is blocked<br>for one client.<br><br></div></blockquote><div><br></div><div>Isn't that because the pread call you used was in a NIF, and therefore could block the scheulder(s) no? My thought's about the approach were initially somewhat different. The write operations were just file:write, whereas there would be no pread, but rather data would be delivered to the socket using sendfile/5, which would utilise the async thread pool if it's enabled.</div><a name="sendfile-5"></a><br><blockquote type="cite"><div>Perhaps in embedded mmap would be better when you want to save memory<br>and have 10 requests per day, but on high load mmap doesn't help.<br></div></blockquote></div><br></div><div>I'd like to handle writing hundreds of thousands of input events per second and reading at various different speeds, but supporting (reads of) up to tens of thousands per second.</div></body></html>