On Tue, 5 Jun 2007, James Bursa wrote:

>> This patch introduces the new setting CURLMOPT_MAXCONNECTS to allow an app
>> to set a max number of entries in the cache.
>
> I found that the number of connections can still be above this limit if the
> number of easy handles is greater. For example, set MAX to 30, and it will
> use 30 connections.

Right, this only limits the amount of connections kept in the cache. If you
continue to add easy handles libcurl will still need at least one connection
for each new easy handle so this is not a hard maximum limit.

> Is it too late to rename the option to something like
> CURLMOPT_MAXCONNECTCACHE to make this clearer?

No, it's not too late until we have a public release I'd say and even then we
can introduced new names by keeping the old around and use the new one in all
docs and examples etc.

I used the MAXCONNECTS name just because it is called exactly that for the
easy handle and they have (almost) the same function.

> A value less than 10 is treated as 10, due to the default 10 in
> Curl_mk_connc(). Would reducing that cause any problems?

Not really. All these amounts are pretty much guessed by me to be "good
enough" amounts for most cases.

> I'm not sure if the default should be an algorithm based on the number of
> easy handles. We could just make it a fixed size, and let the user use this
> option if they want something else.

My thinking for growing the cache with the amount of handles is that it would
be more similar to how it used to work (when each easy handle had its own
cache with by default up to 5 connections), and that it makes sense to allow
each easy handle to "leave" at least one or two connections to be able to
re-use them again.

But then, I don't use libcurl's multi interface in any application of my own
so I guess I'm not really the best guy to tell how these things work out in
real life.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html