RejectedSoftware Forums

On Fri, 07 Aug 2015 21:16:53 GMT, Etienne Cimon wrote:

Yes, I think you can try using a log file with time stamp so that the specific cause can be traced. I'm also curious to know if libasync is also problematic

I replaced http-server with nginx, and replaced the 500 requests with 50000 serving the same 13-bytes file. Results as follows:

Vibe

Requests per second: 16983.8
Conversation size: 416 bytes

GET /file.txt HTTP/1.1
User-Agent: vibe.d/0.7.23 (HTTPClient, +http://vibed.org/)
Connection: keep-alive
Accept-Encoding: gzip, deflate
Host: 127.0.0.1

HTTP/1.1 200 OK
Server: nginx/1.6.2 (Ubuntu)
Date: Sat, 08 Aug 2015 15:40:31 GMT
Content-Type: text/plain
Content-Length: 13
Last-Modified: Fri, 07 Aug 2015 07:10:12 GMT
Connection: keep-alive
ETag: "55c459d4-d"
Accept-Ranges: bytes

Hello world!

AB (with -k):

Requests per second: 36735.56
Conversation size: 371 bytes

GET /file.txt HTTP/1.0
Connection: Keep-Alive
Host: 127.0.0.1:8090
User-Agent: ApacheBench/2.3
Accept: */*

HTTP/1.1 200 OK
Server: nginx/1.6.2 (Ubuntu)
Date: Sat, 08 Aug 2015 15:42:36 GMT
Content-Type: text/plain
Content-Length: 13
Last-Modified: Fri, 07 Aug 2015 07:10:12 GMT
Connection: keep-alive
ETag: "55c459d4-d"
Accept-Ranges: bytes

Hello world!

AB (without -k)

Requests per second: 24213.99
Conversation size: 342 bytes

GET /file.txt HTTP/1.0
Host: 127.0.0.1:8090
User-Agent: ApacheBench/2.3
Accept: */*

HTTP/1.1 200 OK
Server: nginx/1.6.2 (Ubuntu)
Date: Sat, 08 Aug 2015 15:44:02 GMT
Content-Type: text/plain
Content-Length: 13
Last-Modified: Fri, 07 Aug 2015 07:10:12 GMT
Connection: close
ETag: "55c459d4-d"
Accept-Ranges: bytes

Hello world!

Setting settings.defaultKeepAliveTimeout = 0.msecs(); results in lower requests per second and in an exception after a few thousand requests:

std.exception.ErrnoException@../../.dub/packages/vibe-d-0.7.24-rc.2/source/vibe/core/drivers/libevent2.d(281): Failed to bind socket. (Address already in use)

I tried using libasync, and I get an exception everytime at the 100th request(!?).

object.Exception@../../.dub/packages/vibe-d-0.7.24-rc.2/source/vibe/stream/operations.d(202): Reached EOF before reaching end marker.

What kind of log can help you? I can provide a callgrind log file.

On Sat, 08 Aug 2015 16:06:35 GMT, Yazan D wrote:

The code I'm using is available here.

On my windows 8.1 laptop:

I tried this with ./ab -c 1 -n 50000 http://127.0.0.1:8080

Server Software:        vibe.d/0.7.24
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /\=
Document Length:        83 bytes

Concurrency Level:      1
Time taken for tests:   18.917 seconds
Complete requests:      50000
Failed requests:        0
Non-2xx responses:      50000
Total transferred:      11500000 bytes
HTML transferred:       4150000 bytes
Requests per second:    2643.13 [#/sec] (mean)
Time per request:       0.378 [ms] (mean)
Time per request:       0.378 [ms] (mean, across all concurrent requests)
Transfer rate:          593.67 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.6      0       5
Processing:     0    0   1.1      0       5
Waiting:        0    0   1.0      0       5
Total:          0    0   1.2      0       5

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%      0
  95%      5
  98%      5
  99%      5
 100%      5 (longest request)

With your code in vibe.d and libevent in release mode:

C:\Users\Etienne_2\documents\yula> dub run --build=release
Performing "release" build using dmd for x86.
Building vibe-d 0.7.24-rc.2+commit.3.g3d0974f configuration "libevent"...
Building example ~master configuration "application"...
Linking...
Copying files for vibe-d...
Running .\example.exe
min : 0000.33  ms
max : 0003.88  ms
sum : 19967.09  ms
mean: 0000.40  ms
rps : 02504.1 rps

Pretty much the same ... ab might have an advantage if it leaves some headers out, I didn't get more into depth about it, I'll try and understand how you're getting those results.

I tried using libasync, and I get an exception everytime at the 100th request(!?).

Which libasync version did you use for this?

On Sun, 09 Aug 2015 19:26:28 GMT, Etienne Cimon wrote:

I think ab might have some optimizations, will have to check

HTTPClient consistently blocks for 1 msec at HTTP client reading status line

The avg request is 0.3ms on ab so this is definitely the bottleneck.

On Sun, 09 Aug 2015 19:10:23 GMT, Etienne Cimon wrote:

Which libasync version did you use for this?

I am using vibe-d-0.7.24-rc.2 and dub.selections.json file reports libasync at 0.7.5.

$ cat dub.selections.json
{
	"fileVersion": 1,
	"versions": {
		"memutils": "0.4.1",
		"vibe-d": "0.7.24-rc.2",
		"libevent": "2.0.1+2.0.16",
		"openssl": "1.1.4+1.0.1g",
		"libev": "5.0.0+4.04",
		"libasync": "0.7.5"
	}
}

$ uname -a
Linux AW-LAPTOP 4.1.0-040100-generic #201506220235 SMP Mon Jun 22 06:36:19 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

I tried using siege and httperf. Both do not keep the connection alive.

$ siege -b -c1 'http://localhost:8090/file.txt'
** SIEGE 3.0.8
** Preparing 1 concurrent users for battle.
The server is now under siege...^C
Lifting the server siege...      done.

Transactions:		      158145 hits
Availability:		      100.00 %
Elapsed time:		       12.62 secs
Data transferred:	        1.96 MB
Response time:		        0.00 secs
Transaction rate:	    12531.30 trans/sec
Throughput:		        0.16 MB/sec
Concurrency:		        0.90
Successful transactions:      158145
Failed transactions:	           0
Longest transaction:	        0.01
Shortest transaction:	        0.00

$ httperf --port=8090 --uri=/file.txt --num-conns=5000 --num-calls=1
httperf --client=0/1 --server=localhost --port=8090 --uri=/file.txt --send-buffer=4096 --recv-buffer=16384 --num-conns=5000 --num-calls=1
httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to FD_SETSIZE
Maximum connect burst length: 1

Total: connections 5000 requests 5000 replies 5000 test-duration 0.243 s

Connection rate: 20589.1 conn/s (0.0 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 0.0 avg 0.0 max 1.1 median 0.5 stddev 0.0
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000

Request rate: 20589.1 req/s (0.0 ms/req)
Request size [B]: 70.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 0.0 transfer 0.0
Reply size [B]: header 244.0 content 13.0 footer 0.0 (total 257.0)
Reply status: 1xx=0 2xx=5000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.04 system 0.20 (user 14.8% system 84.0% total 98.8%)
Net I/O: 6574.8 KB/s (53.9*10^6 bps)

Right now, I am unsure whether it is useful to spend time on this (vs other stuff) as, I assume, the problem can only be noticed when IO is not the bottleneck, which is a case that is hard to face in practice.

But I am still willing to look further into this if you want me to.