10 ms·

Question: is io_uring only worth using for writing to files, or does it provide performance benefits when reading from them, as well? I've seen database progra

by cytzol 7y ago

Question: is io_uring only worth using for writing to files, or does it provide performance benefits when reading from them, as well? I've seen database programmers rave about the speed benefits of asynchronous I/O, because they have to store a lot of data on disk. But the majority of programs I write only have to deal with reading files. I'd love to try using io_uring, but only when it's appropriate.

thristian 7y ago
Asynchronous I/O is only useful if you have something else you can be doing while you wait for file-data to arrive. For example, if you can do calculations on the part of the file you've already read while you wait for the rest to arrive, or if you can process data for one client while data from a different client is in-flight. Databases are a good example - usually they're handling queries for multiple clients at once, and even within a query they can be reading from multiple places simultaneously (like the individual tables involved in a JOIN). If your program needs to read in an entire JSON blob (for example) before it can do anything, or if it only does light processing on each individual part (like adding up a column of a CSV file) then async I/O probably isn't going to help.
- machinecoffee 7y ago
  Which would actually work nicely with a fibres library, so you can yield while you're waiting for the io to complete.
yxhuvud 7y ago
You can for example read from multiple files simultaneously. You can also build web servers that read from disk as part of the request handling, without having to do blocking file reads. Before io_uring, this scenario would get absolutely horrible performance as the whole thread would lock down while waiting for the file read. Now you can do other things concurrently.
- cmsd2 7y ago
  it looks like in the future it might be a better way of implementing khttpd by handing over from a userspace control program the accept->read->sendfile->close sequence of async operations to the kernel
willvarfar 7y ago
Imagine a database trying to solve SELECT client_id, invoice_id, invoice_status, invoice_date FROM invoices WHERE client_id IN (123, 567) AND invoice_status != 'PAID'; Imagine that there is an index for client_id. The DB engine can scan the index, finding all the pages in the table that contain rows with one of those two client_ids in. It requests these pages as soon as it finds them in the index. It scans the pages in the order it finds them completed, though, which can be a completely different order than it requested them in.

by cytzol 7y ago

thristian 7y ago

Asynchronous I/O is only useful if you have something else you can be doing while you wait for file-data to arrive. For example, if you can do calculations on the part of the file you've already read while you wait for the rest to arrive, or if you can process data for one client while data from a different client is in-flight. Databases are a good example - usually they're handling queries for multiple clients at once, and even within a query they can be reading from multiple places simultaneously (like the individual tables involved in a JOIN). If your program needs to read in an entire JSON blob (for example) before it can do anything, or if it only does light processing on each individual part (like adding up a column of a CSV file) then async I/O probably isn't going to help.

machinecoffee 7y ago
Which would actually work nicely with a fibres library, so you can yield while you're waiting for the io to complete.

yxhuvud 7y ago

You can for example read from multiple files simultaneously. You can also build web servers that read from disk as part of the request handling, without having to do blocking file reads. Before io_uring, this scenario would get absolutely horrible performance as the whole thread would lock down while waiting for the file read. Now you can do other things concurrently.

cmsd2 7y ago
it looks like in the future it might be a better way of implementing khttpd by handing over from a userspace control program the accept->read->sendfile->close sequence of async operations to the kernel

willvarfar 7y ago

Imagine a database trying to solve SELECT client_id, invoice_id, invoice_status, invoice_date FROM invoices WHERE client_id IN (123, 567) AND invoice_status != 'PAID'; Imagine that there is an index for client_id. The DB engine can scan the index, finding all the pages in the table that contain rows with one of those two client_ids in. It requests these pages as soon as it finds them in the index. It scans the pages in the order it finds them completed, though, which can be a completely different order than it requested them in.