On Wednesday, 15 November 2017 at 23:04:46 UTC, kdevel wrote:
> On Wednesday, 15 November 2017 at 13:31:46 UTC, Daniel Kozak wrote:
>> This one works ok for me, but I am on linux: https://dpaste.dzfl.pl/f54decee45bc
>
> It works, but it does not handle two connects in parallel. STR:
>
> 1. start the binary in console 1
> 2. telnet localhost 4444 in console 2
> 3. telnet localhost 4444 in console 3
> 4. enter a [RETURN] in console (3)
>
> observed: nothing (the "thread" handling the first connect blocks)
> expected: response
>
> On my machine defaultPoolThreads() returns 1. This can easily be increased:
>
> ```
>    defaultPoolThreads(8);
> ```
>
> There is also another problem with Socket.select: It may return -1. This frequently happens when the ACCEPT socket is non-blocking and the select is interrupted (by the GC?) then errno == EINTR.
>
> Also not having a timeout in the Socket.select of handle_socket allows for DOS attacks like the one above. In case of a timeout select also returns -1.

Hi Guys,

so i have tried the latest changes with destroy(socket) rather than socket.close().

Still the program is extremely slow.

I see that the httpclinet is making successfully 100 request at a time and then it freezes for 5/10 seconds and then it process another 100 request.

As Kdevel pointed out, this could be related to the Socket.select blocking on the interupt or it would be GC kicking in.

I also have seen the value computed for the defaultThread is not correct, hence i manually started the TaskPool(int thread) manually.

I'm going to share my benchmark program so you can guys test with the same tool.

Unfortunately it seems that there is some underline issue which is blocking the program and preventing to process all the incoming requests in a performant fashion, or at-least utilising the full CPU cycles.

reagrds

ade90036

Hmm works ok for me. What OS?

Dne 16. 11. 2017 12:05 dop. napsal uživatel "kdevel via Digitalmars-d-learn" <digitalmars-d-learn@puremagic.com>:

> On Wednesday, 15 November 2017 at 13:31:46 UTC, Daniel Kozak wrote:
>
>> This one works ok for me, but I am on linux: https://dpaste.dzfl.pl/f54decee45bc
>>
>
> It works, but it does not handle two connects in parallel. STR:
>
> 1. start the binary in console 1
> 2. telnet localhost 4444 in console 2
> 3. telnet localhost 4444 in console 3
> 4. enter a [RETURN] in console (3)
>
> observed: nothing (the "thread" handling the first connect blocks)
> expected: response
>
> On my machine defaultPoolThreads() returns 1. This can easily be increased:
>
> ```
>    defaultPoolThreads(8);
> ```
>
> There is also another problem with Socket.select: It may return -1. This frequently happens when the ACCEPT socket is non-blocking and the select is interrupted (by the GC?) then errno == EINTR.
>
> Also not having a timeout in the Socket.select of handle_socket allows for DOS attacks like the one above. In case of a timeout select also returns -1.
>

On Thursday, 16 November 2017 at 18:20:36 UTC, Daniel Kozak wrote:
> Hmm works ok for me. What OS?
>
> Dne 16. 11. 2017 12:05 dop. napsal uživatel "kdevel via Digitalmars-d-learn" <digitalmars-d-learn@puremagic.com>:
>
>> [...]

I'm running MacOS..

It works for me because I have multiple threads, but when I use only one
thread per pool (defaultPoolThreads(1)), it obviosly blocks, which is
correct behavior

On Thu, Nov 16, 2017 at 7:20 PM, Daniel Kozak <kozzi11@gmail.com> wrote:

> Hmm works ok for me. What OS?
>
> Dne 16. 11. 2017 12:05 dop. napsal uživatel "kdevel via Digitalmars-d-learn" <digitalmars-d-learn@puremagic.com>:
>
> On Wednesday, 15 November 2017 at 13:31:46 UTC, Daniel Kozak wrote:
>>
>>> This one works ok for me, but I am on linux: https://dpaste.dzfl.pl/f54decee45bc
>>>
>>
>> It works, but it does not handle two connects in parallel. STR:
>>
>> 1. start the binary in console 1
>> 2. telnet localhost 4444 in console 2
>> 3. telnet localhost 4444 in console 3
>> 4. enter a [RETURN] in console (3)
>>
>> observed: nothing (the "thread" handling the first connect blocks)
>> expected: response
>>
>> On my machine defaultPoolThreads() returns 1. This can easily be
>> increased:
>>
>> ```
>>    defaultPoolThreads(8);
>> ```
>>
>> There is also another problem with Socket.select: It may return -1. This frequently happens when the ACCEPT socket is non-blocking and the select is interrupted (by the GC?) then errno == EINTR.
>>
>> Also not having a timeout in the Socket.select of handle_socket allows for DOS attacks like the one above. In case of a timeout select also returns -1.
>>
>

On Thursday, 16 November 2017 at 18:44:11 UTC, Daniel Kozak wrote:
> It works for me because I have multiple threads, but when I use only one
> thread per pool (defaultPoolThreads(1)), it obviosly blocks, which is
> correct behavior
>


Ok, let me force the: "defaultPoolThreads(8)" and let me re-test it.

By the way, if the socket is blocking you can remove all the socketSet and the socket.select as they are not needed anymore.

like this.. https://dpaste.dzfl.pl/ca09e4c54789

Result:

bombardier -c 200 -n 10000 http://localhost:4444

Bombarding http://localhost:4444 with 10000 requests using 200 connections
 10000 / 10000 [===========================================================================================================================] 100.00% 1m24s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec       122.27     909.33      20363
  Latency       49.98ms   192.16ms      1.07s
  HTTP codes:
    1xx - 0, 2xx - 9999, 3xx - 0, 4xx - 0, 5xx - 0
    others - 1
  Errors:
    the server closed connection before returning the first response byte. Make sure the server returns 'Connection: close' response header before closing the connection - 1
  Throughput:    36.89KB/s

Mediocre result... let me create a java equivalent program so we have a direct comparison......

>
> Mediocre result... let me create a java equivalent program so we have a direct comparison......

These are the tests for a similar program in java.

bombardier -c 200 -n 10000 http://localhost:8081

Bombarding http://localhost:8081/ with 10000 requests using 200 connections
 10000 / 10000 [==============================================================================================================================] 100.00% 0s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec     24527.29   14797.09      46439
  Latency        8.25ms    15.52ms   235.79ms
  HTTP codes:
    1xx - 0, 2xx - 10000, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:     3.87MB/s

So, what is next?

Can we enable some sort of profiling to see what is going on?

can you post both code, java and d, for sure we are all testing the sames

On Thu, Nov 16, 2017 at 8:37 PM, ade90036 via Digitalmars-d-learn < digitalmars-d-learn@puremagic.com> wrote:

> So, what is next?
>
> Can we enable some sort of profiling to see what is going on?
>

On Thursday, 16 November 2017 at 19:37:31 UTC, ade90036 wrote:
> Can we enable some sort of profiling to see what is going on?

You may compile the code with dmd -g -O -profile -profile=gc

I currently struggle getting meaningful output. I want to terminate the program after a number (say 400) handled requests. When returning from main the program hangs, so I call exit.

The running binary now produces a trace.log but even after wrapping
new SocketSet(); into

```
auto socket_set_allocation_wrapper ()
{
   writeln (__FUNCTION__);
   return new SocketSet();
}
```

I see the invocations in handle_socket in the console but not in trace.log.