Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-09 Thread George Neuner
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

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-09 Thread George Neuner
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

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-09 Thread Jon Zeppieri
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

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-09 Thread Bogdan Popa
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

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-09 Thread George Neuner
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 >

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-09 Thread Bogdan Popa
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

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-08 Thread Alex Harsanyi
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

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-08 Thread Bogdan Popa
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

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-08 Thread Stephen De Gabrielle
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: > >

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-08 Thread Yury Bulka
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):

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-07 Thread Bogdan Popa
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:

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-02 Thread Bogdan Popa
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

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-02 Thread Bogdan Popa
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

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-02 Thread Bogdan Popa
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

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-01 Thread George Neuner
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

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-01 Thread Brian Adkins
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.

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-01 Thread Bogdan Popa
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

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-01 Thread George Neuner
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

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-01 Thread Sam Tobin-Hochstadt
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).

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-01 Thread George Neuner
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

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-01 Thread Bogdan Popa
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

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-01 Thread George Neuner
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. 

Re: [racket-users] Re: [racket] Web Framework Benchmarks

2020-06-01 Thread Sam Tobin-Hochstadt
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

[racket-users] Re: [racket] Web Framework Benchmarks

2020-06-01 Thread hashim muqtadir
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