-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch to v0.14 plugin api #928
Conversation
5641fd3
to
3117c55
Compare
Rest tasks are:
|
Tasks not resolved (will do these later after v0.14.0 release)
|
I'm checking some example configurations:
|
I did a very simple benchmark to show basic throughput on my laptop (MacBookAir 11inch), using configurations below: # generator process (1 or 2) w/ v0.12
<source>
@type dummy
dummy {"message":"yay fluentd v0.14!"}
rate 20000
tag test.flow
</source>
<match test.flow>
@type forward
flush_interval 1s
num_threads 5
<server>
host 127.0.0.1
port 24224
</server>
</match>
# forward process v0.14
<source>
@type forward
port 24224
</source>
<match test.**>
@type forward
buffer_type file
buffer_path /tmp/fluentd.forward.buffer
num_threads 10
flush_interval 1s
<server>
host 127.0.0.1
port 24225
</server>
</match>
# counter process v0.12
<source>
@type forward
port 24225
</source>
<match test.**>
@type flowcounter
unit second
tag fluentd.traffic
</match>
<match fluentd.traffic>
@type stdout
</match> |
v0.14 + file buffer shows a bit curious and unexpected event transferring. Totally this process can forward 20k events per second on average, but flush interval control in v0.14 is different and unexpected from v0.12's one.:
|
This is an (expected) result with forwarder on Fluentd v0.12:
|
I will merge this (and some leading) changes into master, and then will investigate this flush timing. |
No responses... It's time to merge! |
* without this fix, some events will be written paritally if any chunks raise error in #append/#concat * it makes duplicated events Buffer#write will do: (method name was changed: #emit is method names for event routers) * this method receives pairs of metadata and data to be written at once * append/concat these data to chunks (not committed) * commit first chunk * if succeeded, then commit all (even if any following chunk raises error) * if failed, rollback all In memory/file buffer, #commit is very lightweight operation and will NOT fail in most cases. This change requires some additional internal APIs for buffers/chunks * chunk status in general: this is required to make #write thread safe * keyword argument of #write: bulk and enqueue * #write method becomes much more complex, so bulk operation should be merged into an implementation (we can't maintain two different/similar methods) * #write method enqueues chunks if needed, so :immediate mode should be implemented in same level * chunk_full_threshold configuration parameter to control "chunk_size_full?" * bulk and non-bulk #write were merged * In non-bulk mode, it's too rare that written chunk content bytesize is same with limitation
* without this fix, some events will be written paritally if any chunks raise error in #append/#concat * it makes duplicated events Buffer#write will do: (method name was changed: #emit is method names for event routers) * this method receives pairs of metadata and data to be written at once * append/concat these data to chunks (not committed) * commit first chunk * if succeeded, then commit all (even if any following chunk raises error) * if failed, rollback all In memory/file buffer, #commit is very lightweight operation and will NOT fail in most cases. This change requires some additional internal APIs for buffers/chunks * chunk status in general: this is required to make #write thread safe * keyword argument of #write: bulk and enqueue * #write method becomes much more complex, so bulk operation should be merged into an implementation (we can't maintain two different/similar methods) * #write method enqueues chunks if needed, so :immediate mode should be implemented in same level * chunk_full_threshold configuration parameter to control "chunk_size_full?" * bulk and non-bulk #write were merged * In non-bulk mode, it's too rare that written chunk content bytesize is same with limitation
…r buffer overflow
1a43a1a
to
eefaa15
Compare
Green! |
This change is based on #912 and #943.