法本告之 NEWS from (')))>Japan WebCache Workshop 報告 インターネットの普及と Web の利用者の急な増加に ともない、 Web 上のデータを有効に再利用するキャッシュ 技術の重要生か認識されつつあります。 jus では 4 月 23 日に、キャッシュに関する去辭斤の研究成果の発表や現状報 告、新たな研究課題などについての言侖や青報交換を目的 としたワークショップを開催しました。 このワークショップは 13 負 ) 研究発表とバネル・ディ スカッションから構成され、約 100 名が参加してのこ もった言義がおこなわれました。 以ード、プログラムの頂を追って内容を報告します。 松本英夫 (IIJ) Chair : 鍋島公章 (NTT) ・比中如勺大堋莫なプロキシー・サーバーの運用 セッション 1 UNIX MAGAZINE 1999.9 ャッシュを続けるかどうかを含めて検詞する必要がある。 み台にした不正アクセスに利用される危険生を考慮し、キ 今後は、運用コストの増大や、キャッシュ・サーバーを踏 48 % を占める。 れるファイルは全体の 3 % しかないが、トラフィックでは URL は 1 回しかアクセスされす、 10 回以 . E アクセスさ ダイの景強く受けていることが分かる。本の 7 割の 発生しており、 ISP のキャッシュ・サーバーはテレホー トラフィックの半分は午後 10 時 ~ 午前 3 時の 5 時間に IIJ では Squid を利用している。糸をみると、 1 日の した運用を可能にするといった点か挙げられる。 ト率を向ー E させ帯域削減の保を上げる、低コストで安定 は、導入によって応答性が悪くならないようにする、ヒッ キャッシュ・サーバーが導入されている。言 t 方針として 多くの ISP で、応答性の改善や帯域削減を目的として ッシュ・サーバー運用列の報告。 大手 ISP (lnternet Service Provider) におけるキャ ・ firewall 内の proxy/cache server によるリレー 一一條博 ( ケンウッド ) 企業内ューサー向けにキャッシュ・サーバーを提供した ときの効果を知るために、擬イ勺な環境を用意して性能測 定をおこなった。 インターネット接続には研究開発部門の回線を使用し、 キャッシュ・サーバーは一ド段プロキシー (Squid) 、ファイ アウォール (delegate) 、外部プロキシー (Squid) という 構成である。ここに netperf による擬似トラフィックをケ え、 webstone を用いて掟した。その結果、おおむね 30 ~ 50 % 程度のヒット率か碍られること、 OS (FreeBSD を使用 ) のチューニングや Squid の設定によりさらに効 果が上がることなどが分かった。 質鼬芯答のなかで、「企業内ユーザー向けのキャッシュ・ サーバーが遅いと、自分の PC を会社の電話経由で ISP に接続し、それをさらに LAN につなぐようなことをする 人力咄てくる。こういった風朝がひろまらないようにする ためにも、性能を系財寺する必要がある」という、考えさせ 149 ・サーバー ( 準公開キャッシュ ) において、複雑なキャ サーバーだけがアクセスできるように設疋されたキャッシ 網か構築できる。組内利用者と求した外部キャッシュ・ 糸目系測で Squid を叫秀させると、より大きなキャッシュ 大釜弘 ( 徳島大学 ) ・準公開 Squid 相互接続一刻爰システムの運用 験カ始められつつあるといった話も紹介された。 アジア地区で、衛星マルチキャストによるキャッシュ実 parent 接続を中心に再構成することを検討中である。 こで、 sibling 接続をやめ、 WIDE 対タ材妾続 NOC への のヒット率が低いために応答時間が遅くなっている。そ なりの差がある。 HTTP のヒット率は約 40 % だが、 ICP キャッシュ容量は、サーバーによって 10 ~ 256GB とか 2 ホップまでの NOC と sibling 接続をおこなっている。 構成は、各 NOC にキャッシュ・サーバーを設置し、 で運用しているキャッシュ・サーバーについての報告。 W4C (WIDE WWW Cache) ワーキング・グループ 川本芳久 ( 大坂大学 ) ・ WIDE CacheBone の言気と運用報告 られる言劼ゞあった。

ッシュ設定を麪爰するシステムを実現した。キャッシュ・ サーバーの登録 / 状態情報をデータベース化し、それを用 いてシェル・スクリプトで Squid. conf を自動成する 仕組みになっている。管理者は、自喋言されたログの解 析と、それにもとづく接続先の再検言寸をおこなうだけでよ い。・麦の課題は、支援システムの効率化と、キャッシュ・ サーバーによる遅延の矢宿である。 ・バケットモニターによる代理サーバーの性能言れ則 中村豊 ( 奈良先立斗物支術大蝌完大学 ) キャッシュ・サーバーの運用にあたっては、サイトの 規模に適したシステム構成をみきわめなくてはならない。 従来はべンチマークやログ角斤を利用してきたが、キャッ シュ・サーバーの横にモニター計算機を置いて言れ則する方 法を用いた。運用中のキャッシュ・サーバーによぶんな負 荷を与えす、正確なコネクション継続時間が測定できる。 ーヨ勺な能の PC 上に実装したモニターを用いて自サイ トて漣用中のキャッシュ・サーバーを則した結果、瞬間 最大接続数 370 を言当泉した。 会場からは、ファームウェアとして実装すれば世界中で 喜はれるのではという意見も出た。 ・キャッシュ・サーバー性能による回線牆域の景 羽田久一 ( 奈良先端利オ支術大完大学 ) キャッシュ・サーバーと Web サーバーとのあいだの 帯域を変更できるネットワークを実剱勺に構築し、べンチ マーク・ソフトウェアを用いて同時クライアント数やキャ ッシュ・サーバーのソフトウェアを変えながら応答速度を 観察した。その結果、同日妾続クライアント数か増えると、 キャッシュにヒットしたにもかかわらす応答速度が遅くな る現象がみられ、帯域か狭いのにクライアント数か糧端に 多いとエラー率が . E 昇する、キャッシュ専用機は Squid に くらべて処理性能力材行違いに速い、といったことが分かっ た。帯域が狭い場合、キャッシュを増強しても大きな効果 は得られないと思われる。 ・月ⅥーⅥハキャッシュのノヾフォーマンスに関する因 果分析 内藤広志 ( 大阪工業大学 ) 学内で運用してきたいくつかのキャッシュ・サー (Squid を使用 ) のログを t 角斤し、因果モデルにもと づいて分析した。 150 分散キャッシュの性能に景グ礬をえる要因には、個々 の Squid の設定、イントラネットやインターネット孑売 の帯域などがある。一方、ログから得られる観測変量には、 ヒット率、応剞間、 TCP 要求数、エラー率などがある。 これらを分析した結果、質的アクセス量、潜在的ヒット率 ( 外部アクセスの遅さやアクセスドメインのひろがりなど を差し引いたヒット率 ) 、ミスの ) 芯寺 : 間 ( キャッシュに よる遅延を差し引いたミス発生時の ) 芯答時間 ) の 3 っカ咽 子となることか示された。イ乍業には膨大なログ角斤が必要 であり、 3 台の SPARCWS でまる 1 日を要した。 セッション 2 Chair : 知念賢一 ( 奈良先端科学オ支術大完大学 ) ・ Harvest 型分散型キャッシュシステムにおけるトラフィ ックの分析河合浦台 ( 奈良科物支術大凝完大学 ) キャッシュには Zipf の ~却リ (i 番目に人気のあるオプ ジェクトのアクセス回数は 1 / i 。に比例する ) が適用可能 なことカ喇明しつつある。人気のあるオプジェクトは少な いので、リクエストを多く集めるはどヒット率は上がる。 分散キャッシュはリモートのキャッシュか使えるため、見 かけ上のキャッシュが大きくなる面と、リモートのリクエ ストの利用を期待できるという 2 つの面から単独キャッ シュの限界を打ち破るものである。 RFC2186 ~ 2187 で 定義された ICP は、 UDP をベースとしているためプロ トコルのオーバーヘッドが小さいなどの特徴があるが、パ ケットが多数かっバースト的に発生し、リモートヒットの 効果カ坏明といった問題点もある。 そこで、インターネットとのあいだの境界ルータのパ ケット数と、インターネットからのトラフィックの分析に もとづき、 ICP の効果を十館正し、そのための必要条件を調 査した。境界ルータのバケット数の分析では、 sibling を 増やすと同しヒット率でもバケット数か増える、 sibling をいたすらに増やしてもバケットか増加するだけでヒット 率は向上しないことが分かった。 sibling までのトラフィ ック (ICP と HTTP) の言則や、 sibling の利用の有無 によるヒット率の上交などもおこなった。 ICP で効果を上げるのは難しく、ヒット率で 3 ~ 4 % 以 上増加しなけ川よ効果があるとはいえない、この値をもと に有効性をみきわめたうえで使うべきであるというのが結 論である。指定するサーバーは、せいぜい 3 ~ 4 ホッフ先 までのものに限定したはうがよいであろう。 UNIX MAGAZINE 1999.9

者については、過去の履歴をベースにすれば制御できる、 後者については、 HTTP であれば・可能だが、 FTP のよ うに往復の経路か違うと面倒である、という回答だった。 ・主記憶を用いた分散 WWW キャッシンクフ。ロキシー 西川記史 ( 日立製作所 ) 現在のキャッシュの間題は、高負 : 荷工竟でポトルネック になる点とヒット率ががらない点にある。ポトルネック になる一因は、ディスク I / 0 か遅いからである。あるキャ ッシュ・サーバーのディスク I / O を角財斤したところ、大き なデータを除くと IURL 勺 3KB で 100 回 / 秒の入出 力が発生していた。そこで、高負荷工竟においてはディス クでのキャッシュは限界であると考え、 Web キャッシュ に己慮を用いることを提案した。 Web トラフィックを角財斤した結果、 90 % 以のページ は 1 日 1 回以下のアクセスであった。そこで、高アクセ ス頻度のページのみをキャッシュすることにし、アナライ サによってログを分析し、キャッシュする URL をプロキ シー・サーバーに孑ヾするシステム構成をとった。大規模 ネットワークでの利用を想定して階層型構成にし、 10 日ぶ んのアクセスログを用いてシミュレーションを実施した。 プラウサでは 8MB のキャッシュを仮定し、プロキシー サーバーには Web キャッシュ用として主記應 64MB を 石何呆した。そのうえで、アクセス頻度にもとづくコンテン ツ邇尺をおこなうキャッシュ、単純なラウンドロピンによ るキャッシュ・システムを上交対象とした。 その結果、階層が - ド ( ューザー端末寄り ) のキャッシュ では 3 % 、上のキャッシュでは 6 % 程度のヒット率改善 がみられた。本でもヒット率は 1.2 イ部呈度改善されてお り、利用価値はある。 パネル言「キャッシュ技術、今そして未来」 コーディネータ : 鍋島公章 (NTT) ノヾネラー 石川智之 (TeaCup Communication) 秋山ゆかり ( プライスウォーターハウスコンサルタント ) 牧野二郵 ( インターネット弁護士 1 義幻 ・キャッシュ技術の動向 鍋島公章 はしめに、今回のワークショップを企回されオゴ咼島氏か ら、キャッシュ技術の動旬について説明があった。 152 キャッシュ・サーバーの性能で注目されるのはヒット率 だが、新たなプロトコルの開発によってもうすこし上がる であろう。キャッシュ・サーバーに蓄積されるデータは、 大では HTML ファイルなどのテキスト情幸ゞ大半を占 めるが、今後は映像などのストリームが中心になっていく だろう。そうなった場合、たとえは約 IMbps の或を消 費する VHS レベルの画置央像をキャッシュできるサー バーが必要になる。キャッシュやミラーなど、最適な情報 配置とそのナビゲーション技術はさかんに研究されている が、まだまた改善のせ也がある。 キャッシュに関連し、ヨーロッパでは情報の複製と著 イ雀カ墹題となっている、日本ではまた判例はないか注意 が必要である。また、山も丘はキャッシュされないコンテン ツも多くなっている。 ・掲カ反サービスにおけるプロキシー・サーバーへの期待 石川智之 TeaCup Communication(http://www.tcup.com/ は石川氏カ咽人て始めた掲カ反サービスで、現在はサーバ (Linux を使用 ) が 8 台、掲万財反の数が 15 万、 1 日の アクセス数が 250 万ページの規模に成長した。 掲カ反サービスは一殳に CGI を使っており、アクセス するたびに HTML ファイルの内容が変わる。したがっ て、キャッシュ・サーバー管理者からみるとキャッシュ の効果が下がるのカ貘俺点である。一方、掲カ反サーピス利 用者にとってのキャッシュ・サーバーは、アクセスのプロ キシー・サーバーとしての側面か重視されており、アクセ ス元を隠すための道具という認識か強いようだ。利用する 理由としては、匿名ならではの自由な情報交換、自己のプ ライバシー防衛、いたすら / 犯罪の 3 つが多い。 匿名性の需要は確実にあり、プロキシー・サーバーを経 由した迷惑行為に対して発信者を特定できるイ督はみは必要 だが、大ではまた整備されていない。 TeaCup では、発 信元 IP アドレスによりアクセスを拒否する機能を用意し、 掲カ財反管理者が 3 つのモードから選べるようにしている。 プロキシー・サーバー管理者に対しては、代理アクセス であってもアクセス元としての責任を感してはしい、ログ をタイムリーに提供できる体制を整えてほしいといった要 望があった。ログの保存期間については、間題が起きても、 すぐにプロキシー・サーバー管理者に叫各がいくわけでは ないので、 2 週間程度は保存しておくのか望ましい。 UNIX MAGAZINE 1999.9

キャッシュ・サーバー管理とプライバシーの「に関し ・インターネット・マーケティングから観た Web キャッ シュの ~ 来 秋山ゆかり ては、とくにログの扱いが重要である。キャッシュ・サー バーの管理者は、ログの内容について守秘義務がある。ロ インターネットをマーケティング・ツールとしてみた グの保管義務に関してはまた滸磊義がおこなわれている段階 とき、おもな利用形態は広告である。インターネットを使 だが、それよりもログに対するクラッキングに注意を払う う利点は、対象を絞り込んだマーケティングが可能になる べきであろう。管理者は、技術だけでなくモラルの面でも ことにある。 Web ページ上にノサーを配置する形態がよ 高い水準カ腰求される。 く知られているが、ほかにもメールやブッシュ技術を使っ 質題芯答では、たいへん活発な奇義カ咬わさ予定さ たものがあり、標純勺な料金体系も決まっている。 れていた終了時刻を 1 時間半もするほどだった。 キャッシュ・サーバーでは広告もキャッシュするため、 Web サーバーにおけるバナー広告へのアクセス数も減っ ☆ てしまう。夫第のアクセス数と Web サーバーでのアクセ 数 0 比は、、勺で 100 = 00 、著名なサイトでは、 00 = 0.15 Web アクセスに対するユーサーからの要求は厳しく、 さまざまな立場でキャッシュ技術に携わる方たちは、そ にもなる。しかし、キャッシュ・サーバーでのアクセス れに応えるべく積極的な姿勢で間題に取り組んでいるよう 数は Web サーバーの管理者には伝わらないため、広告主 です。今回のワークショップでは、その面で有意義な清報 は効果を測れす、マーケティングではキャッシュ・サー をお届けできたのではないかと思います。 ーは、邪魔者 " 扱いであった。だが、キャッシュされた ノヾ 最後になりましたが、会場を提供していだいた住商工レ ノサー広告もユーサーに見られているので、広告の効果は クトロニクス株式会社にお礼を申しあげます。 あるはずである。そこで、去も匠はキャッシュ・サーバーの つ勉強会のお知らせ 存在を前提とした料本系を組むなど、新たな広告評価基 準か作られつつある。 Web の、、ネ期思率 " を調査する会社も テーマ . もう IMAP から離れられない 出てきており、キャッシュ・サーバーとマーケティングに 講師 : 渡部直明 ( オレンジソフト ) 関する問題は鮹夬の方向に向かっている。 日時 : 8 月 25 日 ( 水 ) 18 : 30 ~ 20 : 30 今後は / サー広告の割合は下がるが、それでもインター 会場 : 丸正ホール・大会議室 ネットを利用したピジネスモテルは広告モデルが羽充にな 東京者辟万宿区四谷 3 ー 12 メい E ピル 6F ると予測される。かなり以前からあるキャッシュ・サー 地下鉄丸ノ内線四谷三丁目駅下陣徒歩 2 分 ーをいまさらなくすことはできないので、マーケティン 定員 : 80 名 ( 事前申込み定員 : 70 名 ) グとの共存関係を作る必要がある。 事前申込み方法 : Subject 行に help とだけ記したメール ・キャッシュの法的考察訌朝侖 を reserve@jus ・ or ・ jp 宛にお送りください。折り返し、 申込みガ去の田を自動」いたします。なお、事前申 現在、言儒義されているのは、キャッシュデータは著作者 の許可を得て置いているわけではなく、著イ料福の観点 込みクメ帝切は 1999 年 8 月 23 日 ( 必着 ) です。 内容 . 自身の運用経験にもとづいて、事例を挙げながら からみると避去ではないかという問題である。キャッシュ IMAP4 の機能、サーバーやクライアントについて説明 データ窈却勺な未付けか羽埆寉になっていないため、侖 します。すこしでも多くの方に、メールサーバーも進化 カ咄るまでにはまた相当な時間がかかるであろう。著作者 すべき時期にさしかかっていることを実感していただけ のイ頁を石呆し、ユーザーの利便性を損なわないようにす ればと思います。 ることか基本である。 対象 : 企業や大学などのメールサーバーの運用担当者、 もう 1 つの問題は、日本では閲覧が許されないような IMAP4 についての知識を得たい方。 情報 ( 猥褻情報や軍事情報など ) もユーサーがアクセスす れはキャッシュされてしまうという点にある。これにつ いては、翫意にその種のデータを保存しようとしないかぎ り、責任を問うことはできないと思われる。 ノヾ 153 UNIX MAGAZINE 1999.9

少ないキャッシュ容量てデータを有俐用するために 会場からの「マルチキャストで HTCP を使った場合 データ置換えアルゴリズムを改良した。置換えアルゴリズ はどうか」という質問に対しては、マルチキャストでも復 ムに LRU (Least Recently Used) を適用し、丿ひ大学 路のバケット数は同しであるとの回答だった。 の Squid ( キャッシュ容量 20GB) のログを用いて、現 ・ WWW 代理サーバーのアクセスログからのページ単位 状のヒット率と LRU 適用後のヒット率のシミュレーショ 普天間智 ( 大阪府立大学 ) の角財斤手法の提案 ンをおこなった。分析の結果、キャッシュ容量 500MB WWW 上の同一ページに含まれるオプジェクトへのア ぐらいで Squid と同しヒット率カ材等られるが、利用率は クセス傾向を調査し、ユーサーの視点から WWW システ Squid 方式と上交して大差なく改善はみられなかった。ヒ ムを改善する手法を探った。 ット率以外の評価は、実装しないと実施できない。 ューザーの挙動を十ヾるために、代理サーバーのアクセ 会場からは、「完全な LRU の実装は大変なので、 Squid スログの角財斤にもとづき、ページ単位のアクセス傾向を分 の hashbucket を大きくするガ去をとったらどうか」と 析した。 HTML ファイル名をユニークな ID としてペー いう質問に対しては、「 hash bucket を小さくしているの ジを切り出し、 HTML ファイルを角財斤して埋め込まれて は芯間を考慮しているためであり、そのガ去は考えて いるオプジェクトを判定している。ページ単位で中幻する いない」との回答だった。今後の課題として、 LRU 以外 ように HTTP を改善すれは冲幻効率が上がる、プラウザ のアルゴリズムも検討したいとのことであった。 でページを表示する際にレイアウトを再計算できるように したほうがよいのではないか。 ・ Web におけるアプリケーション・ルーティング技術の ・投機的キャッシュ法における複数サーバー秀方式の 渺皀正浩 ( 東北インターネット・義会 ) 甫豊徳 (NTT) ネットワーク層によるトラフィック分散は運用コスト ルータの処理能力か 1 矼ヒし、バックポーン回線には余裕 が大きくなるわりに肋攤しく、アプリケーション層に が生じた一方、アクセス回線がポトルネックになってい よって缶卩したほうがよいのではないか。マルチホームの る。そこで、あらかじめキャッシュすべきコンテンツを 経路制御は難しいので、外部情報 ( 経路情報など ) と中継 決め、それを単位日判爿ごとに更新する、投機的キャッシュ 技術 ( プロキシーなど ) を組み合わせて最適な経路選択が 法 " を考案した。 できるようにすることが目的である。 具イ勺には、数日前のアクセス頻度データを用いてキャ 既存の竟 , 、、の景を最小限にするために、、、首振りサ ッシュするコンテンツを決めて実施した。対象外のデータ " を使用する。これはクライアントからリクエスト はキャッシュせす、サーバー上でデータか更新された場合 を受け、外部清報を参考にしてどちらのプロキシー・サー はキャッシュ・サーバーに通知がくることか則提である。 ーに医するかを決定する。この際、経路〕尺に使える 実験の結 1 日のデータ中幻量は 400MB 、その標準偏 外部情報は、プロキシー・サーバーから目的サーバーまで 差は 132MB となった。そして、普通のキャッシュ・サー の RTT 、過去の転却間、経路情報による距離、青勺ポ ーより高いヒット率カ等られること、使用したアクセス リシーである。 Squid 2.1P2 をベースに、 parent5# 尺を 履歴によってヒット率はかなり変わることが分かった。こ 重加勺におこなう部分を追加して実装する予定である。 の結果をもとに、キャッシュ構成ガ去を検詞すると効果が この手法には、ネットワーク層の間題に依存しない、過 あるのではないか。 去のログや RTT などの各種の情報を利用できるといった 会場からの「頻度データを 1 時間あるいは 1 週間単位 利点がある。一方、首振りサーバーのオーバーヘッドが気 でとったらどうか」という質問には「 1 日単位にするのが になるといった間題点もある。 もっとも結果がよかった」、「頻繁に変更されるようなコ ンテンツの場合はどのような結果になるか」という質問に 質題芯答では、「時間帯によって描商な経路が変わった は「今後の訝題としたい」との回答だった。 りする ( 昼休みだけ混んでいる経路など ) が、その場合は どう対処するのか」「 1 つのサーバーに複数のインターフェ ・ WWW キャッシュにおけるデータ置換えアルゴリズム イスを付けたほうが楽ではないか」という質問カ咄た。前 昜雄一・一、 ( 馗日大学 ) の研究 1 一口 ーノヾ ノヾ 151 UNIX MAGAZINE 1999.9

JAPAN COMPUTERCORP. をを = を = を一を いたします。 消失の心配もありません。 ル端末機能 マル 使用目的に応じた端末環境を 1 台で提供いた します。 ・ Java 端末として・・・ Java ヘースで開発された アプリケーションを実行 ・ X ウインドウ端末として・・・ X ウインドウシステム の X サーバー機能を実行 ・ブラウサ端末として・・・ HTML3.2 べースの高 性能プラウサ搭載 ・電子メール端末として・・・画像ファイルも音声 ファイルも添付可能なマルチメディアメール 機能 JCC UItraSPARC べース ワークステーションシリーズ ・お客様のニーズにあわせたフレキシプルな仕様でご提供 ・アップグレーダブルな製品設計・ Solaris & Linux のテュアル OS ・タワー & ラックマウントモデル JU5 シリース JU5, / 360 ( ・ UltraSPARC- Ⅲ 360MHz ・外部キャッシュ 256KB J い / 270 ・ UltraSPARC- Ⅲ 270MHz ・外部キャッシュ 256KB JUIO シリース J い 0 / 440 」 ・ UltraSPARC- Ⅲ 440MHz ・外部キャッシュ 2MB JUIO 〃 / 3 〃 60 ・ UltraSPARC- Ⅲ 300 / 333 / 360M Hz ・外部キャッシュ 512KB / 2MB JU60 シリース ー JU60, / お 60 〃 4 側〃 450 の ・ UltraSPARC- Ⅱ 360 / 400 / 450MHz ・外部キャッシュ 2MB / 4MB JU60 / 2360 / 24 側 / 2450 ( 」 ・ UltraSPARC- Ⅱ 360 / 400 / 450MHzX2 ・外部キャッシュ 2MB / 4MB を物多を 0 多を常 0 0 0 0 尊をを第嗜 第第 0 を顰第第辭 番第第電当当 0 ををを .. い霧を 0 0 を響新 、物 0 0 簽物 0 蘚 0 0 豊を要 0 物傘物 朝 0 物 0 を第を・ , 物 0 0 0 朝朝 を阜を曾第を要を告・ 磐 0 驂を 0 参に第 0 ををに多嚼甞朝 0 宿霧 0 0 0 0 を 0 参第 0 0 傘の傘 JCC ワークグループサーバ 2 シリース ・ UltraSPARC-II 300 / 360 / 400MHz ( 最大 2CPU) 高い信頼性と優れた価格性能比が、データベース、 グループウェア、 web サービスなどのサーバとして各々 のフィールドで最適な能力を発揮いたします。 コスト・スペースを大幅にスリム化 ! JVS シリーズ導入により、キーポード / モニタ 1 組で最大 8 台のワークステーションをコントロール。 コスト・スペースを大幅にスリム化します。 ・、上、←今膨 ? ロロロ ロ三 シリース JVS シリーズ導入後 東京・大阪・福岡・パロアルト ( シリコンバレー ) ・ニューヨーク 本社 / 〒 101 -0031 東京都千代田区東神田 2-6-9TEL.03-3864-8111 ( 大代 ) 本社営業部 / 03 ー 3864 ー 551 1 関西営業所 / 〒 550-0014 大阪府大阪市西区北堀江 1 -20-15 佐野ビル 4F 関西営業所 / 06 ー 6539 ー 8441 福岡営業所 / 〒 8 12-0011 福岡県福岡市博多区博多駅前 4 - 1 - 福岡営業所 / 092 ー 41 2 ー 5521 資料請求 No. 003 Java 端末として X ウインドウ端末として JVS シリーズ導入前 キーボード / ビデオ・スイッチ第 電子メール端末として 日電機式会社 URL http://www.jcc.co.jp/

ewS ハイエンド UNIX サー 富士通 (TeI 03 ー 3216 ー 0429 ) は、独自 CPU 使用のハイエンド UNIX サー ノ、 ◆ GP7000F モデル 2000 のおもな仕様 CPU 、 I/O バス (PCI) 、メモリで構成さ ( 300MHz 8 ~ 64 (SMP 構成 ) 。 4 つの CPU は、 1 ノードあたり SPARC64GP ーー 0 「 GP7000F モデル 2000 」の販売を開始 ■富士通 システ れるシステムボードを複数使用。 ション / 分。最大 16 ノード ( 1 , 024CPU ) CPU 時の処理性能は 150 , 000 トランサク 域幅は最大 51.2GB / s (128CPU 時 ) 。 64 MHz) で、レイテンシは 300nS 以下、帯 配線 CMOS のクロスパー・スイッチ ( 200 ムバス ( ポード内 / ポード間は 0.18 m 銅 CPU ( クロック ) 1 次キャッシュ * 2 次キャッシュ * CPU 数 主記憶 HD ( 内蔵 ) HD ( システム最大 ) I/O スロット 冗長 / 活性交換 (DR) 機構 外形寸法 (HxWxD) * ICPU あたリ GP7000F モデル 2000 SPARC64 GP (300MHz) 64KB ( 命令 ) 、 64KB ( データ ) 8MB 8 ~ 64 4 ~ 64GB 18.2GB ~ ITB 700TB PCI ( 66 / 33MHz ) X12 ~ 96 ディスク、電源、ファン、システム監視機構 180X104.4X130Cm (32CPU まで ) 180X217.2X130Cm (64CPU まで ) ・日立 PA ー 8500 使用のハイエンド・サー / ← 日立製作所 (TeI 03 ー 5471 ー 2637 ) は、 PA -8500 (440MHz) 使用の「日立クリ 工イテイプサーバ 3500 / E540PS 」「同 ◆日立クリエイテイプサーバのおもな仕様 3500 / E540PS 3500 / E540RM 」「 HITACHI 9000V シ リーズ・サーノヾ VT850 」の販売を開始 ・ 9 / 1999 0 000 ー ◆日立クリエイテイプサーバ 3500 / E540 以上の構成は 2000 年夏以降に対応。 売目標は今後 2 年間で 100 台。 128CPIJ 価格は 1 億 2 , 000 万円 ( 8CPU ) から。販 ューティング機能を強化 ) 。 OS は Solaris 7 ( 独自にトラブル・シ 99.999 % 。 スク / 電源 / ファンは二重化。可用性は 次キャッシュ / システムバスは ECC 、ディ る CPU の混在が可能。 1 次キャッシュ / 2 システム監視機構をもつ。周波数の異な configuration) 機能 ( 2000 年夏に対応 ) 、 パーティション機能、 DR (Dynamic Re- ノードを複数の OS 環境に分割する までのクラスタリングが可能。 続。いすれもラックマウント用で、 E540 GB/s のクロスパー・スイッチにより接 GBO プロセッサとメモリ間は最大 7.5 MHz)X2—4 、主記憶は 512MB ~ 3.75 いすれも、 CPU は PA ー 8500 ( 440 PS 、同 3500 / E540RM した。 3500 / E540RM ◆ HITACHI 9000V VT850 のおもな仕様 CPU ( クロック ) CPU 数 SPECint-rate95 SPECfp-rate95 主記憶 最大 HD LAN 回線数 WAN 回線数 I / O 拡張スロット PA -8500 (440MHz) 2 または『 2 または 4 1 , 120 、ネ 1 , 300 ー 512MB ~ 3.75GB * 240 6 , 423.4GB * 5 ~ 17 * 10 512MB ~ 3.75GB 5 , 258.6GB 242 6 ~ 18 145X60X86Cm AC200V*** CPU ( クロック ) CPU 数 事 ICPU あたり 重量 外形寸法 (HxWxD) I/F ( 最大 ) 最大 HD 主記憶 2 次キャッシュ 外形寸法 (HxWxD) 189.5X60X86Cm UNIX MAGAZINE 1999.9 ネ 1 ノードあたり 電源仕様 AC200V ー 4CPU 時車オプションで AC 1 開 V VT850 PA ー 8500 (440MHz) 2 ~ 16 64MB ネ 512MB ~ 64GB 318TB HP-PB X448 、 HP-HSC X62 PCIx56 162X90.5x75cm 440kg 1

needs lth IAI alwa Cyber R の Ent 2 マルチホスト、最大キャッシュメモリー 256MB SNX -56000E -130 ( 13GB) SNX -76000E -450 (45GB) SNX -56000E -180 (18GB) SNX -76000E -550 (55GB) SNX -56000E -270 (27GB) SNX -76000E -720 (72GB) SNX -56000E -360 (36GB) SNX -76000E -900 (90GB) SNX -76000E -1080 ( 108GB ) SERIES SNX -96000E -2520 ( 252GB ) SNX -96000E -2880 ( 288GB ) SNX -96000E -3200 ( 324GB ) SNII SEF'ES 0 ′をを・ル コントローラー機能 ・電圧、温度監視機能 •Event Log 、 Tag Queing 機能 ーティスクドライブサポート Standard(112 台 ) 、 Entry()2 台 ) ・エラー訂正 ( ECC ) 工ラー検出 ( Pa 頑 y ) Sync Mode/Rate 設定メニュー ( VT100 ターミナルモード、 LCD) ・メモリースロット (Standard 4 、 Entry/DuaI 2 ) ・ライトスルー / ライトバックキャッシュ ■バッテリーバックアップ ーホットスワップ 対応ホストマシン SUN ULTRA ・ SGI• RS6000 ・ HP9000 ・ NEWS ・ DEC Alpha ・ Windows NT ・ PC UNIX 他 SNK SERIES Å気贏 SNX -76000E -1080 SNX -56000E -360 Cyber R の Standard 4 マルチホスト、 最大キャッシュメモリー 512MB SNX -76000-1800 ( 180GB ) SNX -76000-2160 ( 216GB) SNX -96000-2520 ( 252GB ) SNX -96000-2880 ( 288GB ) SNX -96000-3200 ( 324GB ) CYBER SUPPORT 全国オンサイト保守体制完備 SNX -96000-3200 A007N MEMORY 8mm カートリッジテープサプシステム X ・ 8510EXS ド TX ・ 891 OXS ( 標準 7GB ・圧縮 14GB ) ( 標準 20GB ・圧縮 40GB ) テープ残量・エラーレート表示付 SUN S PARC 4 5 、 SPARC20 、 ULTRAI / 2 / 5 / 1 0 / 30 / 60 Enterprise150 / 450 / 3000 / 5000 / 6000 IPX/ELC 、 SPARC Center 、 etc. 100 % 完全互換 SGI 高信頼性永久保証メモリー lndy,lndig02 、 ONYX 、 02 、 OCTAN E 、 Challenge 、 etc. “低価格、即納 ' でお届け致します ! DEC AIpha Station 200 、 Alpha Station 500 AIpha Station 600 、 AIpha Server 800-2100 AIpha 3000 300-900 etc. 旧 M (RS6000) 320H -390 、 520H -990 、 3AT 、 3BT 、 3CT 、 40P 、 43P 、 41 / 42 、 T/G/W 、 591 , 595 、 etc. HP HP9000 700 シリーズ、 HP BCDKJ Class Server 、 etc. * 製品等の固有名詞は各社商標または登録商標です。 STX ・ 851 OEX STX ・ 8910XS 1 / 2 カートリッジテープサプシステム ( DLT ) S ・ 4000XS ー STX ・ 7000XS ( 標準 35GB ・圧 70G8 ) ( 標準・圧縮 40GB ) テープ残量・エラーレート表示付 STX-4000XS STX ・ 7000XS WEB ・ http : /lwww.iai•usa. 00 p 技術 :TEL 03-3350-5281 FAX 03-3350-5285 資料請求 No. 017

NEWS PS はクラスタスイッチ付きの統合クラス タモデル。 OS は HI—UX/WE20 価格は、日立クリエイテイプサーバ 3500 / E540PS が 3 , 275 万円 (2CPU 、主 記憶 512MB 、 HD 8.5GB 、 DAT 、クラ スタスイッチ、ラックマウント・キャピ ネット ) から、同 E540RM が 2 , 145 万円 ( E540 PS からクラスタスイッチを除いた 構成 ) から。 ◆ HITACHI 9000V シリーズ・サーハ VT850 CPU は PA ー 8500 (440MHz) x2 ~ 16 、 2 次キャッシュは ICPU あたり 64MB 、 主記憶は 512MB ~ 64GB 。システムバス は最大 26.8GB / s のクロスパー・スイツ チ。電源、ファンは二重化、オンライン 交換が可能。基本筐体と拡張筐体から構 成 ( 1 筐体によるコンパクト構成も可能 ) 。 OS は HP—UX 11.0 。 価格は 3 , 753 万円 (4CPU 、主記憶 1 GB 、 HD 9GB 、 DAT 、 DVD—ROM 、コ •Sun Enterprise X500 に 400MHz モ元レ サン・マイクロシステムズ (Tel 03 ー 5717 ー 5033 ) は、ミッドレンジ・サー 「 Sun Enterprise 3500 」「同 4500 」「同 5500 」「同 6500 」に 400MHz モデルを追 加し、販売を開始した。 CPU モジュールは、 CPU が Ultra SPARC—II ( 400MHz ) 、 2 次キャッシ ュが 8MB0 処理性能は、 17.7SPECint 95 、 158SPECint-rate95 、 30.1SPECfp 95 、 267SPECfp-rate95 ( いすれも 1 CPU 、システムボード 100MHz 時 ) 。 So- laris 7 との組合ぜで動的再構築機能と代 •NEC R 12000 使用の UP4800 HITACHI 9000V シリーズ・サーバ VT850 ンソール、 HP—UX 2 ューサー使用権 ) から。 替パス機能の使用が可能。 CPU モジュールの価格は 379 万 5 , 000 円。基本バッケージの価格は、 Sun En- terprise 3500 が 964 万円 (CPU モジュー ル x 2 、 CPU/ メモリポード、 PCM) 、 4500 が 635 万円 (PCM x 2 ) 、 5500 が 850 万円 (PCM x2 ) 、 6500 が 2 , 940 万円 (PCM x 2 ) 。いすれも 32 倍速 CD-ROM ドライ プ、 SoIaris サーバー・ライセンスが付属。 性を高める UP4800 シリーズ用のソフト ウェア「 ATF 」 (AppIication Transpar- ent Failover) の販売も開始した。価格は 300 , 000 円から。 日本電気 (Tel 03 ー 3456 ー 1246 ) は、 UNIX サーバー「 UP4800 / 860 」「同 860 R 」の販売を開始した。 いすれも、 CPU は R12000 (300MHz) >< 1 ~ 4 。主記憶は 128MB—8GB0 内蔵 HD (Ultra Wide SCSI) は、 9 ~ 99GB ( 外 付け最大 6.8TB ) 。 860 は床置き型、 860 R はラックマウント型。 OS は UX / 4800 、 UX / 4800 ( 64 ) 。 価格は、 UP4800 / 860 が 450 万円、同 860R が 477 万円。出荷は 8 月 31 日。 ディスクアレイ ( RAID5 ) 入出力の信頼 ◆ UP4800 / 860 、同 860R のおもな仕様 CPU ( クロック ) CPU 数 主記憶 内蔵 HD 最大 HD 拡張スロット 最大回線数 UP4800 / 860 UP4800 / 860R R12000 (300MHz) 1 ~ 4 128MB—8GB 9 ~ 99GB 6.8TB PCIx8—32 144 外形寸法 (HxWxD) 67X44.5x68cm 重量 ( 最大 ) 80kg * 高さ 220Cm のラックとの交換も可能 ■ XFree86 Project XFree86 4.0 プレリリース版 XFree86 Project (http ・〃 www.xfree 86.org/) は、 XFree86 4.0 の最初のスナッ プショット ( 版 ) 「 XFree86 3.9.15 」を 公開した。 2 4.0 でのおもな変更点は、 DDX (De- vice—l)ependent c omponent of the X server) 構造の再設計。 Metro Lin k が開 発したローダにより、ドライバや拡張機 180X80X90Cm * 250kg 能、フォント・ラスタライサなどを動的に 組み込むことができる。ロータ機能は OS とは独立に実装され、 API/ABI は今後、 公開される予定。 また、新たに TrueType フォント、 CID フォントをサポート。 TrueType フォン トの表示には、バックエンドとして Free Type と X—TT を用いる。 CID フォント UNIX MAGAZINE 1999.9

・ Gecko 図 1 Gecko のレイアウト・エンジン成 ネットワーク入出力 ☆ . html ☆ . xml ☆ . CSS キャッシュ netli b 解析工ンジン DOM 処理器 解析 ツリー タグ 文法処理器 JavaScript イベント スタイルエンシン モテル ヒュー スタイルフレーム 決定 生成 スタイルシート レイアウトエンジン ジオメトリ リフロー システム レンダリング、エンジン グラフィック ビュー らみていこう。レイアウトとは、ドキュメントのコンテン することができる。 ッモデルに従って文章や画像を行 ( もしくはフレーム ) に Gecko 工ンジンの中枢部は、図 1 に示した主要サプシ 流し込み、各ページが埋め尽くされるまで行を積み重ねて ステムから構成される。ネットワーク入出力、角斤工ンジ いく反復プロセスである ( 文章を行に流し込んで行か積み ン、 DOM 処理器、スタイル、レイアウト、レンダリン 重ねられる順序は、ドキュメントの記述言語によって異 グの各工ンジンの 6 つである。ほかのサプシステム用のコ なる ) 。このプロセスは、ドキュメント本がそれぞれの ンテンツを生成するものもあれば、コンテンツの情報を読 ページにいき渡るまで続く。 み込むだけのサプシステム、その両方をおこなうものもあ Gecko 工ンジンは、このプロセスができるかぎりイン る。たとえば、角眷斤工ンジンはネットワーク用ライプラリ クリメンタルにおこなわれるように言されている。イン (netlib) カイ乍成したドキュメントを読み込み、専用の角 i クリメンタル・ダウンロード / リフロー / レンダリングは、 ツリーを作る。以降では、各サプシステムか処理するプロ プラウサやユーサーインターフェイス・マネージャー、ド セスを簡単に説明しよう。 キュメント・エデイタなどの高性能アプリケーションには その前に、前提条件を決めておこう。 Gecko は古典的 不可欠のものである。生能の面からいえは、リフロー なプラウサ・アプリケーションに組み込まューザー の回数はできるだけ少ないほうがよい ( リフローするデー が http://www.webtechniques.com/という URL を タも少ないはどよい ) 。なせなら、コンピュータにとって 開いたものとする。レイアウト・プロセスは、ドキュメン リフローはかなり負荷のかかる操作だからである。インク トか処理 - 可能となった時点て始まる。 こで、、、ドキュメ リメンタルにおこなうようにすると、ドキュメント本で ント " という用語は文章て構成されるものだけでなく、あ はなくその一部を任意のサイズでリフロー / レンダリング らゆる不頁のデータモデルを指すものとする。たとえは、 174 UNIX MAGAZINE 1999.9