If I pass a timeout with 1ms to epoll_wait,the cpu will not be busy when throughput falls down.

On Wednesday, 27 May 2015 at 08:42:01 UTC, zhmt wrote:
> When I enable the --profle, get something like this, it doesnt give me too much help:
> [...]

Tried callgrind and kcachegrind? If nothing else it's better at illustrating the same output, assuming you have graphviz/dot installed.

Given --dump-instr you can also get instruction-level profiling if you're really wondering what's happening.

On Wednesday, 27 May 2015 at 09:39:42 UTC, Anonymouse wrote:
> On Wednesday, 27 May 2015 at 08:42:01 UTC, zhmt wrote:
>> When I enable the --profle, get something like this, it doesnt give me too much help:
>> [...]
>
> Tried callgrind and kcachegrind? If nothing else it's better at illustrating the same output, assuming you have graphviz/dot installed.
>
> Given --dump-instr you can also get instruction-level profiling if you're really wondering what's happening.

@Anonymouse

Thank u very much, I have tried this:

 valgrind  --tool=callgrind ./gamelibdtest

callgrind_annotate callgrind.out.29234

--------------------------------------------------------------------------------
         Ir  file:function
--------------------------------------------------------------------------------
124,918,002  ???:_D9invariant12_d_invariantFC6ObjectZv [/mnt/hgfs/mydoc/dworkspace/bin/gamelibdtest]
 27,235,809  ???:_D2gc2gc2GC6mallocMFNbmkPmxC8TypeInfoZPv [/mnt/hgfs/mydoc/dworkspace/bin/gamelibdtest]
 22,484,758  /mnt/hgfs/mydoc/dworkspace/gamelibdtest//usr/include/dmd/phobos/std/format.d:_D3std6format74__T14formatUnsignedTS3std6format16__T7sformatTaTiZ7sformatFAaxAaiZ4SinkTaZ14formatUnsignedFNaNfS3std6format16__T7sformatTaTiZ7sformatFAaxAaiZ4SinkmKS3std6format18__T10FormatSpecTaZ10FormatSpeckbZv [/mnt/hgfs/mydoc/dworkspace/bin/gamelibdtest]
 19,171,341  ???:_D2gc2gc3Gcx10smallAllocMFNbhKmkZPv [/mnt/hgfs/mydoc/dworkspace/bin/gamelibdtest]
 16,334,730  ???:pthread_mutex_lock [/usr/lib64/libpthread-2.17.so]
 14,519,760  ???:pthread_mutex_unlock [/usr/lib64/libpthread-2.17.so]
 14,503,272  /mnt/hgfs/mydoc/dworkspace/gamelibdtest/../gamelibd/source/gamelibd/net/linux/epollapi.d:_D8gamelibd3net5linux8epollapi8bitExistFiiZb [/mnt/hgfs/mydoc/dworkspace/bin/gamelibdtest]
 13,521,278  /mnt/hgfs/mydoc/dworkspace/gamelibdtest/../gamelibd/source/gamelibd/net/linux/TcpLinuxConn.d:_D8gamelibd3net5linux12TcpLinuxConn12TcpLinuxConn8readSomeMFAhZi'2 [/mnt/hgfs/mydoc/dworkspace/bin/gamelibdtest]
 12,695,373  ???:_D2gc2gc3Gcx10smallAllocMFNbhKmkZ8tryAllocMFNbZb [/mnt/hgfs/mydoc/dworkspace/bin/gamelibdtest]
 12,558,147  /mnt/hgfs/mydoc/dworkspace/gamelibdtest/../gamelibd/source/gamelibd/net/linux/linuxconn.d:_D8gamelibd3net5linux9linuxconn11handleEventFAS8gamelibd3net5linux8epollapi11epoll_eventZv [/mnt/hgfs/mydoc/dworkspace/bin/gamelibdtest]
 12,091,173  ???:_D4core6thread5Fiber39__T4callVE4core6thread5Fiber7Rethrowi1Z4callMFZC6object9Throwable [/mnt/hgfs/mydoc/dworkspace/bin/gamelibdtest]
 11,153,058  /mnt/hgfs/mydoc/dworkspace/gamelibdtest//usr/include/dmd/phobos/std/format.d:_D3std6format18__T10FormatSpecTaZ10FormatSpec75__T17writeUpToNextSpecTS3std6format16__T7sformatTaTiZ7sformatFAaxAaiZ4SinkZ17writeUpToNextSpecMFNaNfS3std6format16__T7sformatTaTiZ7sformatFAaxAaiZ4SinkZb [/mnt/hgfs/mydoc/dworkspace/bin/gamelibdtest]
 10,877,409  /mnt/hgfs/mydoc/dworkspace/gamelibdtest/../gamelibd/source/gamelibd/net/linux/epollapi.d:_D8gamelibd3net5linux8epollapi8changeEvFiiPviZv [/mnt/hgfs/mydoc/dworkspace/bin/gamelibdtest]
 10,676,006  /mnt/hgfs/mydoc/dworkspace/gamelibdtest/../gamelibd/source/gamelibd/net/linux/TcpLinuxConn.d:_D8gamelibd3net5linux12TcpLinuxConn12TcpLinuxConn9writeSomeMFAhZi [/mnt/hgfs/mydoc/dworkspace/bin/gamelibdtest]
 10,279,096  ???:pthread_getspecific [/usr/lib64/libpthread-2.17.so]
  9,741,852  ???:__GI_memset [/usr/lib64/libc-2.17.so]
  9,645,888  ???:_d_arraycopy [/mnt/hgfs/mydoc/dworkspace/bin/gamelibdtest]
  9,430,244  ???:_D2gc2gc3Gcx5sweepMFNbZm [/mnt/hgfs/mydoc/dworkspace/bin/gamelibdtest]
  8,866,869  ???:_D4core6atomic50__T11atomicStoreVE4core6atomic11MemoryOrderi0TbTbZ11atomicStoreFNaNbNiKObbZv [/mnt/hgfs/mydoc/dworkspace/bin/gamelibdtest]
  8,661,662  /mnt/hgfs/mydoc/dworkspace/gamelibdtest/../gamelibd/source/gamelibd/net/linux/TcpLinuxConn.d:_D8gamelibd3net5linux12TcpLinuxConn12TcpLinuxConn5writeMFAhZi [/mnt/hgfs/mydoc/dworkspace/bin/gamelibdtest]

It seems that  dlang library is not so effient?

On Wednesday, 27 May 2015 at 10:24:59 UTC, zhmt wrote:
> @Anonymouse
>
> Thank u very much, I have tried this:
>
>  valgrind  --tool=callgrind ./gamelibdtest
>
> callgrind_annotate callgrind.out.29234
>
> --------------------------------------------------------------------------------
>          Ir  file:function
> --------------------------------------------------------------------------------
> [...]

Without touching on the actual profile (which I'll leave to those better knowledgeable than I), open those callgrind.out.pid.* files in KCachegrind to get callgraphs.

See https://imgur.com/AZEutCE,XXIDBvB,qehWaHg,bpTxS,3YfcJdh for some examples.

On Wednesday, 27 May 2015 at 10:27:08 UTC, zhmt wrote:
> It seems that  dlang library is not so effient?

The gamelibd could be doing a lot more than just echoing... it sounds to me that your socket might be blocking and epoll is busy looping waiting for it to become available again.

On 5/27/15 2:42 AM, zhmt wrote:
> When I enable the --profle, get something like this, it doesnt give me
> too much help:
>

I don't see any GC function here, I don't think you are are focusing on the right portion of the code. Seems like the gamelib library is consuming all the time. You may want to check with the author of that code for help.

-Steve

On Wednesday, 27 May 2015 at 05:48:13 UTC, zhmt wrote:
> 

The code you posted is the client code, but the issue seems to be on the server side.
Can you post the server code and also the timing code?

On Wednesday, 27 May 2015 at 19:04:53 UTC, Márcio Martins wrote:
> On Wednesday, 27 May 2015 at 05:48:13 UTC, zhmt wrote:
>> 
>
> The code you posted is the client code, but the issue seems to be on the server side.
> Can you post the server code and also the timing code?


@Márcio Martins

here is the server code：

void echoServer()
{
	Acceptor acc2 = new Acceptor();
	acc2.listen("0.0.0.0",8881,100);
	acc2.accept((Ptr!Conn c){
			scope(exit) c.close();
			
			ubyte[5] buf;
			while(true)
			{
				int n = c.readSome(buf);
				if(n<=0){
					break;
				}
				c.write(buf[0..n]);
			}
			writeFlush("close server sock");
		});
}

and I found the reason：
the buffer size on server is too small， just five，so if the data size is more than 5（10000 for example），it will need two read operation。

The length of “10000” is 5，it perfectly matched the point of falling down。
If change the buffer size to 100， it runs well。

But why it falls sharply down to about 24，I will continue to study。

I think it is not problem of gc, it is my fault:
The operations is serialized:
clent send  -> server recv  -> server send  -> client recv,
so if one operation takes too long time, the throughput will definitely fall down.

I cant explain why it so fast when buffer is big enough, and so low when buffer is smaller than data size.