On Friday, 11 May 2018 at 23:24:32 UTC, Arun Chandrasekaran wrote:
On Friday, 11 May 2018 at 07:56:04 UTC, Daniel Kozak wrote:
[...]
siege makes a difference. Earlier I had two chrome windows open
and I just tried a simple GET from each, with a considerable
delay and I saw the same thread
On Friday, 11 May 2018 at 07:56:04 UTC, Daniel Kozak wrote:
On Wednesday, 9 May 2018 at 22:37:22 UTC, Arun Chandrasekaran
wrote:
[...]
I have change my example a little:
case "/": res.writeBody("Hello World " ~
to!string(thisThreadID), "text/plain");
And I get this (siege -p -c15 0b -t
On Friday, 11 May 2018 at 07:56:04 UTC, Daniel Kozak wrote:
On Wednesday, 9 May 2018 at 22:37:22 UTC, Arun Chandrasekaran
wrote:
[...]
I have change my example a little:
case "/": res.writeBody("Hello World " ~
to!string(thisThreadID), "text/plain");
And I get this (siege -p -c15 0b -t
On Wednesday, 9 May 2018 at 22:37:22 UTC, Arun Chandrasekaran
wrote:
That could be the reason for slowness.
Ubuntu 17.10 64 bit, DMD v2.079.1, E7-4860, 8 core 32 GB RAM.
With slight modifcaition to capture the timestamp of the
request on the server:
import std.datetime.systime : Clock;
On Wednesday, 9 May 2018 at 21:55:15 UTC, Daniel Kozak wrote:
On which system? AFAIK HTTPServerOption.reusePort works on
Linux but maybe not on others OSes. Other question is what
events driver is use (libasync, libevent, vibe-core)
On Wed, May 9, 2018 at 9:12 PM, Arun Chandrasekaran via
On which system? AFAIK HTTPServerOption.reusePort works on Linux but maybe
not on others OSes. Other question is what events driver is use (libasync,
libevent, vibe-core)
On Wed, May 9, 2018 at 9:12 PM, Arun Chandrasekaran via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Monday, 30
On Monday, 30 October 2017 at 17:23:02 UTC, Daniel Kozak wrote:
Maybe this one:
import vibe.d;
import std.regex;
import std.array : appender;
static reg = ctRegex!"^/greeting/([a-z]+)$";
void main()
{
setupWorkerThreads(logicalProcessorCount);
runWorkerTaskDist();
On Friday, 3 November 2017 at 18:44:30 UTC, Arun Chandrasekaran
wrote:
On Monday, 30 October 2017 at 17:23:02 UTC, Daniel Kozak wrote:
Maybe this one:
clip
vibedtest ~master: building configuration "dmd"...
Linking...
/usr/bin/ld: cannot find -levent
/usr/bin/ld: cannot find
On Friday, 3 November 2017 at 18:44:30 UTC, Arun Chandrasekaran
wrote:
I tried to run the example, and I'm struck with a linker error
DMD v2.076.1 and LDC 1.4.0.
/usr/bin/ld: cannot find -levent
/usr/bin/ld: cannot find -levent_pthreads
Did you try installing libevent and libevent-pthreads?
On Monday, 30 October 2017 at 17:23:02 UTC, Daniel Kozak wrote:
Maybe this one:
import vibe.d;
import std.regex;
import std.array : appender;
static reg = ctRegex!"^/greeting/([a-z]+)$";
void main()
{
setupWorkerThreads(logicalProcessorCount);
runWorkerTaskDist();
Maybe this one:
import vibe.d;
import std.regex;
import std.array : appender;
static reg = ctRegex!"^/greeting/([a-z]+)$";
void main()
{
setupWorkerThreads(logicalProcessorCount);
runWorkerTaskDist();
runApplication();
}
void runServer()
{
auto settings = new
On Thursday, 21 September 2017 at 13:09:33 UTC, Daniel Kozak
wrote:
wrong version, this is my letest version:
https://paste.ofcode.org/qWsQikdhKiAywgBpKwANFR
On Thu, Sep 21, 2017 at 3:01 PM, Daniel Kozak
wrote:
my version: https://paste.ofcode.org/RLX7GM6SHh3DjBBHd7wshj
On Monday, 25 September 2017 at 09:45:13 UTC, tchaloupka wrote:
On Monday, 25 September 2017 at 08:36:31 UTC, Vadim Lopatin
wrote:
On Monday, 25 September 2017 at 08:01:02 UTC, tchaloupka wrote:
On Monday, 25 September 2017 at 07:05:57 UTC, Vadim Lopatin
wrote:
[...]
I've just tried this on
On Monday, 25 September 2017 at 13:18:45 UTC, Daniel Kozak wrote:
Not at all. Rust test is fake. Does not process headers, does
not write headers. Does not send right output. Does not work
with browser. Every one or two request it will die. Rust
result shoud not be taken seriously. Until
Not at all. Rust test is fake. Does not process headers, does not write
headers. Does not send right output. Does not work with browser. Every
one or two request it will die. Rust result shoud not be taken seriously.
Until fixed
Dne 25. 9. 2017 11:50 dopoledne napsal uživatel "tchaloupka via
On Monday, 25 September 2017 at 08:36:31 UTC, Vadim Lopatin wrote:
On Monday, 25 September 2017 at 08:01:02 UTC, tchaloupka wrote:
On Monday, 25 September 2017 at 07:05:57 UTC, Vadim Lopatin
wrote:
On Monday, 25 September 2017 at 06:56:58 UTC, Vadim Lopatin
wrote:
On Sunday, 24 September 2017
On Monday, 25 September 2017 at 08:01:02 UTC, tchaloupka wrote:
On Monday, 25 September 2017 at 07:05:57 UTC, Vadim Lopatin
wrote:
On Monday, 25 September 2017 at 06:56:58 UTC, Vadim Lopatin
wrote:
On Sunday, 24 September 2017 at 22:54:11 UTC, Sönke Ludwig
wrote:
How on earth can that be
On Monday, 25 September 2017 at 07:05:57 UTC, Vadim Lopatin wrote:
On Monday, 25 September 2017 at 06:56:58 UTC, Vadim Lopatin
wrote:
On Sunday, 24 September 2017 at 22:54:11 UTC, Sönke Ludwig
wrote:
How on earth can that be unfair when the Go, node.js and
Scala versions appear to use
On 2017-09-24 20:36, Vadim Lopatin wrote:
nuald reverted change which enables multithreading since it's "unfair".
That's kind of stupid. In a real world scenario one would do everything
possible to get the best performance. If one of the frameworks doesn't
support mutlithreading, too bad
On Monday, 25 September 2017 at 06:56:58 UTC, Vadim Lopatin wrote:
On Sunday, 24 September 2017 at 22:54:11 UTC, Sönke Ludwig
wrote:
How on earth can that be unfair when the Go, node.js and Scala
versions appear to use multi-threading, too?
Looks like repo owner thinks they are single
On Sunday, 24 September 2017 at 22:54:11 UTC, Sönke Ludwig wrote:
How on earth can that be unfair when the Go, node.js and Scala
versions appear to use multi-threading, too?
Looks like repo owner thinks they are single threaded.
Am 24.09.2017 um 20:36 schrieb Vadim Lopatin:
On Friday, 22 September 2017 at 09:40:00 UTC, Sönke Ludwig wrote:
What's was the last status? Could you observe any meaningful thread
scaling?
It works for me - multithreading improves performance on my PC.
So far, test results on
On Sunday, 24 September 2017 at 18:36:50 UTC, Vadim Lopatin wrote:
On Friday, 22 September 2017 at 09:40:00 UTC, Sönke Ludwig
wrote:
What's was the last status? Could you observe any meaningful
thread scaling?
It works for me - multithreading improves performance on my PC.
So far, test
On Friday, 22 September 2017 at 09:40:00 UTC, Sönke Ludwig wrote:
What's was the last status? Could you observe any meaningful
thread scaling?
It works for me - multithreading improves performance on my PC.
So far, test results on
https://github.com/nuald/simple-web-benchmark
show that D is
On Sunday, 24 September 2017 at 08:08:35 UTC, Petar Kirov
[ZombineDev] wrote:
On Saturday, 23 September 2017 at 22:07:58 UTC, bitwise wrote:
[...]
Can you give a bit more details? What kind of architectures do
you mean (hardware, software, ..)?
What was your use case? IO-multiplexing,
On Saturday, 23 September 2017 at 22:07:58 UTC, bitwise wrote:
Of the few different architectures I tried, the fiber based
approach was much slower. It's possible that my implementation
did too many unnecessary context switches.
Can you give a bit more details? What kind of architectures do
On Friday, 22 September 2017 at 09:48:47 UTC, Sönke Ludwig wrote:
Am 21.09.2017 um 20:49 schrieb bitwise:
Doesn't vibe-d use Fibers?
I tried to build a simple web server with a fiber-based
approach once - it was horribly slow.
I hope C# (and soon C++) style stackless resumable functions
On 9/21/17 11:49, bitwise wrote:
On Thursday, 21 September 2017 at 08:01:23 UTC, Vadim Lopatin wrote:
There is a simple set of simple web server apps written in several
languages (Go, Rust, Scala, Node-js):
https://github.com/nuald/simple-web-benchmark
I've sent PR to include D benchmark
On Thursday, 21 September 2017 at 08:01:23 UTC, Vadim Lopatin
wrote:
There is a simple set of simple web server apps written in
several languages (Go, Rust, Scala, Node-js):
https://github.com/nuald/simple-web-benchmark
I've sent PR to include D benchmark (vibe.d).
I was hoping it could show
Am 21.09.2017 um 20:49 schrieb bitwise:
Doesn't vibe-d use Fibers?
I tried to build a simple web server with a fiber-based approach once -
it was horribly slow.
I hope C# (and soon C++) style stackless resumable functions will
eventually come to D.
It uses them and the overhead actually
Am 22.09.2017 um 09:45 schrieb Vadim Lopatin:
On Thursday, 21 September 2017 at 19:40:48 UTC, bitwise wrote:
On Thursday, 21 September 2017 at 18:55:04 UTC, Vadim Lopatin
It does. But Golang uses them, too. Goroutines.
Indeed. I'm reading about them right now, and they seem to be
On Thursday, 21 September 2017 at 19:40:48 UTC, bitwise wrote:
On Thursday, 21 September 2017 at 18:55:04 UTC, Vadim Lopatin
It does. But Golang uses them, too. Goroutines.
Indeed. I'm reading about them right now, and they seem to be
"multiplexed". I wonder if Vibe.d does something similar.
On Thursday, 21 September 2017 at 18:55:04 UTC, Vadim Lopatin
wrote:
On Thursday, 21 September 2017 at 18:49:00 UTC, bitwise wrote:
On Thursday, 21 September 2017 at 08:01:23 UTC, Vadim Lopatin
wrote:
[...]
Doesn't vibe-d use Fibers?
I tried to build a simple web server with a fiber-based
On Thursday, 21 September 2017 at 08:01:23 UTC, Vadim Lopatin
wrote:
There is a simple set of simple web server apps written in
several languages (Go, Rust, Scala, Node-js):
https://github.com/nuald/simple-web-benchmark
I've sent PR to include D benchmark (vibe.d).
I was hoping it could show
On Thursday, 21 September 2017 at 18:49:00 UTC, bitwise wrote:
On Thursday, 21 September 2017 at 08:01:23 UTC, Vadim Lopatin
wrote:
There is a simple set of simple web server apps written in
several languages (Go, Rust, Scala, Node-js):
https://github.com/nuald/simple-web-benchmark
I've sent
On Thursday, 21 September 2017 at 17:13:16 UTC, Daniel Kozak
wrote:
Ok, maybe there is a some small improvments, but it is nothing
what would make this faster than rust and still undere 30K on
my pc
More test results:
On my Win10 PC, DMD/x86/libevent:27-29K, Go:31-33K
Ok, maybe there is a some small improvments, but it is nothing what would
make this faster than rust and still undere 30K on my pc
On Thu, Sep 21, 2017 at 7:02 PM, Daniel Kozak wrote:
> in this situation I dont thing there will be difference
>
> On Thu, Sep 21, 2017 at 6:20
in this situation I dont thing there will be difference
On Thu, Sep 21, 2017 at 6:20 PM, Kagamin via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> Other implementations use switch. https://dpaste.dzfl.pl/406dafbedbd9 is
> it slower?
>
Other implementations use switch.
https://dpaste.dzfl.pl/406dafbedbd9 is it slower?
with dmd 26K - 28K
witlh ldc 27K - 29K
On Thu, Sep 21, 2017 at 3:53 PM, Vadim Lopatin via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Thursday, 21 September 2017 at 13:46:49 UTC, Daniel Kozak wrote:
>
>> Ok, after some more testing it seems it is almost sema with or without
>>
On Thursday, 21 September 2017 at 13:46:49 UTC, Daniel Kozak
wrote:
Ok, after some more testing it seems it is almost sema with or
without VibeManualMemoryManagement
Do you see any benefits from using LDC instead of DMD?
Ok, after some more testing it seems it is almost sema with or
without VibeManualMemoryManagement
On Thu, Sep 21, 2017 at 3:44 PM, Daniel Kozak wrote:
> And it seems it is faster with GC. So removing VibeManualMemoryManagement
> helped in some cases too.
>
> On Thu, Sep 21,
s'/sema/same/
On Thu, Sep 21, 2017 at 3:46 PM, Daniel Kozak wrote:
> Ok, after some more testing it seems it is almost sema with or without
> VibeManualMemoryManagement
>
> On Thu, Sep 21, 2017 at 3:44 PM, Daniel Kozak wrote:
>
>> And it seems it is faster
And it seems it is faster with GC. So removing VibeManualMemoryManagement
helped in some cases too.
On Thu, Sep 21, 2017 at 3:43 PM, Daniel Kozak wrote:
> BTW: I have changed dub.json a little too:
>
> {
> "name": "vibedtest",
> "targetName": "vibedtest",
>
BTW: I have changed dub.json a little too:
{
"name": "vibedtest",
"targetName": "vibedtest",
"targetType": "executable",
"targetPath": "bin",
"dependencies": {
"vibe-d": "~>0.8.2-alpha.1"
},
"subConfigurations": {"vibe-d": "libevent"},
"versions": [
On Thursday, 21 September 2017 at 13:09:33 UTC, Daniel Kozak
wrote:
wrong version, this is my letest version:
https://paste.ofcode.org/qWsQikdhKiAywgBpKwANFR
Thank you!
Updated.
wrong version, this is my letest version:
https://paste.ofcode.org/qWsQikdhKiAywgBpKwANFR
On Thu, Sep 21, 2017 at 3:01 PM, Daniel Kozak wrote:
> my version: https://paste.ofcode.org/RLX7GM6SHh3DjBBHd7wshj
>
> On Thu, Sep 21, 2017 at 2:50 PM, Sönke Ludwig via Digitalmars-d <
>
my version: https://paste.ofcode.org/RLX7GM6SHh3DjBBHd7wshj
On Thu, Sep 21, 2017 at 2:50 PM, Sönke Ludwig via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> Am 21.09.2017 um 14:41 schrieb Vadim Lopatin:
>
>> On Thursday, 21 September 2017 at 10:21:17 UTC, Sönke Ludwig wrote:
>>
>>>
my results:
OS lang:config req/scomments
=== ===== ==
Linuxgo24K
LinuxD:libevent27K4 threads
LinuxD:libasync 26.5K 4 threads
On Thu, Sep 21, 2017 at 2:41 PM, Vadim Lopatin via Digitalmars-d <
Am 21.09.2017 um 14:41 schrieb Vadim Lopatin:
On Thursday, 21 September 2017 at 10:21:17 UTC, Sönke Ludwig wrote:
shared static this()
{
(...)
}
BTW, I'd recommend using
void main()
{
(...)
runApplication();
}
instead and dropping the
On Thursday, 21 September 2017 at 10:21:17 UTC, Sönke Ludwig
wrote:
shared static this()
{
(...)
}
BTW, I'd recommend using
void main()
{
(...)
runApplication();
}
instead and dropping the VibeDefaultMain version in the package
recipe. The
shared static this()
{
(...)
}
BTW, I'd recommend using
void main()
{
(...)
runApplication();
}
instead and dropping the VibeDefaultMain version in the package recipe.
The old approach is planned to be faded out slowly, because it requires
Am 21.09.2017 um 10:01 schrieb Vadim Lopatin:
There is a simple set of simple web server apps written in several
languages (Go, Rust, Scala, Node-js):
https://github.com/nuald/simple-web-benchmark
I've sent PR to include D benchmark (vibe.d).
I was hoping it could show performance at least
On Thursday, 21 September 2017 at 08:18:51 UTC, Suliman wrote:
Can it be issue with regex speed?
auto reg = ctRegex!"^/greeting/([a-z]+)$";
Did you try without it?
Regex is used for request paths like "/greeting/username" and not
used for path "/"
There is no big slowdown caused by regex.
Can it be issue with regex speed?
auto reg = ctRegex!"^/greeting/([a-z]+)$";
Did you try without it?
There is a simple set of simple web server apps written in
several languages (Go, Rust, Scala, Node-js):
https://github.com/nuald/simple-web-benchmark
I've sent PR to include D benchmark (vibe.d).
I was hoping it could show performance at least not worse than
other languages.
But it appears
56 matches
Mail list logo