[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] Evhttp client + conneciton pool




On Mar 29, 2013, at 6:32 PM, lesa Le wrote:

I'm trying to write a program to retrieve data using evhttp_make_request(). It needs to handle a significant amount of requests per second, to a decent amount of servers. Somewhere in the neighbourhood of 100s of servers, issuing several requests per second.

What I'm currently working on is some kind of a connection pool. I'd like to avoid opening a new connection for every request, but I'm trying to find the most efficient way to do this.

This sounds like a fun project. I did not write something like this with libevent, but here is how I would do this.

Keep a connection pool for each remote server. When you make a request for some server, get the connection for that server with the smallest number of pending requests and make the request with that connection. If the best connections has too many pending requests, you probably want to stop making requests for this server until the connections make some progress.

evhttp_connection keeps a list of request and process one request at a time (the first in the list). However, it does not keep a count of pending request. I would add such counter and a function to get the value. An alternative solution is which does not require changing libevent, is to queue the requests yourself, and make a request only when the a connection is finished with the previous request.

The number of connections to each server depends on the server - you will have to research this limit.

Connections will not last forever, depending on the remote server, they may be closed after few seconds. Looking at the source, it seems like connections are automatically connected as needed.

Keeping 100s of connections pools, (one for each server) is very easy with libevent, as each connection is only a struct with one file descriptor and some fields.

I would also check evhtp library <https://github.com/ellzey/libevhtp/> it may be easier to build your tool with it.