Ubuntu上のAsyncで遅延 – BlackJumboDog CoreCLR

ずーっと気になっていたんですが、Ubuntu上でサーバーのTCPソケットをAcceptAsyncかけていたら、しばらくアクセスがない状態だと1秒程度の遅延が発生していました。そして、連続したアクセスだとこれは起きなかったんです。

元々のBjdではWhileとSleepによるポーリングを行っていたので、おそらくそんなことは起きなかっただろうと思っています。(そもそも、Begin/Endが動かなかったので、根拠はない!)

同じことが、ManualResetEventSlimeでも起きました。ある程度時間がたったときに、シグナルセット後のWait解放が1秒くらい。これ、Windowsでは起きなかったんですよね。

正直、そこまでプラットフォームに詳しい人間ではないので、なぜこうなるのか?は理解できませんでした。ただ、どうすれば?に関しては、「深い眠りにつかないようにする」っていう発想で回避しました。

https://github.com/darkcrash/bjd5/commit/a9049f8630d2e788dda19065026c415654efcd05#diff-c042d296432145429c9f5f4d27bfef99

     -            tTcp.Wait(this.Kernel.CancelToken);  
 94   +            while (true)  
 95   +            {  
 96   +                if (tTcp.Wait(2000, this.Kernel.CancelToken))  
 97   +                    break;  
 98   +                if (tTcp.Status == TaskStatus.Canceled)  
 99   +                    break;  
 100  +            }

Waitを2秒までとして、完了時はループを抜け、キャンセル時もループを抜けます。こうすることで2秒に一回このWaitが実行されます。そして、結果として遅延1秒はなくなりました。

SpinWaitの絡みとか、タイムスライスのルールとかありそうなんですが、ブラックボックスです。Darkが作るBlackなだけに・・・

これが、Kernelによるものなら、今後もこういう仕様ということになるでしょうし、.Net Coreのものであれば、改善されていくかもしれません。ので、現時点ではこのコードは、一つの回避策として整理してくださいませ!

それでは!

BlackJumboDog CoreCLR Ubuntu – Socketの置き換え APMからTAPへ

こんにちは!いきなり動いてるスクリーンショットから!!(Azure上のUbuntu14.04で動かしている様子です。)

というのも、動いてるだけでもすごいっていう気持ちを伝えたかったわけですが、今回に至るまでに行った変更点

  1. System.Net.Socketsのバージョンを他と統一し「4.1.0-beta-23516」としました。
  2. それに伴って、APMの実装は捨てられたため、TAPに書き直しました。
  3. パスの置換(\→.Netが提供するCharフィールド)を進めて動かしてみたところ、パスの置換が空回りして無限ループ!→修正済
  4. CPU利用率が起動直後で安定していても、10%以上という状況で、Thread.SleepをManualResetEventSlimに置換→アイドル中のレスポンスに1秒の遅延が発生。→検討中
  5. ConsoleTraceListenerの負荷がかかりそうなので、専用のタスクスケジューラ実装
  6. ログをそれっぽくフォーマットしました。

前回記事の、Begin/EndなどのAPM(非同期プログラミングモデル)なソケット実装がないとエラーになってました。これは、上のリンク先の通り、廃止されていくようです。このIssues(上と同じリンク) でその理由が書かれていました。Windowsに依存したようなものは排除する!っていう面白い話ですね。

ただ、これ変えてしまうと、そもそもポーリングしてるロジックとか全部作りなおしなわけで、結構時間かかってました&まだ懸念点が残ってます。行き詰っていろいろ試したのもあって、ソースの履歴が激しいことになっていてごめんなさいというところです。

また、ぜんぜん気づいていなかったのですが、Traceで出力したものは、Defaultのlistenerか何かによってだとは思いますが、しっかりとSyslogに出力されていました。(これはちょっと驚いた)

大物のWebServerが動いたので、懸念点を解消しつつデプロイ方向にシフトしていきます。

それではまた!