3 ms·
The Linux process scheduler deals with it, I guess. I suppose I could add some kind of my own limiting mechanism, but since encoding ties up the application pro
by zx2c4 14y ago
The Linux process scheduler deals with it, I guess. I suppose I could add some kind of my own limiting mechanism, but since encoding ties up the application process, I figure it's limited to how uwsgi works with this kind of thing (multiple child processes, threads, event loops, whatever).
I really wish there was an nginx header like X-Accel-Redirect called X-Accel-FD where I could pass it a file descriptor to send the data directly, with SIGPIPE set up fine. That way I wouldn't have to buffer from the application process.
Wait a second. Here's an idea -- maybe I can just pass a fifo file to X-Accel-Redirect... I'll give that a whirl. One potential issue here is that it's not going to behave nicely with the client terminating the connection prematurely -- it'll leave a zombified process or a filled pipe or both. So maybe this isn't best then. Any suggestions here? I'd like to not wind up rolling my own nginx module for this.
That said, the current solution works very well, and in my tests works great with several clients transcoding. My server is pretty underpowered, but it doesn't seem to have much of an issue.
- mbell 14y agoI wouldn't worry about it. At the scale I could see it being an issue I think the right answer becomes to simply store all the transcoded versions on disk and serve them directly. It would in all likelihood be more cost effective to pay for the storage than to pay for the CPU time to encode everything on the fly given the small size of audio files.