dbohdan wrote on 09/09/2017 02:40 PM:
When I limit the memory usage in racket-custom to the total RAM on the
VPS minus what the OS uses (through custodian-limit-memory) Racket
quits with an out of memory error at the point when it would be killed
by the OS. racket-scgi seems to behave the same,
On Friday, September 8, 2017 at 1:09:19 PM UTC+3, Jay McCarthy wrote:
> Wow! Thanks for all of this work. It is really interesting to see how
> different the performance is on the Internet workload!
Once again, you're welcome! See my reply to Neil Van Dyke for some reasoning
about the Internet wo
On Friday, September 8, 2017 at 4:29:34 PM UTC+3, Neil Van Dyke wrote:
> dbohdan wrote on 09/07/2017 04:52 PM:
>
> The #/sec for each implementation are suspiciously similar. I wonder
> whether they're limited by something like an accounting limit imposed on
> the VPS (such as network-bytes-per
dbohdan wrote on 09/07/2017 04:52 PM:
Last, I ran the benchmark over the Internet with two machines about 1.89×10^-10
light years apart. The applications ran on a very humble VPS. Due to its
humbleness I had to reduce the number of concurrent connections to 25.
The #/sec for each implementati
Wow! Thanks for all of this work. It is really interesting to see how
different the performance is on the Internet workload!
On Thu, Sep 7, 2017 at 9:52 PM, dbohdan wrote:
> On Tuesday, September 5, 2017 at 12:41:04 PM UTC+3, Jay McCarthy wrote:
>> Is the benchmarking client core the same core as
On Thu, Sep 7, 2017 at 4:52 PM, dbohdan wrote:
>
> In both cases the ordering is still "single" > "many" > "places" >
> "many-places". Though "many" and "places" are pretty close in the first case,
> "many" consistently comes out ahead if you retest.
This is really interesting. I wonder how cos
On Tuesday, September 5, 2017 at 12:41:04 PM UTC+3, Jay McCarthy wrote:
> Is the benchmarking client core the same core as the server core?
> Could that help explain why single threaded performance is best?
The not-quite-yes-or-no answer is that they were limited to separate virtual
cores inside
On Tuesday, September 5, 2017 at 3:17:38 AM UTC-7, Piyush Katariya wrote:
> Wow. ~7K looks like good number.
>
> Is it common practice to spawn Thread for each request ? Is it that cheap
> from resource point of view ? can ThreadPool could be of some help here ?
Racket threads are not OS thread
Wow. ~7K looks like good number.
Is it common practice to spawn Thread for each request ? Is it that cheap from
resource point of view ? can ThreadPool could be of some help here ?
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscrib
Is the benchmarking client core the same core as the server core?
Could that help explain why single threaded performance is best?
On Tue, Sep 5, 2017 at 10:00 AM, dbohdan wrote:
> On Tuesday, September 5, 2017 at 11:41:46 AM UTC+3, dbohdan wrote:
>> I'll try this again with two fixed cores avail
On Tuesday, September 5, 2017 at 11:41:46 AM UTC+3, dbohdan wrote:
> I'll try this again with two fixed cores available to the application
> container.
results/custom-many-places.txt:Requests per second:6517.83 [#/sec] (mean)
results/custom-many.txt:Requests per second:7949.04 [#/sec] (me
On Tuesday, September 5, 2017 at 10:57:17 AM UTC+3, Jay McCarthy wrote:
> I've just tested on Linux and OS X and I don't see that behavior. I'm
> quite confused.
Yes, scratch what I said. The "many-places" benchmark only fails this way for
me on a particular Linux VM, which just so happened to be
On Tue, Sep 5, 2017 at 8:07 AM, dbohdan wrote:
> ==
> results/custom-many.txt:Requests per second:6720.43 [#/sec] (mean)
> results/custom-places.txt:Requests per second:7095.99 [#/sec] (mean)
> results/custom-single.txt:Requests per second:7609.11 [#/sec] (mean)
> ==
That is i
On Tuesday, September 5, 2017 at 8:50:27 AM UTC+3, Jon Zeppieri wrote:
> (tcp-abandon-port r)
> (tcp-abandon-port w)
You're right. This worked for "places". I've rerun "single" and "many" along
with "places".
==
results/custom-many.txt:Requests per second:6720.43 [#/sec] (mean)
resul
On Tue, Sep 5, 2017 at 6:38 AM, dbohdan wrote:
> On Monday, September 4, 2017 at 7:11:14 PM UTC+3, Jay McCarthy wrote:
> I would like to add you to the AUTHORS file
> (https://gitlab.com/dbohdan/racket-vs-the-world/blob/master/AUTHORS — please
> read). Would this attribution line be okay?
>
>> J
I think so too (in both places versions)
On Tue, Sep 5, 2017 at 6:50 AM, Jon Zeppieri wrote:
> On Tue, Sep 5, 2017 at 1:38 AM, dbohdan wrote:
>>
>> I've run the default benchmark with the new application, which I've dubbed
>> "racket-custom". (Actually, I had to make a tweak to the benchmark to
On Tue, Sep 5, 2017 at 1:38 AM, dbohdan wrote:
>
> I've run the default benchmark with the new application, which I've dubbed
> "racket-custom". (Actually, I had to make a tweak to the benchmark to
> accommodate the number of requests it was fulfilling. It made ApacheBench
> overstep its memory
On Monday, September 4, 2017 at 7:11:14 PM UTC+3, Jay McCarthy wrote:
> Thank you for working on this Danyil.
You're welcome!
> Would you please add this file to your tests (and each of its three
> ways of running?)
Added, and updated to the "many-places" version.
I would like to add you to the
I thought of another way, so here's a fourth version:
#lang racket/base
(require racket/tcp
racket/match
racket/place)
(define message #"Lorem ipsum...") ;; XXX fill this in
(define len (bytes-length message))
(define (serve! r w)
(let read-loop ()
(define b (read-bytes-l
Thank you for working on this Danyil. I think it is fair to test what
the defaults give you.
Would you please add this file to your tests (and each of its three
ways of running?) It would be interesting to compare the performance
of Racket versus the particular Web server library. (The Web server
On Saturday, September 2, 2017 at 8:46:54 PM UTC+3, Piyush Katariya wrote:
> Does Racket app make use of all CPU cores by having multiple processes ?
Thanks for asking this question. It prompted me to revise how the benchmark is
run. The short answer is that the servlet application uses a single
Thanks for the clarification.
On 03-Sep-2017 12:31 AM, "George Neuner" wrote:
>
> On 9/2/2017 1:46 PM, Piyush Katariya wrote:
>
>> Does Racket app make use of all CPU cores by having multiple processes ?
>>
>
> If it is written to use "places", which are parallel instances of the
> Racket VM tha
On 9/2/2017 1:46 PM, Piyush Katariya wrote:
Does Racket app make use of all CPU cores by having multiple processes ?
If it is written to use "places", which are parallel instances of the
Racket VM that run on separate kernel threads.
https://docs.racket-lang.org/guide/parallelism.html?q=plac
Then it might not be a fair benchmark with a comparison to other Platforms.
Isnt it ?
--
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...@
The Racket web server does not make use of multiple CPU cores, but with
stateless continuations you can run multiple instances behind a reverse
proxy. See
https://groups.google.com/d/topic/racket-users/TC4JJnZo1U8/discussion ("it
is exactly node.js without callbacks").
-Philip
On Sat, Sep 2, 2017
25 matches
Mail list logo
