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 being hit should change the numbers.) You can also run
Wireshark or "tcpdump", to be certain of what's going on at the packet
level, but that can be time-consuming to trace through.
Neil Van Dyke wrote on 09/01/2017 02:38 PM:
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/scgi.txt-Percentage of the requests served within a certain
time (ms)
results/scgi.txt- 50% 3
results/scgi.txt- 66% 4
results/scgi.txt- 75% 4
results/scgi.txt- 80% 5
results/scgi.txt- 90% 7
results/scgi.txt- 95% 11
results/scgi.txt- 98% 1018
results/scgi.txt- 99% 1030
results/scgi.txt- 100% 55256 (longest request)
If GC is indeed the cause, if you avoid or reduce the GC hits that are
killing you 5% of the time, then maybe 100% of your requests are
fast. (I suggest looking at avoiding/reducing GC hits holistically,
in an application-specific way, since there's lots of things you can
do, depending, and there are costs and benefits. One very likely
situation is that there are inefficiencies in the application code
itself that are the bottleneck, and it's best to take a look at those
before focusing on where the bottleneck moves next. That
familiarization with the application code can also help you decide how
to address any bottlenecks external to it.)
This performance of Racket SCGI+nginx relative to the others you
tested is surprising to me, since I made the Racket `scgi` package for
particular non-performance requirements, and performance was really
secondary. (If I were prioritizing speed higher, I suspect I could
make serving much faster, doing it a different way, and then
micro-optimizing on top of that.)
Not to look a gift horse in the mouth, but it's possible that
something else was going on, to give surprisingly good numbers. For
example, often, errors can cause good performance numbers. Sometimes I
used JMeter instead of `ab` to rule out that cause of bad numbers in
performance testing (as well as to implement some testing). Also, the
bad numbers could be something else, like the OS pushing into swap,
sporadic network latency (though looks like you might've controlled
for that one), or some other OS/hardware/network burp outside of your
Racket process(es).
I'd want to have a better understanding of these numbers before
Racketeers started either bragging or donning burlap sacks of shame. :)
--
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.
