On Sat, Sep 9, 2017 at 6:25 PM, Jon Zeppieri 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.
On Sat, Sep 9, 2017 at 8:05 PM, Jon Zeppieri wrote:
> On Sat, Sep 9, 2017 at 7:52 PM, Jon Zeppieri wrote:
>>
>> It does seem odd, though, that the server seems to *favor* sending
>> ACKs to clients it can't service over responding to the ones it can.
>
> No, there has to be something else wrong.
On Sat, Sep 9, 2017 at 7:52 PM, Jon Zeppieri wrote:
>
> It does seem odd, though, that the server seems to *favor* sending
> ACKs to clients it can't service over responding to the ones it can.
No, there has to be something else wrong. The tcpdump output shows
significant gaps in time while this
On Sat, Sep 9, 2017 at 6:25 PM, Jon Zeppieri wrote:
> When I ran experiments similar to yours on OS X I saw some odd
> scheduling behavior. It looks like after roughly 2^14 requests are
> `accept`-ed, there's a *long* delay before the next one succeeds. It
> appears that the program is `poll`-ing,
When I ran experiments similar to yours on OS X I saw some odd
scheduling behavior. It looks like after roughly 2^14 requests are
`accept`-ed, there's a *long* delay before the next one succeeds. It
appears that the program is `poll`-ing, waiting for activity, but, for
whatever reason, it doesn't r
A time ago i have implemented a minimal fastcgi protocol and compare it
against various others implementations.
http://antoineb.github.io/blog/2015/06/02/basic-fastcgi-with-racket/
On 09/02/2017 10:12 PM, Neil Van Dyke wrote:
dbohdan wrote on 09/02/2017 03:12 PM:
I rather like the SCGI protoc
dbohdan wrote on 09/02/2017 03:12 PM:
I rather like the SCGI protocol. It's a pity that it isn't as widely
supported as FastCGI, considering that it's much simpler to implement
(second only to plain old CGI), but still has a performance profile
similar to FastCGI's.
I mostly implemented Fast
On Friday, September 1, 2017 at 8:19:19 PM UTC+3, dbohdan wrote:
> My exceptions were [...]
This, of course, should say "expectations".
On Friday, September 1, 2017 at 9:38:25 PM UTC+3, Neil Van Dyke wrote:
> Thank you very much for doing this work, D. Bohdan.
You're welcome! I had fun doing it
Oh yeah, contention from simultaneous requests, if you're doing that,
can also complicate your numbers. Adjusting `#:scgi-max-allow-wait`
might be a quick way to see whether that changes your numbers. (Hitting
a limit here could give you better numbers, or worse numbers, but
removing a limit
Thank you very much for doing this work, D. Bohdan.
If I'm reading these results quickly, and if my guess about the
distribution is correct, then it looks like Racket SCGI+nginx *might*
actually have the best times of any of your tested combinations *except
when a GC cycle kicks in*.
results
Hi, everyone. Long time (occasional) reader, first time writer here.
In the 5.x days I played with Racket's Web servlets and found them slower than
I'd expected. (My exceptions were, admittedly, quite high after seeing how much
better Racket performed at other tasks than your average scripting l
11 matches
Mail list logo
