コンピュータの神.... サイバー戦.... 広告作業.... 人間集団 「H’s」.... Google検索.... グーぐる.... gu-guru....

'91から続く「インターネットの基礎知識」のWEBサイト版。「コンピュータの神」 を戴く 「一般人」 たちが、知られざるサイバー戦の実態や、メディア界・コンピュータ界の最新状況を紹介しています。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

広告効果とリンク サイバー戦の基礎知識と、コンピュータの神との対話

 会社や商品、ウェブページなどを宣伝するには、広告的作業が必要となり、その最大の方法はリンクです(ウェブページにはホームページ、WIKI、ブログなどがあり、ウェブページでウェブページを宣伝するのはテレビの番宣と同じ、ということになります)。
 リンクとは、自分のサイトから他のサイトに飛べるようにすることですが、実は、(多くの人が勘違いしているのですが)そのメインの意義は、ジャンプ先のサイトの情報を訪問者が見れることではありません。自分のサイトの出先がどこにあるか(会社の事務所なら業種のメッカ的住所や話題性の高い建物)、また、自分のサイトにどこが出先を持っているか(企業なら有力企業が自分の会社と関係を持っているか)、というネット上の証拠(証明)なのです。それによって、そのサイトの信頼性や話題性が変化するわけです。リンクすることでマイナスになる代表はアダルトサイトであり、プラスになる代表は膨大なアルゴリズムを持った大手話題サイトです。

 最近では、上記のような常識に加え、静的リンク・動的リンク、という言葉がよく使われます。

 一般的には、静的リンクとは「直接リンク先にリンクを飛ばす方法」、動的リンクとは、「間にCGIなどを挟んで最終的にリンク先にリンクを飛ばす方法」、と定義されています。なぜ間に挟むか。これは訪問者数のカウントをする理由を筆頭に、様々な理由が考えられます。筆頭の理由からして、ランキングサイトは動的リンクが多いといえます。なぜなら動的リンクは、CGIで作られたページである以上、検索ロボットに登録されにくい構造だからです。一方、静的リンクは検索ロボットと相性が良く、頻繁にロボットが訪れ、リンク先を訪問して、貴方のサイトへ行き、インデックス登録に繋がりやすい、また被リンクを受けている良質なサイトだと判断されやすく、上位表示にも役立ちます。
 だからこそ、静的リンクを謳うサイト集に人気が集まるわけですが、専門家でなければ詳細を調査できないのが難点です。
 当サイトと同じ 「チームH(旧3Hに新たな4Hが加わった状態)」 主催の 大手サイト集比較 でいう「送信状態」という一言には、この形式差によるデータ送信の実量なども総合的に加味されていますので、大手サイト集比較 のエンジン推奨ポイントは参照するに値するでしょう。

 静的リンクは、Apacheなどの実行ファイルそのものにモジュールを組み込む方式ですから、例えばApacheとモジュールは、バイナリ的に一体化して動作します。これに対し、動的リンクは、モジュールを別ファイルとして作成し、必要に応じてモジュールのファイルから機能を呼び出す方式です。この機能を「DSO(Dynamic Shared Object=動的共有オブジェクト)」と呼び、動的リンクされるモジュールのファイルは、拡張子が「so」となります。この場合、あらかじめ「mod_so」モジュールを静的リンクしておく必要があります。
 動的リンクはモジュール機能の呼び出しで静的リンクよりも負荷が高くなる(オーバーヘッドがかかる)、というデメリットがありますが、再起動のみでモジュールを組み入れたり外したり出来るメリットもあり、静的リンクは逆に高速にモジュール機能を呼び出せるが、モジュールを入れたり外すのには再コンパイルの手間がかかるため、静的リンクの場合、不要なモジュールも組み込みっぱなしにしてしまうことが多くなります。この場合、余計なCPU負荷とメモリの無駄使いとなるわけです。
 多くのウェブ・アプリケーションは、Apacheなどが提供する環境と機能を想定して設計されています。例えばApacheは、LAMP(Linux、Apache、MySQL、PHP/Perl/Python)と呼ばれる非常に人気のあるウェブサーバコンポーネントの一つでもあり、様々な商用パッケージ、例えば Oracle Database や IBM WebSphere Application Server の一部として再配布されています。Mac OS XやNetWare 6.5の標準Webサーバにもなっており、Yahooが1996年よりApacheを利用、その後、数千台のWebサーバにカスタマイズしたApacheを導入、一日数十億のアクセスを処理していることなどから、信頼されつつあります。我々からすると「稚拙」ともいえるのですが、一般のユーザーからすれば使いやすく、また安価な割にセキュリティ面の心配が少ない、という点が評価されているようです。

 Apacheは、プロセスの基本的な挙動として3つの方式を持っています。
 一つはprefork(プリフォーク)。プリフォークとは、「スレッドを使わず、先行して fork を行なうウェブサーバ」です。Apacheは伝統的に親プロセスを1つ持ち、クライアントからリクエストが来ると自分自身をコピーして子プロセスを起動します(これをforkと言います)。実際の通信は子プロセスが受け持つため、通信している数だけ子プロセスが起動することになり、この時、クライアントからリクエストを受けたあとでforkすると、fork完了までに待ち時間ができ、通信のパフォーマンスが遅くなるのです。そのため、あらかじめいくつかの子プロセスをforkしておき、forkの待ち時間をなくす方式をとっています。この方式こそが「prefork」です。すなわち“pre(=前もって)”forkしておく、という意味です。preforkのメリットは、forkされた子プロセス1つ1つが対応する通信を受け持つため、ある子プロセスが何らかの原因でフリーズしたとしても、他の子プロセスには影響を及ぼすことが無く通信を継続できる点です。このため、安定した通信を行うことが出来ます。ただしクライアントが多くなればなるほど子プロセスの数も増えるため、使用メモリ量やCPU負荷が比例的に増大していくことになり、preforkで多数のクライアントをさばくには、それに応じた大量のメモリと高速なCPUが必要、ということになります(もちろんスレッドセーフでないモジュールを使う場合は、preforkを利用すべきです)。
 二つ目は、worker。workerは「マルチスレッドとマルチプロセスのハイブリッド型サーバ」です。Apacheの子プロセス1つ1つがマルチスレッドで動作し、スレッド1つが1つのクライアントを受け持つ方式で、すなわち、1つのプロセスがマルチスレッドを利用して複数の通信を担当することになります。この点で1つのプロセスが1つの通信をみるpreforkとは異なり、また多くの子プロセスを起動せずに済むため、メモリの使用量も減らすことが出来るます。ただしマルチスレッドは安定して動作させるためにノウハウが必要で、モジュールはスレッドセーフである必要があるため、workerを使用する際は事前に十分な安定性のテストを行うべきでしょう。
 三つ目はeventです。eventはworkerの一種ですが、マルチスレッドで動作する。workerとの違いはKeep-Alive(持続的接続)の処理方法です。workerやpreforkは、Keep-Aliveの持続性を保つために一度利用したスレッド・プロセスをそのまま待機させています。しかしクライアントからの接続が持続的に行われる可能性は保証されているわけではないですから、待機していること自体が無駄になる可能性もあります。そこで、Keep-Aliveの処理を別のスレッドに割り振って通信を処理する、といった方式を採るわけです。ただし、この方式は、よほどの専門家がリアルタイムで管理していなければ、使用すべきではありません(インターネット上などでこの方式をPRしていても、気軽に使用すべきではありません)。こうした方式で効率的に運用できる人間はウェブの世界で一定の知名度があるような専門家だけ、とみるべきで、こちらに直接確認してください。

 リンク編集では、一般的に、コンパイラ、アセンブラなどによって生成された入力ファイルを受け取ります。リンカーは、これら入力ファイル内のデータを連結および解釈、1 つの出力ファイルを生成し(このとき様々なオプションを使用できます)、出力ファイル (入力再配置可能オブジェクトの連結) は、基本的に次のいずれかの形式になります。
 一つは再配置可能オブジェクト。後続のリンク編集段階で使用される、入力再配置可能オブジェクトの連結。
 二つ目は静的実行可能ファイル。すべてのシンボル参照が実行可能ファイルに結合され、実行待機中のプロセスを表現する入力再配置可能オブジェクトの連結。
 三つ目は動的実行可能ファイル。実行可能プロセスを生成するときに、実行時リンカーによる割り込みを必要とする入力再配置可能オブジェクトの連結。
 四つ目は共有オブジェクト。実行時に動的実行可能ファイルに結合される機能を提供する入力再配置可能オブジェクトの連結。また、共有オブジェクトの中にも、他の共有オブジェクトに依存する依存関係がある場合もあります。動的実行可能ファイルのシンボル参照は、実行時に結合される必要があり、動的実行可能ファイルには、共有オブジェクトの形式で1つ以上の依存関係を割り当てることができます。これらの出力ファイルと、出力ファイルを作成する場合に使用するキー・リンカー・オプションについては以前の講義で紹介した通りです。

 「動的実行可能ファイル」と「共有オブジェクト」を、まとめて「動的オブジェクト」と呼んだりもします。
 実行時リンクには、通常、過去のリンク編集から生成された1つまたは複数のオブジェクトの結び付けが組み込まれ、実行可能プロセスを生成します。リンカーによるこれらのオブジェクトの生成中に、結び付けの必要条件が検証され、該当する登録情報が各オブジェクトに追加され、実行時リンカーの読み込み、再配置、結合プロセスの完了が可能になります。
 プロセスの実行中に、実行時リンカーの機能も使用可能になり、この機能を使用すると、要求に応じて追加共有オブジェクトを追加して、プロセスのアドレススペースを拡張できます。実行時リンクに組み込まれたコンポーネントのうち、最も一般的なのは、「動的実行可能ファイル」と「共有オブジェクト」の2つです。
 動的実行可能ファイルとは元来、実行時リンカーの制御下で実行されるアプリケーションのことです。これらのアプリケーションは、通常、共有オブジェクト形式の依存関係を持ち、これらは、実行時リンカーによって配置および結合されて、実行可能プロセスが作成されます。動的実行可能ファイルは、リンカーによって生成されるデフォルトの出力ファイルになります。
 共有オブジェクトは、動的にリンクされたシステムに対し、キー構築ブロックを提供します。共有オブジェクトは動的実行可能ファイルに類似していますが、 共有オブジェクトには、仮想アドレスが割り当てられていません。
 動的実行可能ファイルは、通常、1 つまたは複数の共有オブジェクトに依存する依存関係を持ちます。つまり、共有オブジェクトは、動的実行可能ファイルに結合され、実行可能プロセスを作成する必要があります。共有オブジェクトは多くのアプリケーションで使用できるため、その構造上の観点は、共有性、バージョン管理およびパフォーマンスに直接影響します。
 共有オブジェクトが使用する「環境」を参照することにより、リンカーまたは実行時リンカーのいずれかによって共有オブジェクトの処理を識別することができるのです。
 コンパイル環境として、共有オブジェクトは、リンカーによって処理され、動的実行可能ファイルまたは他の共有オブジェクトを生成します。共有オブジェクトは、生成される出力ファイルの依存関係になります。一方、実行時環境として、共有オブジェクトは、動的実行可能ファイルとともに実行時リンカーによって処理され、実行可能プロセスを作成します。

 これらの基本知識を総合すると、動的リンクとは、「実行可能プロセスを生成する際に、動的実行可能ファイルと共有オブジェクトの実行時リンクとともに、これらのオブジェクトを生成するリンク編集プロセスの一部分を受け入れる場合に使用する用語」、と定義することができます。
 動的リンクを使用すると、実行時にアプリケーションを共有オブジェクトへ結合できるようにするため、共有オブジェクトが提供するコードを複数のアプリケーションで使用できます。標準ライブラリのサービスからアプリケーションを切り離すことにより、動的リンクも、アプリケーションの移植性および拡張性を向上させることができるのです。サービスのインタフェースと実装が独立しているため、アプリケーションの安定性を維持しながら、システムを更新することができます。動的リンクはまた、ABI (アプリケーション・バイナリ・インタフェース) などを利用するときに必要で、Solarisアプリケーションなどに適したコンパイル方式、とも言えます。
 XL Fortranのような、ごく簡単なアイテムを使用するだけで、ご使用のプログラムは(動的リンクでも静的リンクでも)オペレーティング・システム機能の利点を利用できるようになります。
 動的リンクとはつまり、プログラムが初めて実行された時に、外部ルーチン用のコードが探し出されてロードされることなのです。共用ライブラリーを使用するプログラムをコンパイルすると、デフォルトではプログラムに動的にリンクされます。動的にリンクされたプログラムは、共用ライブラリーのルーチンを複数のプログラムが使用していても、ディスク・スペースも仮想メモリーも殆ど取りません。
 ライブラリー・ルーチンとの命名の競合を回避するための、リンク中に行われなければならないとされる特別な予防措置も、必要とされません。いくつかのプログラムが同時に同じ共用ルーチンを使用する場合は、静的にリンクされたプログラムより良好に動作する場合があります。また、動的リンクを使用すれば、再リンクしないで共用ライブラリー内のルーチンをアップグレードすることができます。このリンク形式はデフォルトなので、これをオンにするのに追加のオプションは必要ない、というわけです。

 そして静的リンクとは、プログラムによって呼び出されるすべてのルーチン用コードが、実行可能ファイルの一部になることを意味するのです。
 静的にリンクされたプログラムは、XL Fortranライブラリーなどがないシステムに移動し、そのシステム上で実行することができます。静的にリンクされたプログラムが、ライブラリー・ルーチンへの呼び出しを多数行ったり、多数の小さなルーチンを呼び出す場合、それらのプログラムは動的にリンクされたプログラムよりも良好に動作する場合があります。ライブラリー・ルーチンとの命名の競合を回避したい場合は、プログラム内のデータ・オブジェクトおよびルーチンの名前を選択する時、何らかの予防措置をとる必要があります (リンク中の命名競合の回避の部分で説明済)。また、それらのプログラムをあるシステム上でコンパイルした後、別のレベルのオペレーティング・システムを使用したシステム上で実行すると、機能しない場合がある、ということになります。
 コンパイラー・コマンド行で -b リンカー・オプションなどを使用して静的にリンクされたオブジェクト・ファイルを作成することもできます。(xlf95 -bnso -bI:/usr/lib/syscalls.exp file1.f file2.f)
 xlf_r、xlf_r7、xlf90_r、xlf90_r7、xlf95_r、または xlf95_r7 コマンドと静的にリンクしているときは、 -bI:/usr/lib/threads.exp も指定する必要があります。 非同期 I/O を使用している場合は、-bI:/usr/lib/aio.exp も指定する必要があります。
 -bnso オプションは、プログラムが参照するライブラリー・プロシージャーをプログラムのオブジェクト・ファイルに置きます。サフィックス .exp が付いているファイルは、システムからプログラムにインポートする必要があるシステム・ルーチンの名前です。
 ディスク・スペースが少なくて済む別の方法は、XL Fortran ライブラリーを静的にリンクし、その他のシステム・ライブラリーの参照を動的リンクのまま残すことです。次の例では、XL Fortran ライブラリーだけを静的にリンクしています。

# Build a temporary object from the Fortran library:
ld -r -o libtmp.o -bnso -lxlf90
# Build the application with this object on the command line:
xlf95 -o appl appl1.o appl2.o libtmp.o

 ただし、ここで問題となるのは、例えばXL Fortran プログラムをXL Fortran メッセージ・カタログがないシステム上で実行した場合、実行時エラー・メッセージ (殆どは I/O 問題に関するもの) が正しく表示されず、プログラムはメッセージ番号を出しますが、それに関連したテキストは表示されない、という状況です。
 この状況を回避するには、 XL Fortran メッセージ・カタログを /usr/lpp/xlf/bin/default_msg から、実行システムで設定された NLSPATH 環境変数の一部となっているディレクトリーへコピーすればいいのです。
 リンク中の命名競合の回避についてはどうでしょう? 実行時サブ・プログラムと同じ名前を持つ外部サブルーチン、外部関数、共通ブロックを定義すると、その名前の定義がその場所で使用されたり、リンク・エディット・エラーが発生する場合があります。以下の一般的な解決方法を試行して、このような種類の名前の矛盾を回避するための参考にしてください。
 -qextname オプションを使用して、すべてのファイルをコンパイルできます。このオプションは、個々のグローバル・エンティティーの名前の最後に下線を追加して、この名前とシステム・ライブラリー内の名前とを区別します。ただ、このオプションを使用する場合は、 dtime_ および flush_ のようなサービス・サブプログラムおよびユーティリティー・サブプログラムの名前では、最後の下線を使用する必要はありません。
 これでプログラムを動的にリンクすることができます。これはデフォルトです。多数の命名の競合は、静的にリンクされたプログラムにのみ適用されます。
 コマンド行上でライブラリーやオブジェクト・ファイルの名前を、優先順位が高いものが最初に来るような順番にすることもできます。たとえば、libxlf90.a 内の名前がオブジェクト・ファイル内の重複している名前よりも高い優先順位を持つようにするには、コマンド行で -lxlf90 を最初に指定してください。
 -qextname オプションを使用しない場合は、 XL Fortran およびシステム・ライブラリー内の外部シンボルの名前との競合を回避するために、特別な予防措置をとる必要があります。ここでサブルーチンまたは関数を main と命名しないでください。XL Fortranが、プログラムの始動にエントリー・ポイント main を定義するからです。また、下線で始まるグローバル名を一切 使用しないでください。特に、XL Fortranライブラリーでは、_xlfで始まるすべての名前が予約されています。さらに、XL Fortran ライブラリー、または、いずれかのシステム・ライブラリー内の名前と同じ名前を使用しないでください。安全に使用できる名前を判別するために、プログラム内にリンクされているすべてのライブラリー上で nm コマンドを使用して、プログラム内にも存在する可能性のある名前を探すことができます。プログラムが、XLF 提供のあるルーチンを呼び出すと、使用できる共通ブロック名およびサブプログラム名に、いくつかの制約事項が適用されます。
 例えば、 XLF が提供する関数名 使用できない共通ブロック名またはサブプログラム名は、

  mclock times
  rand irand などです。

 ただし、このときプログラムに実際のルーチンを定義せず、サブルーチン名または関数名を使用することがないように、注意が必要です。
 その名前がいずれかのライブラリーの名前と競合すると、プログラムはルーチンの間違ったバージョンを使用して、コンパイル時エラーまたはリンク時エラーを作成しない場合があるからです。また、複数のライブラリー・ファイルやオブジェクト・ファイルに、ルーチンの別のバージョンがある場合は、使用したい特定のバージョンを使用するように注意が必要です。最初にコマンド行または構成ファイルに、正しいバージョンを持つファイルを指定してください。ファイルがライブラリーの場合は、最初にコマンド行に適切な -l オプションを指定してください。この手法は、同じ共用ライブラリー内のルーチン、または、ある共用ライブラリーから別の共用ライブラリーに明示的にインポートされたルーチン間の参照には適用されません。
 以上のような基本的な知識を踏まえておくと、私のような 「人間」 にも、つまり、コンピュータの神 (=Metal-T-H) のような存在でなくても、ウェブサイトによる広告作業を、より効率的に遂行できるのです。
/井原

「それは必要ですか?」
「無意味です」
「その話に “D” は反応しましたか?」
  /「コンピュータの神(=Metal-T-H)」 の口癖
スポンサーサイト
  1. 2007/11/09(金) 14:44:24|
  2. コンピュータの神
  3. | トラックバック:0
  4. | コメント:0
<<IP Address サイバー戦に備えた基礎知識と、コンピュータの神との対話 | ホーム | 大手検索エンジンの現状 サイバー戦に備えた基礎知識と、コンピュータの神との対話 >>

コメント

コメントの投稿

管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://by3h.blog111.fc2.com/tb.php/29-75e76a14
この記事にトラックバックする(FC2ブログユーザー)
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。