タグ

アーキテクチャに関するsyanbiのブックマーク (5)

  • アーキテクチャ設計の難しさについて - arclamp

    アーキテクチャについては、以下のパワポを見て頂くとして。 なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423 from yusuke suzuki アーキテクチャ設計を要約すると「"何をやるか"と"どうやるか"のバランスを取る事」となります。 "何をやるか"というのは"システムのミッション"のことであり、ソフトウェア品質モデルで言うところの"利用時の品質"、つまりはシステムのユーザーが何を達成したいのかということです。これは「このシステムが動き出した時、どんな価値を生み出すべきか」を考えることになります。 次に"どうやるか"というのは、2つの話があると思っています。1つめは"静的な構成"としてのどうやるか。2つめは"動的なプロセス"としてのどうやるか。 "静的な構成"というのはクラス構成であり、設定ファイルの構成であり、フレームワークの構成であり、つまり、システ

    アーキテクチャ設計の難しさについて - arclamp
  • 並列イベント駆動I/Oフレームワーク「mpio」リリース - Blog by Sadayuki Furuhashi

    分散KVS kumofs のコードは、全体で約2万行です*1。 そのうち、ネットワークI/Oやプロトコルに関するコードは約1万行*2で、全体の約半分を占めています。 ロジックは残りの半分*3だけで実装されています。 この実例から分かりますが、kumofsのような分散アプリケーションを開発するにはI/O周りの実装が大変で、とてつもなく大きな障壁になっています。*4 さらに今日では、性能を稼ぐためにマルチスレッド化が必須です。また、多数のクライアントを少ないリソースで効率よく相手にするには、非同期・イベント駆動型のアーキテクチャも必要になります。さらに、究極的な性能を達成すべく GC を利用しない C++ においては、実装のみならず設計も大変です。 これに加えてソケットAPIの難解な挙動に対処にしなければならないため、C言語やC++によるネットワークプログラミングは、vimの使いこなしなどと同

    並列イベント駆動I/Oフレームワーク「mpio」リリース - Blog by Sadayuki Furuhashi
  • スカウターとスパコン - プログラマーの脳みそ

    先日、非IT系の友人のパソコンが壊れたらしく、買い換えるのだが何を選べばいいのか?という相談を受けたのだけど、「ネット見るだけならEeePCでも十分だぜ」的なことを言ってやった。やれCPUは何がいいんだとか聞かれても説明に困る。Core2Duoのクロック周波数が低いけど性能どうなの?とかさ。 CPUのクロック周波数といえば、1990年代後半〜2000年代前半ぐらいまではIntelが「クロック周波数が高い=ハイスペック」というプレゼンを盛んにやってて、対AMDとのバトルを優位に進めようとしていた。Intelはクロック周波数というのが高ければいいんだよ!と、素人向けに製品を選ぶ尺度を与えた。この尺度は当は正しくないのだけど、まったく嘘というわけではない。CPUを選ぶ際のスカウター*1をIntelは消費者に与えたのだ。ほら、うちのCPUのほうがクロック周波数高いでしょ、うちのを買いなさい、と。

    スカウターとスパコン - プログラマーの脳みそ
  • ネットワークプログラムのI/O戦略 - sdyuki-devel

    図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド・イベント駆動 コネクションN:スレッド1。epoll/kqueue/select を1つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える: サーバーにメッセージを送信 イベントハンドラを登録;このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す 1コネクション1スレッ

    ネットワークプログラムのI/O戦略 - sdyuki-devel
  • Firebirdのアーキテクチャと特性、歴史 (1/3) - @IT

    Yet another OSS DB:Firebird(1) Firebirdのアーキテクチャと特性、歴史 Firebird日ユーザー会のはやしつとむです。今回からFirebirdについて連載をさせていただくことになりました。第1回に当たる今回は、Firebirdとはどんなデータベースで、誰が作ってきたのかなどを中心にまとめています。今後の予定は、Firebirdのデータベースファイルの内部構造、標準関数、User Defined Functionの作成について、といった流れを予定しています。この連載を通じて、Firebirdのファンが1人でも増えてくれることを願っています。 Firebirdのインストールから起動まで さて、firebirdとはいったいどんなRDBMSだろう? 今回は、手始めに導入の手順はもちろんだが、Firebirdが生まれた背景や、アーキテクチャの特性にも触れたいと

  • 1