blocking file i/o when dealing with a ram disk?

jim.robinson

So everything I've read indicates it's a very bad idea to attempt perform file i/o using stock lua io libraries from within OpenResty LUA code. Does using a ramdisk for the file mitigate any of the problems, or is it still a really bad idea?

agentzh

Hello!

On Wed, Aug 30, 2017 at 7:57 AM, Jim Robinson wrote:
> So everything I've read indicates it's a very bad idea to attempt perform
> file i/o using stock lua io libraries from within OpenResty LUA code.  Does
> using a ramdisk for the file mitigate any of the problems, or is it still a
> really bad idea?
>

It's not really a bad idea as long as the disk I/O operations are
relatively small and their latency is manageable.

NGINX core uses blocking file I/O by default for its http cache,
access logging, and error logging, for example. Just don't panic.

If you use ramdisk, then you may probably just use the shared dicts
API instead since the latter does not incur any file system call
overhead at all.

Regards,
Yichun

jim.robinson

On Wed, Aug 30, 2017 at 7:36 PM Yichun Zhang (agentzh) <age...@gmail.com> wrote:

> Hello!

> On Wed, Aug 30, 2017 at 7:57 AM, Jim Robinson wrote:

>> So everything I've read indicates it's a very bad idea to attempt perform

>> file i/o using stock lua io libraries from within OpenResty LUA code.

>> Does using a ramdisk for the file mitigate any of the problems, or is it

>> still a really bad idea?

> It's not really a bad idea as long as the disk I/O operations are

> relatively small and their latency is manageable.

> NGINX core uses blocking file I/O by default for its http cache,

> access logging, and error logging, for example. Just don't panic.

> If you use ramdisk, then you may probably just use the shared dicts

> API instead since the latter does not incur any file system call

> overhead at all.

Ah, that's good to know. The specific details are that I'm finally

moving my openresty basd lua code from using location_capture to

using lua-resty-http. That gives me access to handling a streaming

response, which is a big win -- I can start sending the response

back to the client before waiting for all of it to be downloaded.

But now I need to be able to store the response somewhere until

it's completely sent so that I can then turn around and add it to

a custom cache layer.

The particular use case I'm intersting in involves big files, e.g.,

400 megabyte files fetched from the backend.

I hadn't thought about using the shared dicts api, I guess that

would make it just as easy to get access to the data from a separate

coroutine as using a shared file. I'll look into that.

As always, thank you for the advice.

Jim

jim.robinson

Well I am very very pleased with lua-rest-http as a replacement for ngx.location.capture.

Here's some timing requests made to a backend server, fetching a 400 MiB file:

status name-lookup connect pre-transfer start-transfer total

200 0.002 0.002 0.002 0.407 9.626

200 0.002 0.002 0.002 0.316 10.905

200 0.002 0.002 0.002 0.257 8.132

200 0.004 0.004 0.004 0.366 10.874

200 0.002 0.003 0.003 0.264 8.137

200 0.002 0.004 0.004 0.338 11.293

200 0.004 0.004 0.004 0.294 8.165

200 0.004 0.006 0.006 0.410 11.348

200 0.006 0.007 0.007 0.258 8.148

200 0.001 0.002 0.002 0.354 11.464

And here's a request via an openresty server that is using lua-resty-http to stream the data:

status name-lookup connect pre-transfer start-transfer total

200 0.001 0.001 0.001 0.317 8.236

200 0.002 0.002 0.002 0.383 11.500

200 0.003 0.003 0.003 0.246 8.357

200 0.001 0.001 0.001 0.314 10.961

200 0.001 0.001 0.001 0.230 8.073

200 0.001 0.002 0.002 0.324 11.097

200 0.002 0.002 0.002 0.317 8.198

200 0.001 0.002 0.002 0.381 11.438

200 0.001 0.002 0.002 0.289 8.605

200 0.001 0.001 0.001 0.379 11.532

On the old code, using ngx.location.capture, it was taking the 8-12 seconds to start-transfer, since it had to buffer the entire thing to local ramdisk before sending the response.