You could, with the appropriate use of two threads, overlap the 13ms with the 51ms, by virtue of preparing a handful of new requests in the same time that the request is being processed.   Or, you could launch an asynchronous write, prepare the next request or two, and then stick your catcher’s mitt up into the air in time to catch the ball on its way down.   Good ol’t select() can go a long way sometimes.   But you still have to consider where is “the ruling constraint.”   How fast can the target of your entreaties process requests?   How many can it do “literally at the same time?”   If it were by some means presented with 10 requests simultaneously (and from the same TCP/IP port address), could it actually process them simultaneously?   It will do no good at all to generate a bunch of parallel requests “over here” only to find that they have to wait in line, e.g. waiting on some mutex or database lock or whatnot, “over there.”   You need to find that out first, before you start writing very-clever software.   (And especially before you actually say to anyone, such as your boss, “I think I know how I can make this thing run ten times faster,” because, once such perhaps-regretful words have passed your lips, you have ... Signed Up.™)