Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thread Pools in Nginx Boost Performance 9x (2015)

nginx.com

Post reply on HN
Print view View original

21–30 of 62 posts

Re: Thread Pools in Nginx Boost Performance 9x (2015)

#21

Post by biokoda »

vbezhenar wrote: post #12
nemanjaboric wrote: post #7

Earlier quoted context omitted.

Trick is that nginx uses thread pools for non-blocking reading on the "fast" devices - you can't use coroutines/fibers, because on Linux is not reliably possible to read the regular file in a non-blocking way, as far as I'm aware, so that means that `read` in a single fiber would block entire thread until the data is fetched from the disk. In the storage engine I'm developing/maintaining, I've been using fibers, for…

Why files can't be read without blocking with Linux? There's certainly an API for this.

io_ syscalls only really work on XFS and require O_DIRECT which means kernel is not caching anything. Unsuitable for web servers.

Re: Thread Pools in Nginx Boost Performance 9x (2015)

#22

Post by vbezhenar »

nemanjaboric wrote: post #15
vbezhenar wrote: post #12

Earlier quoted context omitted.

Why files can't be read without blocking with Linux? There's certainly an API for this.

Which API are you referring to? If you're referring to `aio_` that's just glibc's user-space thread-pool emulation of the POSIX's asynchronous IO + many operations needed for the truly async IO are not supported (such as `stat` and `open`). There's `io_` syscalls family, but that's not in the ready-to-use state yet, judging by the manpages and various patches being submitted every month.

I'm referring to `fcntl(fd, F_SETFL, flags | O_NONBLOCK)`. `stat`, `open` are blocking, yes, didn't think about that. Also according to [1] file operations will always block, even in non-blocking mode, so I was wrong, sorry.

1: https://www.remlab.net/op/nonblock.shtml

Re: Thread Pools in Nginx Boost Performance 9x (2015)

#24

Post by signa11 »

vbezhenar wrote: post #22
nemanjaboric wrote: post #15

Earlier quoted context omitted.

Which API are you referring to? If you're referring to `aio_` that's just glibc's user-space thread-pool emulation of the POSIX's asynchronous IO + many operations needed for the truly async IO are not supported (such as `stat` and `open`). There's `io_` syscalls family, but that's not in the ready-to-use state yet, judging by the manpages and various patches being submitted every month.

I'm referring to `fcntl(fd, F_SETFL, flags | O_NONBLOCK)`. `stat`, `open` are blocking, yes, didn't think about that. Also according to [1] file operations will always block, even in non-blocking mode, so I was wrong, sorry. 1: https://www.remlab.net/op/nonblock.shtml

> ... Also according to [1] file operations will always block ...

not quite :) look at aio(7)

Re: Thread Pools in Nginx Boost Performance 9x (2015)

#25

Post by majke »

Ok, I understand why you might "offload" read() from disk backed files file descriptors. But why "sendfile"? I thought sendfile is properly async in linux... Unless I'm getting something wrong.

"aio_write" -> wasn't the idea of AIO operations to actually be truly async? Maybe it's because it requires XFS. Anyway, I'm confused.

Re: Thread Pools in Nginx Boost Performance 9x (2015)

#26

Post by dsr_ »

acdjuiamadfn wrote: post #23

This is not the right place but I failed to find an answer elsewhere so would somebody answer? Is it possible for me to use lighttpd as a proxy but at the same time serve static pages for a subset of urls?

I don't know, but you can definitely do that with nginx.

You should ask here: https://redmine.lighttpd.net/projects/lighttpd/boards

Re: Thread Pools in Nginx Boost Performance 9x (2015)

#27

Post by taf2 »

majke wrote: post #25

Ok, I understand why you might "offload" read() from disk backed files file descriptors. But why "sendfile"? I thought sendfile is properly async in linux... Unless I'm getting something wrong. "aio_write" -> wasn't the idea of AIO operations to actually be truly async? Maybe it's because it requires XFS. Anyway, I'm confused.

From the article

"Although Linux provides a kind of asynchronous interface for reading files, it has a couple of significant drawbacks. One of them is alignment requirements for file access and buffers, but NGINX handles that well. But the second problem is worse. The asynchronous interface requires the O_DIRECT flag to be set on the file descriptor, which means that any access to the file will bypass the cache in memory and increase load on the hard disks. That definitely doesn’t make it optimal for many cases."

Re: Thread Pools in Nginx Boost Performance 9x (2015)

#28

Post by jsn »

majke wrote: post #25

Ok, I understand why you might "offload" read() from disk backed files file descriptors. But why "sendfile"? I thought sendfile is properly async in linux... Unless I'm getting something wrong. "aio_write" -> wasn't the idea of AIO operations to actually be truly async? Maybe it's because it requires XFS. Anyway, I'm confused.

From what I can see, sendfile isn't really async, it still returns the number of bytes written or error status, and nginx probably needs to wait for that to e.g. log the results, handle short writes, or proceed with whatever next operation must be done to the socket (like closing it). No idea why aio_write needs offloading, though.

Re: Thread Pools in Nginx Boost Performance 9x (2015)

#29

Post by taf2 »

jsn wrote: post #28
majke wrote: post #25

Ok, I understand why you might "offload" read() from disk backed files file descriptors. But why "sendfile"? I thought sendfile is properly async in linux... Unless I'm getting something wrong. "aio_write" -> wasn't the idea of AIO operations to actually be truly async? Maybe it's because it requires XFS. Anyway, I'm confused.

From what I can see, sendfile isn't really async, it still returns the number of bytes written or error status, and nginx probably needs to wait for that to e.g. log the results, handle short writes, or proceed with whatever next operation must be done to the socket (like closing it). No idea why aio_write needs offloading, though.

They say why in the article

"The asynchronous interface requires the O_DIRECT flag to be set on the file descriptor, which means that any access to the file will bypass the cache in memory and increase load on the hard disks"

They even go into how no interface has been surfaced yet that allows determining whether a file is in cache or not. Also how FreeBSD's aio interface doesn't have the same limitations

Post reply on HN