Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
RE: CURLMOPT_MAX_HOST_CONNECTIONS
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Mellergård, Daniel via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 4 Feb 2022 21:17:26 +0000
> That's probably because the limit is not entirely fixed in any browser afaik, but 6 is typically the "long term" limit for desktop browsers at least, that can be overriden at times for specific (short-term) reasons.
Ok, thanks. I have not seen that kind of information previously. So then it should probably be ok to use a lot more connections for a short-term. Good!
> If you are doing "browser-like" operations with libcurl, you are probably better off capping the amount somewhere, yes. I don't think libcurl needs to set that default for you though. A lot of users use libcurl in non-browser use cases and for those a sensible limit might be something completely different.
Yeah, I would probably need to cap it to some limit. (I guess this option is only effective for non-multiplexed connections?)
> If you didn't set a limit for curl, it doesn't care and then there's no ceiling.
Ok, I accept your word for it. In any way it doesn't cause an issue for us. I'll probably set a max-limit of maximum 64 connections anyway. But as far I can see, there are 64 connections opened almost at once (it differs slightly, less than 20 ms at most, probably because requests are placed at slightly different times). No connection has reached the connect phase before all connections has been opened and started executing dns lookup. (And definitely no transfers has been completed, so there are no consecutive requests being placed from early finished transfers.) It might be possible that we place exactly 64 requests at once every time when we start a session, but it's not very likely I would say (we probably place more).
/Daniel
Date: Fri, 4 Feb 2022 21:17:26 +0000
> That's probably because the limit is not entirely fixed in any browser afaik, but 6 is typically the "long term" limit for desktop browsers at least, that can be overriden at times for specific (short-term) reasons.
Ok, thanks. I have not seen that kind of information previously. So then it should probably be ok to use a lot more connections for a short-term. Good!
> If you are doing "browser-like" operations with libcurl, you are probably better off capping the amount somewhere, yes. I don't think libcurl needs to set that default for you though. A lot of users use libcurl in non-browser use cases and for those a sensible limit might be something completely different.
Yeah, I would probably need to cap it to some limit. (I guess this option is only effective for non-multiplexed connections?)
> If you didn't set a limit for curl, it doesn't care and then there's no ceiling.
Ok, I accept your word for it. In any way it doesn't cause an issue for us. I'll probably set a max-limit of maximum 64 connections anyway. But as far I can see, there are 64 connections opened almost at once (it differs slightly, less than 20 ms at most, probably because requests are placed at slightly different times). No connection has reached the connect phase before all connections has been opened and started executing dns lookup. (And definitely no transfers has been completed, so there are no consecutive requests being placed from early finished transfers.) It might be possible that we place exactly 64 requests at once every time when we start a session, but it's not very likely I would say (we probably place more).
/Daniel
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-02-04