Bug #80830 [Opn]: Running out of local ports when using curl

From: Date: Fri, 12 Mar 2021 08:39:03 +0000
Subject: Bug #80830 [Opn]: Running out of local ports when using curl
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-232667@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=80830&edit=1 ID: 80830 User updated by: external dot maik dot dieterich at bosch dot com Reported by: external dot maik dot dieterich at bosch dot com Summary: Running out of local ports when using curl Status: Open Type: Bug Package: Network related Operating System: Windows Server 2019 PHP Version: 7.4.15 Block user comment: N Private report: N New Comment: Hello, yes we are using apache2handler SAPI and each request initializes a curl handle. But also if I'm initialize a curl handle in a cli application and close it the connection I openend is closed but the corresponding local to local port connection, which i have not explicit opened, stays in TIME_WAIT. When I'm opening and close the same connection with curl from command line without PHP i can not see such a local to local port connection. Thanks for the support. Previous Comments: ------------------------------------------------------------------------ [2021-03-09 11:54:57] cmb@php.net To clarify: you are not initializing multiple curl handles in a single request, but rather for different requests, and you are using the apache2handler SAPI? In this case there may indeed be a problem, since the SAPI intializes libcurl (curl_global_init()) at its startup and shuts it down (curl_global_cleanup()) at its shutdown, so libcurl might keep connections open, but may not reuse them. > It's causing localhost to localhost TIME_WAITs. Frankly, I have no idea why that happens. The curl extension is relatively thin wrapper around libcurl, so I wonder whether we set up or use libcurl inappropriately, or whether Apache or the SAPI interferes. ------------------------------------------------------------------------ [2021-03-09 08:23:25] michael dot mckeever at bosch dot com Thank you @danack and @cmb for the quick response. Your suggestions with reusing the the curl handle is correct if you're using a cli application and you're in control of the environment. The problem described by Maik is that if you're using apache you can't reuse curl handles. @rtrtrtrtrt, your comment is unfortunately not helping in this topic ;-) The key question is, why is the mass usage of curl.exe not causing TIME_WAITs and the php libcurl functions causing TIME_WAITs. Furthermore the php functinos are not causing TIME_WAITs to the called server as one would expect, but it's causing TIME_WAITs for some kind of local redirects. It's causing localhost to localhost TIME_WAITs. ------------------------------------------------------------------------ [2021-03-04 20:07:01] rtrtrtrtrt at dfdfdfdf dot dfd it's just how TCP works https://superuser.com/questions/173535/what-are-close-wait-and-time-wait-states ------------------------------------------------------------------------ [2021-03-04 18:32:27] external dot maik dot dieterich at bosch dot com First thanks for the quick response. What is not clear for me, is why the connection I open to the external server can be closed immediately and why this local local port connections, which i do not have if i use curl from command line, are still open even if the external connection I open is closed. Because each connection is opened in a different thread i think I can not reuse them. ------------------------------------------------------------------------ [2021-03-04 17:19:18] cmb@php.net I think @danack is spot on. But instead of fiddling with these Windows settings, I suggest to re-use the same curl resource (object as of PHP 8.0.0), like described by Dan, to avoid calling curl_easy_cleanup() under the hood, because[1] | re-using handles is a key to good performance with libcurl Anyway, this is not a PHP issue. [1] <https://curl.se/libcurl/c/curl_easy_cleanup.html> ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=80830 -- Edit this bug report at https://bugs.php.net/bug.php?id=80830&edit=1

« previous php.bugs (#232667) next »