[
https://issues.apache.org/jira/browse/LOG4NET-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13866538#comment-13866538
]
Jose Luis Pedrosa commented on LOG4NET-415:
-------------------------------------------
Hi Cauchy,
Because of your result tests, I am quite convinced that non-blocking is better
for this scenario:
Use Non-Blocking send 100000 message, 3733 failed (3.73 %), use 1.396 seconds.
Vs
Use BeginSend send 100000 message, 0 failed (.00 %), use 2.576 seconds.
The behaviour I want to achieve is fire and forget and don't block the main
thread. The async took double of time!
Also I think we need to understand the use case, it's for logging over UDP. In
extreme scenarios as the one we are using here, I'd radther higher message lost
rate than longer execution. Also I would expect a higher CPU using async vs
non-blocking, I think that is the reason why you loose less messages in async
mode, because it takes more time to do the same.
But I don't think anybody wants to log from a single application 100K messages
per second, Imagine that in any real application (some of the one we know). I
think even for really high values 10k per second, the lost would be almost 0.
Also in your test you receive more messages because async is slower! so you
take double of time, then double send. Blocking false maximizes what you can
send per second and loosing messages if it exceeds your capacity, I think that
is the best behaviour.
If you want to do a final test for the good shake of testing, you can try log
at fixed rate, (100, 1000, 2500, 5000 ) per second, and see when you start
loosing. But for what I've seen now, non-blocking achieves better the behaviour
that I'd want.
Rgds
JL
> RemoteSyslogAppender may block for ARP resolution + Improvement Strict RFC3164
> ------------------------------------------------------------------------------
>
> Key: LOG4NET-415
> URL: https://issues.apache.org/jira/browse/LOG4NET-415
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 1.2.13
> Environment: Any Windows environment
> Reporter: Jose Luis Pedrosa
> Labels: RemoteSyslogAppender
> Attachments: LOG4NET-415.patch, MessageLostTest.cs,
> MessageLostTest.cs, MessageLostTestAsync.cs, RemoteSyslogNonBlockingv2.patch
>
>
> Sending UDP packages may block for some time in specific circumstances:
> 1) Next hop in network level 3 can't be resolved by ARP.
> 2) Datagram size exceeds FastSendDatagramThreshold configured size.
> When sending packets bigger than FastSendDatagramThreshold, the OS waits
> until the packet is actually sent, if the If the syslog (or the next hop to
> reach the syslog) is in the same VLAN/Subnet the OS tries to resolve by ARP
> the Ip of the configured syslog, this may take up to 3 seconds, slowing down
> the whole application, which in some cases can lead to outages (timeouts, DB
> locks...).
> Also the fact that each carriage return generates the headers of the packet
> again, that can lead to a significant overhead in some scenarios, for
> instance when loggign HTTP requests to a remote syslog, every header will go
> in a different message. Also some logging may require characters that are now
> skipped in patch: https://issues.apache.org/jira/browse/LOG4NET-370
> I'm adding a patch that
> 1) Moves the use of UDPClient to Non blocking sockets, which eliminates the
> blocking.
> 2) Adds a configuration field to decide if you want Strict RFC Behaviour or
> not (with default Strict).
> Please your feedback, thanks in advance
> Jose Luis
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
