{デラング}{希哲14年8月23日の日記}{通信方法}{水平拡大}{KNEST 隠し}{KNEST::cch_T}{プロセス内隠し}{隠し戦略}{希哲14年8月23日}{拡縮性}...=}(76)

{希哲14年8月23日の開発 K#F85E/A-5B28-17C0}

デライト隠し戦略隠し機構について検討し,「KNEST 隠し」を考案,今後の方針として採用することを決めた。これも長らく課題としていたことで,大きな前進だった。

KNEST 隠しでは,各捌き手プロセス内隠しKNEST を通して同期する。通信方法はいくつか考えられるが,台数が少ないうちは単に外部から空了出来るようにするだけでも十分だろう。

これまで,デルンではプロセス内隠しxtd::cch_)を使って月庭高速化にある程度成功していたが,プロセス捌き手間での同期問題があり,使える場面は限られていた。

Memcached導入なども検討したことがあるが,どうも帯に短し襷に長しという感じが否めず,デライトぴったり解決策が見つかっていなかった。

15日6歩で,libxpo.Pg を利用して PostgreSQL隠し捌きとして使ってしまうことも考えた。それはそれであってもいいが,やはりウェブ捌き制御したいことも多々あり,根本的な解決策にはならなかった。

KNEST 隠しは,プロセス内隠しというHTTP というでゆるやかに連携させるという手法であり,デライト運用必要拡縮性を上手く確保出来そうだ。

デライト拡縮性における最後の問題がウェブ捌き水平拡大だったため,これによって安定拡大戦略を支える技術が出揃ったとも言える。

出場捌き水平拡大はとりあえず履複化でいいとして,ウェブ捌きの水平拡大における同期KNEST を通して行なう。これは接渉管理にも応用出来るだろう。あとは流量制御しつつ,適宜 CDN などを利用する。請い手側では PWA高速化していく。

戦略が定まったことにより,目先最適化着手しやすくなった,というのも大きい。どう作業していくかについて迷いが消えた。こんなことを考え始めたのも,デライトの宣伝本格化させる前に,性能課題に対する見通しをつけておきたかったからだ。

早速,KNEST::cch_T実装に取りかかることにした。

その他,デラング構文解析についての検討8歩)など。

{隠し戦略}
{}