On Sat, Sep 9, 2017 at 6:25 PM, Jon Zeppieri <zeppi...@gmail.com> wrote: > It looks like after roughly 2^14 requests are > `accept`-ed, there's a *long* delay before the next one succeeds.
Okay, the above happens when the host runs out of ephemeral ports. So, not a big deal. --- My tests suggest the same thing (w.r.t. places) that D. Bohdan's do: that using places consistently lowers the server throughput (even when there are multiple cores available). Don't know why, though. I wanted to see if inter-place communication was the bottleneck, so I made some changes to allow the individual places to do their work without needing to communicate: - First, I made tcp-listeners able to be sent over place-channels, so the only inter-place communication would be at initialization time. - Then I realized I could accomplish the same goal with a lot less fuss by changing the meaning of tcp-listen's reuse? parameter so that it would set SO_REUSEPORT (instead of SO_REUSEADDR) on the listening socket. (This allows each place to bind to the same port without needing any inter-place communication at all.) This did not improve throughput. But it doesn't exactly prove that inter-place communication isn't a bottleneck, since both of the above changes required some other changes to rktio, which, for all I know, may have caused different performance problems. (If multiple OS threads are polling the same socket, you need to handle the race between them to accept an incoming connection.) So, I'm still puzzled by this. -J -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
