> The exact throughput is somewhat difficult to measure but it's around 300 > to 500 kbps through the system. There are other factors here but the > overall architecture is easily capable of getting into many mbps in testing.
This is *very slow* and this is not read(4k) problem, it is something way more than this. Maybe you can share minimal client/server/proxy that I can take a look at? (the best case scenario if you will provide server/client that I can connect to each other and see the throughput, for example if both of them will print received payload) > CPU seems fine (32 core server is being used for testing and it's no where > near 100% usage on any core). I wrote about CPU just to underline that this will introduce some latency in compare to the plain bufferevent (of course I didn't mean that the problem is that huge that you will see 100% CPU consumption) > > You can add an API for evbuffer to change the default size and create > > a pull request with your changes here [2]. Are you interested in this? > > Or should I? > > I'm interested however I suspect you're best placed to make the patch. I'm > certainly happy to help where possible though. I can help you with patches *if* you will dig into aspects that I just wrote about. > Although, as I said, you're probably best placed to patch this one, are > there any guides to contributing to the project (i.e. testing and coding > requirements etc) > that I can look at? Yes, but it does not contain a lot of details for now: https://github.com/libevent/libevent/blob/master/CONTRIBUTING.md And it will be shown to you (by github) on issue/pull request creation time Regards, Azat. *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
