With most noise like serialization etc. out of the way, this is what I measured on Linux: native sender -> native receiver 567520085 Bytes/s CAF sender -> native receiver 511333973 Bytes/s native sender -> CAF receiver 229689173 Bytes/s CAF sender -> CAF receiver 222102755 Bytes/s Send performance is OK, but performance drops significantly once CAF is used at the receiver. The profiler output (attached) doesn't point to a particular function that consumes an inappropriate amount of time. So it's either the sum of the many little functions called for each received chunk or the epoll_wait loop itself. I have created a ticket for further progress tracking / discussion [1] as this is clearly not a Bro/Broker problem. Thank you all for reporting this and all the input you have provided. @Matthias: FYI, I have used a new feature in CAF that allows senders to get feedback from the I/O layer for not overloading it. This allows the sender to adapt to the send rate of the network. Dominik
|
caf-client.pdf
Description: Adobe PDF document
caf-server.pdf
Description: Adobe PDF document
_______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
