cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: extract max keepalive requests configuration using a discovery loop

From: Roberto Nibali <ratz_at_drugphish.ch>
Date: Tue, 27 Sep 2005 21:01:15 +0200

> CURLINFO_NUM_CONNECTS returns the number of new connects that were made.
> 0 means it re-used an existing connection.

So if I a have a loop where I always fetch the same URL, the history of
CURLINFO_NUM_CONNECTS is as follows (MaxKeepAliveRequests=10):

req 1: CURLINFO_NUM_CONNECTS=1
req 2: CURLINFO_NUM_CONNECTS=0
req 3: CURLINFO_NUM_CONNECTS=0
req 4: CURLINFO_NUM_CONNECTS=0
req 5: CURLINFO_NUM_CONNECTS=0
req 6: CURLINFO_NUM_CONNECTS=0
req 7: CURLINFO_NUM_CONNECTS=0
req 8: CURLINFO_NUM_CONNECTS=0
req 9: CURLINFO_NUM_CONNECTS=0
req 10: CURLINFO_NUM_CONNECTS=0
req 11: CURLINFO_NUM_CONNECTS=1

Which for some reason is not the case right now. But it's surely a
problem on my side.

> CURLINFO_REDIRECT_COUNT returns the number of redirects.

So this number actually needs to be added to the total number of
requests per keepalive connection then.

> I believe the description you quoted meant that if a
> followed-redirection is made, you can get a larger number of new
> connects (depending on how many redirects and if they manage to re-use
> connections or not).

Exactly. So to make sure my question gets answered with the least amount
of code, I should set CURLOPT_FOLLOWLOCATION to 0.

> I'm not sure what those apache config entries tell. Is
> MaxKeepAliveRequests the maximum number of consecutive requests allowed
> on the same connection? If so, you could use CURLINFO_NUM_CONNECTS and

Yes.

> figure out when it no longer returns 0 as then a new connect was made.

That was what I was trying ;). Just a little clumsy.

>>> I don't see how it is off by two. I set MAX_LOOP to 5, and run it on a
>>> URL of mine and then it says it was 3 connections while I could clearly
>>> see how all requests re-used the same one. Thus it was off by 4.
>>
>>
>> ?? off by 2, I'd say. since you did 5 connections and the program said
>> it did make 3.
>
> It used one connection doing 5 requests. It said '3' yes, but I that's
> because you display loop - 2, not because it signify anything.
>
> Unless I missed something of course.

No, bad wording on my side.

>>> Increase MAX_LOOP makes it even more off.
>>
>>
>> Well, try setting MAX_LOOP to MaxKeepAliveRequests + 1 and re-run your
>> tests.
>
> Why? Can't you succssfully do this the way I suggest?

Well, you need to do at least MaxKeepAliveRequests+1 requests to figure
out the settings of the web server.

>> Hmm, maybe in a spare minute I could dive into the libcurl sources but
>> so far I was extremely happy that the implementation and documentation
>> didn't require me to do so.
>
> I understand that, but someone has to add the features... :-)

Why is there no libcurl_easy_getopt()? Just curious.

The loop looks as follows now:

void perftest_rundisc(CURL *curl) {
  CURLcode res;
  unsigned int loop;
  unsigned int new_conn;
  unsigned int skip;
  long con;

  fprintf(stderr, "Explicitly disabling following 302\n");
  res = curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 0);
  res = curl_easy_setopt(curl, CURLOPT_URL, "http://some.site.com/");
  new_conn = 0;
  loop = 0;
  skip = 1;
  while (new_conn == 0 && loop < MAX_LOOP) {
    res = curl_easy_perform(curl);
    res = curl_easy_getinfo(curl, CURLINFO_NUM_CONNECTS, &con);
    check_retval(res, 0, __FILE__, __LINE__);
    if (con > 0) {
      if (skip == 1) {
        skip = 0;
      } else {
        new_conn = 1;
      }
    }
    if (new_conn == 0) {
      loop_sleep();
    }
    loop++;
  }
  fprintf(stderr, "Amount of cons through same socket: %d\n",loop);
}

Thank you and regards,
Roberto Nibali, ratz

-- 
-------------------------------------------------------------
addr://Kasinostrasse 30, CH-5001 Aarau tel://++41 62 823 9355
http://www.terreactive.com             fax://++41 62 823 9356
-------------------------------------------------------------
terreActive AG                       Wir sichern Ihren Erfolg
-------------------------------------------------------------
Received on 2005-09-27