BT

きれいで代表的なモデルが高性能

| 作者: Jan Stenberg フォローする 29 人のフォロワー , 翻訳者 徳武 聡 フォローする 0 人のフォロワー 投稿日 2014年6月29日. 推定読書時間: 2 分 |

原文(投稿日:2014/06/22)へのリンク

先頃ロンドンで開催されたDDD Exchangeで、Martin Thompson氏は、自分の書いたコードが全く最適化されておらず、コードがきれいなきわめて性能の良いシステムを開発することができるはずだ、と語った

氏はハイパフォーマンスシステムの世界で働いており、世界有数のカタログシステムや秒間に大量のイベントが発生する高トランザクションシステムを手がけてきた。氏の経験によれば、ハイパフォーマンスなコードは汚くて読めたものではないという一般的な理解とは反対で、性能とはモデルのきれいさや表現力にかかっている。

氏のふたつのコンセプト、きれいであることと代表的(representative)であることは、DDDの意味するところにも通ずる。きれいなモデルはドメインの言葉とデータ構造だけを含んでいる。SpringORMといった技術要素が現れれば、性能問題を起こし、モデルのメンテナンスや進化を阻害してしまう。モデルはドメインの理解を捉えているときが最高だ。そのときが問題領域を捉えている生き生きとしたモデルなのだ。

ハイパフォーマンスシステムの場合、内部のサーバやCPUを考慮するのはとても大事だ。氏はデータの在処によってコード実行の速度がいかに変わるかを説明した。例えばローカルキャッシュからメモリへデータが移動すると遅延が高まる。

氏は性能を考慮したモデルの実装についていくつかのヒントを示している。

  • 参照のローカリティを尊重する。凝集度の高い分離されたコンテキストで、きれいで通信が最小化されているの最も適切。氏が言うには、優れた設計原則はフラクタルだ。つまり、小さくても大きくても問題なく動作する。
  • データ構造になじむ。エンティティを忘れてエンティティ間の関連に着目する。
  • オンラインシステムにとってバッチ処理は優れている。同一のリソースにマルチスレッドでアクセスすると不快なキューイング問題が発生するかもしれない。これをキューとバッチ処理で仲介することでスループットは向上する。
  • 抽象化について。氏は抽象化を使わない。高コストだからだ。みな、すぐに抽象化したがるというのが氏の考えだ。抽象化の代わりにコピーをして、まったく同じものだという確信を得たときにだけ抽象化するべきだ。

氏は最後に、継続的統合のひとつのプロセスとして性能テストをする必要があると強調した。そして次のように語り、プレゼンを終わりにした。

モデルが優れており、エレガントだったら、性能も良いのです。

来年のDDD Exchangeは2015年6月19日に開催される予定。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT