fix(file-loger): use no buffering model when open file

[monkeyDluffy6017]

trafficstars

Description

use no buffering model when open file Avoid error: If the data written to the log file is larger than the default buffer, it will be flushed into the file several times, and other log may be flushed in during this period

Fixes #7839

Checklist

• [x] I have explained the need for this PR and the problem it solves
• [x] I have explained the changes or the new features added to this PR
• [ ] I have added tests corresponding to this change
• [ ] I have updated the documentation to reflect this change
• [x] I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)

[tokers]

@monkeyDluffy6017 I don't think just changing the flush mechanism is a good idea, but it can be an alternative for the users. Also, the default Glibc buffer size should be shown (or the way we can calculate it should be given if the buffer size varies on different OS).

[monkeyDluffy6017]

@monkeyDluffy6017 I don't think just changing the flush mechanism is a good idea, but it can be an alternative for the users. Also, the default Glibc buffer size should be shown (or the way we can calculate it should be given if the buffer size varies on different OS).

I don't think we need buffer here, because we write and flush immediately. cc @spacewander

[tokers]

@monkeyDluffy6017 I don't think just changing the flush mechanism is a good idea, but it can be an alternative for the users. Also, the default Glibc buffer size should be shown (or the way we can calculate it should be given if the buffer size varies on different OS).

I don't think we need buffer here, because we write and flush immediately. cc @spacewander

The number of access logs can be tremendous if the QPS are high, in such a case, the performance will suffer from a serious degradation. Access logs are different from error logs, we definitely need to consider the caching. No buffer can be an option but MUST NOT BE a required one.

[spacewander]

What about using a bigger buffer, like 64KB in Nginx's access_log?

IMHO, there still will have an issue that a log > 64KB might be broken. Maybe using C.write and managing the buffer by ourselves via Lua table will be a better idea...

[spacewander]

After rethinking this problem, I have a new opinion: As currently we create the file handler per route instead of per file, it is hard to flush the log in order if we use a buffer per route.

Since the original code doesn't use buffer (it flushes the buffer immediately), I think we can focus on solving the bug first.

[monkeyDluffy6017]

@tokers do you agree with @spacewander ?

Since the original code doesn't use buffer (it flushes the buffer immediately), I think we can focus on solving the bug first.

[tokers]

@tokers do you agree with @spacewander ?

Since the original code doesn't use buffer (it flushes the buffer immediately), I think we can focus on solving the bug first.

Got it.

[tokers]

@tokers do you agree with @spacewander ?

Since the original code doesn't use buffer (it flushes the buffer immediately), I think we can focus on solving the bug first.

Got it.

But we may still open an eye about the performance.