My system is 'embedded' (for the modern very liberal definition of that word) so memory bandwidth is kind of key.
I'm looking right now at Apache Serf, which advertises itself as supporting zero-copy, and seeing if I can integrate it into the libevent dispatch loop. But I'd hate to have to pull in yet another dependency. Ryan On Thu, Dec 8, 2016 at 10:06 AM, Thor Lancelot Simon <[email protected]> wrote: > On Thu, Dec 08, 2016 at 09:39:25AM -0500, Ryan Daum wrote: > > Hi there, > > > > I have a feature request for the http client facility, or at least a > > request for advice if there's already a way to do what I want. > > > > Profiling my application which uses libevent's http client piece to make > a > > large number of GET requests for fairly large amounts of data I see the > > majority of the process's time is spent in memcpy. > > I wrote an SSL-intercepting HTTP proxy for a network equipment vendor > using an early version of libevent -- but not so early that it lacked > HTTP support or the beginnings of bufferevent. > > It didn't have any SSL or HTTPS support, so we considered adding that > and built a few prototypes. Our conclusion was that the amount of > copying caused by bufferevent made using anything built on it a nonstarter > for our purpose -- we paid at least two copies in each direction (in the > front out of the proxy and out the back) which wasn't sustainable given > the memory bandwidth of our platform at the time and the need to handle > multiple Gbit/sec of traffic. Modern platforms have vastly more memory > bandwidth, but modern networks are multiple *tens* of Gbit/sec of traffic > so your mileage may vary. > > I ended up building a very thin, though not pretty, layer that had a single > buffer used for both Tx and Rx. If we used hardware, we could receive and > decrypt directly into the buffer from which we'd transmit (zero copies); > with software SSL, we paid one copy to get the cleartext. This > meant building datastructures, and utility code, that handled both the > protocol recordkeeping and the buffer recordkeeping in one shot, avoiding > the extra copies involved in all the abstraction. It also meant getting > annoyingly intimate with OpenSSL in a few cases. And no, I didn't get it > right the first time -- it took a couple of months of beta testing until > it was entirely stable. Using bufferevent would have been much, much > less development time and certainly less debugging. > > But copies are slow, while zero-copy code is hard to write. > > Thor > *********************************************************************** > To unsubscribe, send an e-mail to [email protected] with > unsubscribe libevent-users in the body. >
