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.