Wikipediaといえば世界で第5位の訪問者数を誇る巨大サイトですが、システム運営に携わる人間は世界でわずか6人、しかもこれはボランティア込みという恐るべき少人数で、第4位のFacebookのサーバ数が3万台を超えているのに対して、Wikipediaはわずか350台で運用している……などというような感じで、知られざる今のWikipediaの実態が「KOF2010」にて本日行われた講演「Wikipedia / MediaWiki におけるシステム運用」で明かされました。 登壇したのはWikipediaを運営するWikimedia財団のエンジニアであるRyan Lane氏で、100席ある座席は満席になり、隣の中継の部屋まで人があふれているほどの盛況っぷりで、語られる内容もなかなか参考になることが多く、今後のGIGAZINEサーバにも活かせそうな内容でした。 というわけで、「Wikipedia
Google の Page Speed の Apache module 版 mod_pagespeed をインストールして、ちょっとだけ動きを見てみた。 インストールは Ubuntu に deb パッケージで。 $ wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_amd64.deb # sudo dpkg -i mod-pagespeed-beta_current_amd64.debconfig はデフォルトで入るものそのまま。 <IfModule pagespeed_module> SetOutputFilter MOD_PAGESPEED_OUTPUT_FILTER ModPagespeed on ModPagespeedUrlPrefix "http://localhost/mod_p
10/31の東京てら子で、発表してきました。 資料公開すると約束してたので、公開します。 本当はパワポをそのまま上げようと思っていたんですが、資料は2部構成でみんな興味があるのは後半っぽかったので、後半を抜き出した上で、色々スペルミスとか口頭で説明した内容を追加して、Blog記事として載せることにしました。 文章はパワーポイントからのコピペと、画像と入り混じってますがご容赦を twitter関連のFlashコンテンツを作る機会が増えてますが、CGI作る手間もかかるし、ユーザーが離脱する可能性が出てくるので、できればOAuthしたくないところです。 でも、twitterからアイコンを取得するのって 意外と面倒なんですよね。 ・API制限が・・・ 1時間に50回くらい? 同一IPからのアクセスで制限 search.twitter.comに限っては 150回くらい?らしい。 →後で重要になります
注意) レンダリングの高速化とは別レイヤーの話になります。 去年の記事でAPIレベルの考察はしていますが、今回はもう少し踏み込んで考えてみます。 get/setVector() vs get/setPixels() その前に BitmapData.getVector() と BitmapData.getPixels() のシグネチャを再掲。 両APIともピクセルデータを一次元のコンテナに詰め込むメソッドです。 getPixels(rect:Rectangle):ByteArray ピクセルデータの矩形領域からバイト配列を生成します。 getVector(rect:Rectangle):Vector.<uint> ピクセルデータの矩形領域からベクター配列を生成します。 速度を比較すると get/setVector() の方が高速です。 が、 重要なのはAPIの実行速度ではなく、 「取得したデ
InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が
ハードディスクの「拡張処理能力を有効にする」 http://d.hatena.ne.jp/ripjyr/20070521/1179731435 ハードディスクの「拡張処理能力を有効にする」 http://blogs.wankuma.com/shuujin/archive/2007/05/20/77424.aspx 2chの書き込み。 http://pc8.2ch.net/test/read.cgi/win/1115119803/ 「拡張処理能力を有効にする」は英語版では 「Enable advanced performance」という名前で それでぐぐってみたところ ttp://msfn.org/board/index.php?act=ST&f=34&t=67976 「拡張処理能力を有効にする」のチェックオフだと HDDは「ライトスルーキャッシュモード」というHDDの書き込み時
先日とある製品のパンフにあった構成が目にとまったので個人的にまとめ。 サーバの仮想化と分散型のストレージ/ファイルシステムやデータベースを組み合わせると、あり合わせの材料でスケーラブルな性能・容量に加えて冗長性を備えた環境が構築できます。 必要なのは複数の物理サーバ まず普通の物理サーバ(PSV)が3台あるとして構成してみましょう。 PSV1-3、それぞれにサーバ仮想化の仕組みを入れてVMを一つずつ入れます。 VMwareのESXiとかXenServerなど管理しやすいものがよいかと思います。 次にそれぞれのVMで、分散型のストレージソフト、ファイルシステム、データベースなんかを入れてみます。 ファイルシステムはhadoopだったり、データベースはCassandraとかは浸透してるけど、分散型ストレージソフトがそんなにないかな。 例えば複数のノードでiSCSIボリュームを作るLef
これは JS Benchmarks: Closing In < Rob Sayre's Mozilla Blog の抄訳です。この記事の肝は後半ですので、ベンチマーク結果だけ眺めて帰ることのないように! JS Benchmarks: Closing In この記事はいくつかのベンチマークのスコアについて取り上げ、それらが実際に何を測定しているかについて掘り下げます。 Firefox 4 の開発サイクルでは JägerMonkey の導入など JS エンジンの性能向上が著しいので、今こそベンチマーク結果を更新しておく良い機会です。ベンチマークは Windows 7 が動く Lenovo Thinkpad X201 で測定しました。以下は SunSpider ベンチマークで Firefox の成績の改善状況を示しています(数値が小さいほど良い)。 以上が現在のベンチマーク結果ですが、近い将来、
はじめに 2010 年 9 月 15 日を持ちまして、サイボウズ・ラボを退職いたしたました。 報告も兼ねて、久しぶりにブログを書いてみたいと思います。 (写真はゆうすけべーさんです) この会社に入って、たくさんの学びと思い出がありました。 その一つ一つをまとめていければ、素晴らしい記事になるのかもしれませんが、僕は文章が苦手です。 ですので、うまく退職のエントリを書き上げることができません。 言葉にできない。そんな感じです。 なので、このエントリはサイボウズ・ラボやサイボウズ本社の仲間たちへのありがとうの気持ちをこめて、自分らしく最後まで JavaScript のことを書きたいと思います。 サイボウズでの最後の仕事 僕にとって、サイボウズでの最後の仕事は「JavaScript で新しいユーザーインタフェースを作ること」でした。 そして、その中で始めて複数人による大規模な JavaScrip
kazuhoさんが「プロのサーバ管理者の間では存在価値が疑問視されて久しい (Min|Max)SpareServers だと思う」と書いたり、hirose31さんが去年のYAPC::Asiaで{Start,{Min,Max}Spare}Servers,MaxClientsは同じにしているよと発表したり、実際前職のサーバはそのように設定されていたのですが、自分でうまく説明ができてなかったので、調べながら書いてみた。 本当はイントラブログ用に書いていたものですが、がんばったので転載。 前提として、CPUの使用率におけるsystemとfork Re: クラウドがネットワークゲーム開発者にもたらしてくれたもの - blog.nomadscafe.jpでも書いている通りforkってのはサーバにとって重い部類の処理になります。つまり負荷の高いときにforkを大量に行うのはしてはならないことの1つです。
handlersocket plugin や mycached を使えば memcached は不要か、それとも使うべきケースがあるか。考察せよ [10点] kazuho (Kazuho Oku) http://twitter.com/kazuho/status/21477219149 考えて答えてみる。 HandlerSocketやmycachedを利用し、MySQLへの接続数が数万単位で行えるようになったり、より多くのクエリ数が発行できるようになっても、memcachedは不要ではないし、使うべきケースもあります。 memcachedは単なるKVSではなく、ExpiresとLRUがついたキャッシュサーバです。キャッシュオブジェクトには期限を付ける事ができ、期限が過ぎたキャッシュは無効にされ、またアクセスがされていない不要になったオブジェクトは削除され、空いたスペースは新しいキャッシュオ
はじめに はじめまして、グリー株式会社でエンジニアをしておりますkgwsと申します。今回は、グリー内で写真データの保存を行っている分散ストレージ(nanofs)を紹介させていただければと思います。 背景 弊社で運営させていただいている "GREE" ではユーザの写真や動画データを保存することができます。1億ユーザを目指すグリーは、ユーザの増加とともに写真や動画データは上限なしに増加していきます。またユーザの皆様の大切なデータを失うことは許されませんし、サービスを止めることも許されません。そんな状況の中、様々な技術や仕組みを使いサービスを運営してまいりました。 グリーのストレージの歴史は大きく分けて3世代がありました。 第一世代 第一世代ではアプリケーションサーバからNFSサーバをマウントし画像データを保存しておりました。簡単に導入できることと高価なサーバを使用すれば信頼性や安定性も保たれる
Twitterの大規模システム運用技術、あるいはクジラの腹の中(前編)~ログの科学的な分析と、Twitterの「ダークモード」 先週の6月22日から、米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」が開催されていました。 その中で、TwitterのJohn Adams氏がTwitterのシステム運用について説明するセッション「In the Belly of the Whale: Operations at Twitter」(クジラの腹の中:Twitterでの運用)が行われています。Twitterのような大規模かつリアルタイムなWebサイトの運用とはどういうものなのでしょうか? 公開されているセッションの内容を基に概要を記事で紹介しましょう。システム管理者の新たな役割、Railsの性能の評価、Bittorrentを使った
App Engineで使える言語は基本的にはPythonとJavaです。それでは、どちらを選ぶのが良いのでしょうか。 それ以外の言語の人向けの話は後から出てくるのでしばらくこのままお読みください。 趣味ならば単に好きなものを選ぶだけでいいのですが、仕事で使うためには、長所と短所をきちんと把握した上で選ぶ必要があります。また、ここでの話は言語としての一般的な話ではなくApp Engineで使うとき限定の話としてお読みください。 まず安定度ですが、インフラ部分の安定度は、どちらも基本的に同じです。もしかすると、まったく同じものを使っているのかもしれません。 その上で動くAPIの部分は、インフラと直接結びついている低レベルな部分と低レベルなAPIの上に構築された高レベルな部分とに分けて考える必要があります。 低レベルなAPIはLLAPIと呼ばれたりしますが、安定度は、PythonとJavaも同じ
コミュニティーリソース Flex cookbook* (コードの共有) CSS Advisor (ブラウザ別バグ修正) Exchanges* (コンポーネントの共有) Adobe Labs* ユーザフォーラム RSS フィード* Flex バグベース* ユーザグループの検索* ユーザグループについて* Adobe Community Experts (ACE)* デベロッパーイベント* ブログ MXNA* (ブログアグリゲータ) Adobe ブログ* 正直に言いましょう。AIRはランタイムが大きすぎ、貴重なメモリとCPUを浪費すると言われています。確かに多くのAIRアプリケーションがこの罠に陥っていますが、これは決して避けられないわけではありません。様々な技法を利用することで、ネイティブプログラムに遜色ないパフォーマンスを発揮する軽量のアプリケーションも開発できるのです。 CPU使用率を劇
いろいろな本からメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く