{デライト高速化}{希哲15年2月21日の日記}{機会損失の最小化}{放置状態}{KDN}{希哲15年2月21日}{Schema.org}{デライト文書構造最適化}{中景輪符整理}{検索演心教育}...=}(30)

{希哲15年2月21日の開発 K#F85E/A-E74C-0B9C}

デライト文書構造最適化SEO 向けの作業一段落した。

長いこと SEO に関しては放置状態に近かったが,HTML5Schema.org活用してそれなりの形にはなった。 SEE にとっても大きな進歩だ。機会損失の最小化を考えると出来るだけ早く済ませておきたかったので割とあっさり終わって良かった。

これからの文書構造最適化中景輪符整理など領当て保守性観点から必要な作業中心になるだろう。

SEO に加え第三次宣伝攻勢も始まればデライト高速化も急ぐ必要があるが,CDN に関してはやはり依存を避けつつ,体系的に上手く利用出来るようにしておきたい。

この体系KNEST一環として「KDN」(knowledge delivery network)と呼んでおくことにした。

=}
{デライト高速化}{知識配信網}{CDN}{KNEST}{宇田川の用語}=}(5)
{デラング}{希哲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歩)など。

{CDN}{DNS}=}(2)
{CDN}
{}