A single request in loop on macOS

From: Jicea via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 19 Mar 2024 13:37:15 +0000

Hi,
I'm doing some tests with libcurl, I've something that I can't understand and would hope to have some insight of more experienced people. It's not a libcurl bug and is certainly something "obvious" I don't understand.
I'm just running the same request in loop, 5000 times. This is a local request : GET http://localhost:8000
The libcurl sample is from --libcurl option. I've just specicied a timeout of 5s, and force use of ipv4 addresses:
```
#include <curl/curl.h>
static size_t cb(void *data, size_t size, size_t nmemb, void *clientp) {
    size_t real_size = size * nmemb;
    return real_size;
}
int fetch(char * url) {
    CURLcode ret;
    CURL *hnd;
    hnd = curl_easy_init();
    curl_easy_setopt(hnd, CURLOPT_BUFFERSIZE, 102400L);
    curl_easy_setopt(hnd, CURLOPT_URL, url);
    curl_easy_setopt(hnd, CURLOPT_NOPROGRESS, 1L);
    curl_easy_setopt(hnd, CURLOPT_TIMEOUT_MS, 5000L);
    curl_easy_setopt(hnd, CURLOPT_MAXREDIRS, 50L);
    curl_easy_setopt(hnd, CURLOPT_FTP_SKIP_PASV_IP, 1L);
    curl_easy_setopt(hnd, CURLOPT_TCP_KEEPALIVE, 1L);
    curl_easy_setopt(hnd, CURLOPT_WRITEFUNCTION, cb);
    curl_easy_setopt(hnd, CURLOPT_IPRESOLVE, 1L);
    ret = curl_easy_perform(hnd);
    curl_easy_cleanup(hnd);
    return (int) ret;
}
int main(int argc, char *argv[]) {
    for (int i = 0; i < 5000; i++) {
        int res = fetch(http://localhost:8000);
        if (res != 0) {
            printf("Status req %d KO=%d\n", i, res);
        }
    }
}
```
I'm on a MacBook Pro (Sonoma 14.3.1) M3/32Go. I'm compiling with system libcurl 8.4.0 (`gcc -l curl main.c -o main`) and I've also tested libcurl 8.6.0.
I launch the main 4 or 5 times in a row, one process at a time. Each time, I've error the 4rth or 5th times I launch `main`:
```
$ time ./main
./main 0.16s user 0.34s system 44% cpu 1.113 total
$ time ./main
./main 0.15s user 0.33s system 44% cpu 1.095 total
$ time ./main
./main 0.15s user 0.33s system 44% cpu 1.084 total
time ./main
Status req 1371 KO=7
Status req 1372 KO=7
Status req 1373 KO=7
Status req 1374 KO=7
Status req 1375 KO=7
Status req 1376 KO=7
Status req 1377 KO=7
Status req 1378 KO=7
Status req 1379 KO=7
Status req 1380 KO=7
....
./main 0.10s user 1.24s system 85% cpu 1.577 total
```


For the server side, I've tested:
- a Caddy one (CaddyFile is the following)
```
http://localhost:8000
respond "Hello, world!"
```
- a simple Python: `python3 -m http.server`

- a standard go :
```
package main
import (
            "fmt"
            "io"
            "net/http"
            "os"
)
func getHello(w http.ResponseWriter, r *http.Request) {
            io.WriteString(w, "Hello World!\n")
}
func main() {
            http.HandleFunc("/", getHello)
            err := http.ListenAndServe(":8000", nil)
            if err != nil {
                        fmt.Printf("error starting server: %s\n", err)
                        os.Exit(1)
            }
}
```
The behaviour is a little different when switching server (for instance, with the Python one, error is a timeout 28). I really don't understand what's happening and would be glad to have an explantion about what I'm missing.
I've tested the same code on a Debian and don't have any error, so it may be something related to macOS?
Thanks for the feedbacks and sorry if it's something obvisous I should be aware of.
Jean-Christophe


Orange Restricted
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2024-03-19