RejectedSoftware Forums

Am 12.10.2013 17:45, schrieb Martin Nowak:

On Sun, 29 Sep 2013 10:21:46 GMT, Dicebot wrote:

On Sat, 28 Sep 2013 20:56:22 GMT, Martin Nowak wrote:

I reach about 4000 req/s.

Without keep-alive that was.

P.S. I got at most ~ 18 000 req/s with -c 2500 when testing about half an year ago and then it was network card bottleneck, not application.

But 2500 connections is somewhat irrelevant for HTTP.
After fixing the keep-alive issue I also reach
around 18k req/s with less then 10 connections. This is for a simple hello world plaintext response, rendering pages still shows up with quite some GC in the profiler.

To reach full speed you also need to add
-version=VibeManualMemoryManagement (makes it unsafe to escape data from
HTTPServerRequest).

I reached about 90 kreq/s using "weighttp -c 100 -k -n 100000" some time
back when Dicebot did his first benchmark tests. That was using a
standard desktop as the server (AMD Phenom2) and a laptop (Core2Duo)
over a GbE connection. The bottleneck still was the client in this setup.

That was some time ago though, so there may be some more performance
regressions by now. I'll add a CI based performance test in a while to
stabilize performance over time.

On Sat, 12 Oct 2013 15:45:43 GMT, Martin Nowak wrote:

But 2500 connections is somewhat irrelevant for HTTP.
After fixing the keep-alive issue I also reach
around 18k req/s with less then 10 connections. This is for a simple hello world plaintext response, rendering pages still shows up with quite some GC in the profiler.

I had ~18k without keep-alive.

On Tue, 15 Oct 2013 18:53:12 +0200, Sönke Ludwig wrote:

Am 15.10.2013 17:34, schrieb simendsjo:

On Sat, 12 Oct 2013 17:59:03 +0200, Sönke Ludwig wrote:
(...)

That was some time ago though, so there may be some more performance
regressions by now. I'll add a CI based performance test in a while to
stabilize performance over time.

I have an Arch x86 Linode instance with a quite some spare resources if you need an extra CI node.

For vibe.d itself I already have a host running multiple VMs for that
purpose, but if you are willing to allocate some resources for a general
CI for all code.dlang.org projects at some point, that would definitely
be great!

At least my suspicion is that we'll need to take everything we can,
depending on how much we'll want to test for each package.

I'll probably need help configuring the server to run the testing sandboxed.
And the server only has 1GB RAM, which might be a problem..
But we can talk more about this when the time comes.

Are you thinking of running an off-the-shelf CI? Does any have good D support?

On Wed, 16 Oct 2013 09:45:06 +0200, Sönke Ludwig wrote:
(...)

1GB RAM is probably an issue for a number of projects (since we don't
want to cause swapping on the server of course),

(...)

And because I run a RoR application there, there is only ~500mb free..
For some reason, RoR thinks RAM is free and everyone has GBs to spare.

Am 16.10.2013 14:10, schrieb Dicebot:

On Wed, 16 Oct 2013 08:19:35 GMT, simendsjo wrote:

For some reason, RoR thinks RAM is free and everyone has GBs to spare.

Sounds like DMD ;)

Anyway, this needs dub-registry side support first. Kind of working on it (adding features to vibe.d to allow more natural registry API implementation)

BTW I've made some local changes in dubregistry.web to add search and
prepare for categories. I hope this doesn't interfere with your changes
(forgot to submit the question asking if you are already making changes
there).