On 02/28/2018 11:04 AM, Aziz Rozyev wrote:
> While it’s not clear why one may need to flush the data on each http operation,
> I can imagine to what performance degradation that may lead of.
I store data on HTTP servers in a distributed manner and have a catalog
of where each file is. If I get back a successful HTTP response for a
PUT operation, I want it to be true, so the file must be on stable storage.
If I just write it to a buffer and something happens with the machine
while the data is still in the buffer, I can't trust that response and I
have to make sure the file is there in its entirety from time to time,
which is much much much much more of a performance degradation.
With clever file systems and/or good hardware (battery backed write
cache) it won't cost you much.
Anyways, it's completely irrelevant how fast you can write to RAM. The
task here is to write reliably. And you can make it fast if you want
with software and hardware.

>
> if it’s not a some kind of funny clustering among nodes, I wouldn't care much
> where actual data is, RAM still should be much faster, than disk I/O.
>
Let's turn the question this way: if you write to RAM, you can't make
sure that the file really made it's way to the storage.
Why do you upload files to an HTTP server if you don't care whether they
are there or not?
You could use /dev/null too. It's even more faster...
Or just make your upload_file() function to a dummy "return immediately"
call.
That's even more faster. :)

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx