Round 20 was recently published and Racket's score improved, as expected:
https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=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 i
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 to
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 way.
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
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
> qu
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 positi
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 th
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 because
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):
https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/fra
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:
https://www.techempower.com/benchmarks/#section=test&shareid=669bfab7-9242-4c26-
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 i
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 request
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 core.
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 conn
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 th
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). M
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 is
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 of
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 b
A new version of these benchmarks was just published ("Round 19"):
https://www.techempower.com/benchmarks/#section=data-r19
Racket scores rather poorly (0 errors is nice, though). Anybody has any
guesses as to why this is? Racket performs well enough as far as I'm
concerned, and while I don't u
That's a good idea. I'll check it out.
Jay
On Tue, Jul 16, 2013 at 1:49 AM, adam moore wrote:
> Hello there, racket users!
>
> My first post here - and it's pretty self serving, but, so it goes.
>
> I've recently been enjoying diving into racket, starting with the
> guide, and just getting my fe
Hello there, racket users!
My first post here - and it's pretty self serving, but, so it goes.
I've recently been enjoying diving into racket, starting with the
guide, and just getting my feet wet at the moment making some command
line tools, small web apps.
So, anyway, I'm not sure if anyone els
27 matches
Mail list logo
