Round 20 was recently published and Racket's score improved, as expected:
https://www.techempower.com/benchmarks/#section=data-r20=ph=composite
We're now beating many of the popular frameworks in the composite scores
and I think there are still plenty of improvements that could be made.
On 6/9/2020 8:11 AM, Jon Zeppieri wrote:
On Tue, Jun 9, 2020 at 7:59 AM Bogdan Popa wrote:
>
> I think we'd need to also set `SO_REUSEPORT', which is not available on
> all platforms, to support multiple processes listening on the same port
> without reusing file descriptors.
And even where
On 6/9/2020 7:59 AM, Bogdan Popa wrote:
George Neuner writes:
> Multiple Racket applications *should* all be able to listen on the
> same port without having been spawned from the same ancestor process.
> If that isn't working now, something has gotten hosed.
I don't know whether this used
On Tue, Jun 9, 2020 at 7:59 AM Bogdan Popa wrote:
>
> I think we'd need to also set `SO_REUSEPORT', which is not available on
> all platforms, to support multiple processes listening on the same port
> without reusing file descriptors.
And even where it is available, it doesn't work the same
George Neuner writes:
> Multiple Racket applications *should* all be able to listen on the
> same port without having been spawned from the same ancestor process.
> If that isn't working now, something has gotten hosed.
I don't know whether this used to work in the past or not, but currently
On 6/9/2020 3:02 AM, Bogdan Popa wrote:
Alex Harsanyi writes:
> Question 1: Based on this benchmark, is there any reason to chose anything
> else but "drogon"? Even if one chooses the second best on that list, which
> is "actix", they already loose about 6% performance and things degrade
>
Alex Harsanyi writes:
> Question 1: Based on this benchmark, is there any reason to chose anything
> else but "drogon"? Even if one chooses the second best on that list, which
> is "actix", they already loose about 6% performance and things degrade
> quickly afterwards. The framework at
On Monday, June 8, 2020 at 6:11:37 PM UTC+8, Yury Bulka wrote:
>
> Wow, from 695 requests per second to 49,516 is a huge improvement!
>
> Since we were comparing to django previously, it's now much closer with
> django (which does 78,132 rps.)
>
I know very little about web development, so
Yury Bulka writes:
> Wow, from 695 requests per second to 49,516 is a huge improvement!
>
> Since we were comparing to django previously, it's now much closer with
> django (which does 78,132 rps.)
I expect the Racket benchmark will do even better on TechEmpower's hw
than it did on mine
Thank you Bogdan!
On Sun, Jun 7, 2020 at 6:39 PM Bogdan Popa wrote:
> Small update on this: I've updated the benchmarks to run multiple Racket
> processes with an Nginx load balancer in front. After some tuning[1], here
> is what the results look like on my 12 core AMD Ryzen 9 3900 server:
>
>
Wow, from 695 requests per second to 49,516 is a huge improvement!
Since we were comparing to django previously, it's now much closer with
django (which does 78,132 rps.)
Django also does run multiple worker processes (3 per cpu):
Small update on this: I've updated the benchmarks to run multiple Racket
processes with an Nginx load balancer in front. After some tuning[1], here
is what the results look like on my 12 core AMD Ryzen 9 3900 server:
The reason for the poor performance relative to the other langs/frameworks is
that there is currently no easy way to take advantage of multiple cores using
the web framework so what’s being benchmarked is single core perf. This is
mainly a problem for benchmarks such as this, but not really an
Bogdan Popa writes:
> Only dispatchers get direct access to the output port for the socket.
> If you use `dispatch/servlet', then it takes care of taking your
> `response' value and calling `output-response' on it. Unless the server
> knows the connection should be closed and unless the
George Neuner writes:
> What I did say is that Python's threads are core limited - and *that*
> is true. As a technical matter, Python *may* in fact start threads
> on different cores, but the continual need to take the GIL quickly
> forces every running thread in the process onto the same
On 6/1/2020 4:21 PM, Bogdan Popa wrote:
George Neuner writes:
> But Python's DB pool is threaded, and Python's threads are core
> limited by the GIL in all the major implementations (excepting
> Jython).
Python's Postgres pooling does not[1] use POSIX threads under the hood
to manage the
I may look into this in more detail later, but I ran a simple benchmark
comparison on my modest AWS EC2 server (ApacheBench can behave poorly on
MacOS).
1) I ran ApacheBench w/ 6 processes to fetch a simple "hello world" static
html file using only nginx. I got roughly 650 requests per second.
George Neuner writes:
> But Python's DB pool is threaded, and Python's threads are core
> limited by the GIL in all the major implementations (excepting
> Jython).
Python's Postgres pooling does not[1] use POSIX threads under the hood
to manage the connections if that's what you mean, nor is
On 6/1/2020 3:40 PM, Sam Tobin-Hochstadt wrote:
I'm skeptical both of the DB explanation and the multi-core
explanation. As you say, the difference between something like Django
and Racket is much too large to be explained by that. For example, on
the "plaintext" benchmark, Racket serves about
I'm skeptical both of the DB explanation and the multi-core
explanation. As you say, the difference between something like Django
and Racket is much too large to be explained by that. For example, on
the "plaintext" benchmark, Racket serves about 700 req/sec (I get
similar results on my machine).
On 6/1/2020 1:40 PM, Bogdan Popa wrote:
I replied earlier today off of my Phone, but, for whatever reason
(caught in the moderation queue?), it's not showing up in this thread.
Here's what it said:
The reason for poor performance relative to the other
langs/frameworks is that there
I replied earlier today off of my Phone, but, for whatever reason
(caught in the moderation queue?), it's not showing up in this thread.
Here's what it said:
The reason for poor performance relative to the other
langs/frameworks is that there is currently no easy way to take
advantage
On 6/1/2020 11:12 AM, Sam Tobin-Hochstadt wrote:
I think the biggest thing is that no one has looked at optimizing
these benchmarks in Racket. If you tried out running one of these
benchmarks and ran the profiler it would probably show something
interesting.
Sam
The code[1] itself isn't bad.
I think the biggest thing is that no one has looked at optimizing
these benchmarks in Racket. If you tried out running one of these
benchmarks and ran the profiler it would probably show something
interesting.
Sam
On Mon, Jun 1, 2020 at 6:43 AM hashim muqtadir
wrote:
>
> A new version of these
24 matches
Mail list logo
