"Why "using the same 5000 handles" ? Sure, if all those 5000 are already completed then sure you can reuse them but I would guess than some of those transfers aren't completed in a second so you need to create and use more handles while the previous ones are finishing up."
Allow me to correct myself. By 5000 handles I meant, 5000 TCP connections / 5000 open sockets no more no less. This is a fixed requirement. So basically in order to achieve this, 1. I should fix the number of TCP connections to 5000 by setting it using CURLMOPT_MAXCONNECTS. 2. If there are no handles available, I can create a easy handle on the fly and use that to send the request. 3. So I can in fact in one second can have 5000 TCP concurrent connections sending 15000 requests using 15000 handles. 4. This also means that for a single connection, before we have received 200 OK for a request, we would have sent another request which is what I am looking for. Correct me if I am wrong. Regards, On Thu, Sep 18, 2014 at 3:58 PM, Daniel Stenberg <[email protected]> wrote: > On Thu, 18 Sep 2014, nikhil ap wrote: > > Set up 5000 concurrent connections and vary the request rate from 5000 to >> 50000 requests per second. >> > > libcurl doesn't really expose "connections" in the API, but I guess we can > ignore that for now. > > Assuming I have setup 5000 easy handles and added it to multi interface, >> in >> the first second, 5000 GET requests will be sent. >> > > Yeps. > > In the next second, using the same 5000 handles, I would like to send >> 10000 GET requests. >> > > Why "using the same 5000 handles" ? Sure, if all those 5000 are already > completed then sure you can reuse them but I would guess than some of those > transfers aren't completed in a second so you need to create and use more > handles while the previous ones are finishing up. > > This means 2 requests should be pipelined and sent in a single handle. >> > > Not exactly. The second request could possibly be pipelined on an existing > connection if you have that enabled, but the second request needs its own > easy handle. There's a one-to-one mapping between transfers and easy > handles. The second GET in a pipelined connection is still a separate > transfer and thus it is made with a separate easy handle. The multi handle > is what keeps track of all connections and all possible pipelines. > > In the third second, I would like to send 15000 which would have piplined >> 3 >> requests and so on. >> > > Again, you then need 15000 unused easy handles to take care of those 15000 > transfers. Some of them may then end up being done pipelined, some of them > may not. > > > -- > > / daniel.haxx.se > ------------------------------------------------------------------- > List admin: http://cool.haxx.se/list/listinfo/curl-library > Etiquette: http://curl.haxx.se/mail/etiquette.html > -- niks
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
