TwitterのステータスIDが53bitを越えたお話 - tmytのらくがき
僕の記事の間違いを指摘していただいているすばらしい記事です。僕の記事よりこちらの記事をご覧ください。 http://archive.guma.jp/2010/12/twitter-json.html 先日、29日の7時過ぎごろにTwitterのステータスIDが53bitを越えました。 こんな中途半端なビット数を超えただけでなぜこんな記事にするかというと、一部のクライアントで動作がおかしくなることがあるからです。 (14:14 追記しました) (14:31 もひとつ追記しました) TwitterのAPIはXMLとJSONの2種類で結果を取得できます。このうちXMLで処理してる場合は内部で64bit INTで処理していれば特に問題は起きません。 問題が起きるのはJSONの場合です。JSONはJavascriptでevalすればそのまま中身が取り出せることからもわかるように、Javascript
技術者視点で見る「クラウド」 ― ＠IT
2006年の後半から頻繁に聞かれるようになった「クラウド・コンピューティング」だが、マイクロソフトが“Windows Cloud”の構想を明らかにするに至り、ついに役者がそろったようだ。だが、そもそも「クラウド」とは何か？ 「インターネット上にグローバルに拡散したコンピューティングリソースを使って、ユーザーに情報サービスやアプリケーションサービスを提供するという、コンピュータ構成・利用に関するコンセプト」(情報マネジメント用語事典から) とのことだが、それがWeb（蜘蛛の巣のようにネットに分散するコンピュータ・サービスの結合コンセプト）や「グリッド・コンピューティング」と、どう違うのかは判然としない。「サーバを意識しない」や、「よりサービス指向」などのニュアンスは持つものの、単に手垢が付いていないマーケティングメッセージの新鮮さに各社が相乗りしているというのが実態だろう。 経営層に対するメ
Scaling Twitter: Making Twitter 10000 Percent Faster - High Scalability -
Update 6: Some interesting changes from Twitter's Evan Weaver: everything in RAM now, database is a backup; peaks at 300 tweets/second; every tweet followed by average 126 people; vector cache of tweet IDs; row cache; fragment cache; page cache; keep separate caches; GC makes Ruby optimization resistant so went with Scala; Thrift and HTTP are used internally; 100s internal requests for every exter
ココログベーシック／プラス／プロ メンテナンスのお知らせ: お知らせココログ:@nifty
ココログをご利用いただきありがとうございます。 ココログベーシック／プラス／プロにつきまして、データベースのリプレイスを目的としたメンテナンスを実施いたします。 詳しくは以下の通りです。 ======================================================== 詳細情報 ======================================================== ◇メンテナンス日時 2007年4月3日（火）15:00～4月4日（水）15:00の約24時間 ◇メンテナンス目的 データベースのリプレイス ◇ご利用いただけなくなるサービス 下記のサービスがご利用いただけなくなります。 ・ココログベーシック／プラス／プロ －管理画面へのアクセス －管理画面上の各種操作（記事投稿など）※1 －公開日時指定機能 ※2 －トラックバック／コメン
TheC10kProblem - 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと
TheC10kProblem - 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと 目次 この文書について C10K 問題 関連サイト まず読むべき本 I/O フレームワーク I/O 戦略 1. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と レベル・トリガ型の完了通知を利用する. 伝統的な select() 伝統的な poll() /dev/poll kqueue() 2. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と 変更型の完了通知(readiness change notification)を利用する. kqueue() epoll リアルタイム・シグナル fd 単位のシグナル (Signal-per-fd)
Google Tokyoの技術講演会に参加したので簡単コメント - Ogawa::Memoranda
Posted by: Hirotaka Ogawa @ February 03, 2007 10:09 PM | 昨日のことですがセルリアンタワーでやっていたGoogle Tokyoの技術講演会に参加してきました。まあ割と面白かったと思います。質疑時間が短すぎてちゃんと質問できなかったのでコメントがてら書いておきます。 南野さんのtalk: 世界中で単一のエンジニアリングチームがすべての設計文書・ソースなどを共有していることに関して。アクセスコントロールを考慮しなくて良いことは事務的コストの削減に大いに役立つが、実際にエンジニア・インターンがsingle point of failureになり得る。NDAを結ぶから平気というのもおかしな話で、個人に負わせ得る責任にはおのずと限界があるのであって、全情報の流出による損失がそれを上回るのであれば対策が必要なのは明らかではないか。まだ流出したこと
12/5 ココログデータベース分散化実施について: お知らせココログ:@nifty
日頃よりココログをご利用いただきまして誠にありがとうございます。 ココログ負荷問題の抜本的な対策として、ココログベーシック・プラス・プロのデータベース分散化を2006年12月5日（火）に実施する予定です。 当日はココログベーシック・プラス・プロのバージョンアップも同時に実施いたします。 詳細な時間、バージョンアップ内容につきましては後日改めてご報告させていただきます。 なお、このバージョンアップで長らくご愛顧いただきましたココログベーシック・プラス・プロ@niftyBooks ISBN Lookup機能が提供終了となります。現在ご利用の場合、該当箇所のリンクがバージョンアップと同時に無くなることはありません。こちらも、詳細につきましては改めてご報告させていただきます。 今後ともココログをよろしくお願いいたします。
[ThinkIT] 第6回：データベースの負荷分散とまとめ (2/3)
ところで、はてなブックマークではMySQLのレプリケーション機能を素直に使った負荷分散を行っているわけですが、これはソーシャルブックマークというアプリケーションの特性を考慮してのことです。 ソーシャルブックマークサービスはコンテンツとして閲覧されるページが非常に多く、発行されるSQLのクエリーの多くは参照系のクエリーになります。参照系と更新系のクエリーの割合は、だいたい80％〜90％が参照系という具合です。ソーシャルブックマークに限らず、掲示板やブログなど多くのWEB＋DBアプリケーションでは参照系クエリーが多くなるかと思います。 こういった場合は、レプリケーションによる負荷分散が効果的です。レプリケーションではマスター1台に対して複数のスレーブを持たせることができ、理論的にはスレーブは何台でも追加できます。先に述べたとおり、参照系クエリーはスレーブが担当するので、参照系クエリーを分散させ
[ThinkIT] 第1回：Inside Hatena Bookmark (2/2)
ハードウェアは、はてなブックマークに限らずはてなのサービスでは基本的にすべて自作のPCサーバーを利用しています。はてなブックマークで利用している17 台もすべて自作のPC サーバーで、基本的なスペックは、次のようにごく普通なものです。 秋葉原のパーツショップからパーツを取り寄せ、自社で組み立ててサーバールームに設置しています。 通常のWebサイトの運用では、あまりハードウェアを自作したりといった話は聞きません。わざわざハードを自作するからにはそれなりのメリットがなければなりませんね。ハードウェアの自作に関してはてなが重要視しているポイントは、次の点です。 インターネットで不特定多数に対して公開されているシステムの難しさの一つに、負荷の見積もりがあります。ある程度人気のあるインターネットサービスではトラフィックは一定に落ち着くことはなく、アクティブなサービスであればあるほどそれは日々上昇し続
かいはつにっし サーバを増やすということ
ココログスタッフです。コメントに対して別ブログからトラックバックという変則的な答え方ですが、お答えします。 リンク: ココログレスポンス問題お知らせブログ（臨時）: メンテナンス後の経過報告（7/13-7/20）. >また、その後、アプリケーションサーバの台数も倍増いたしました。 >その結果、まだまだ合格点はいただけないと思いますが、なんとかご利用いただける状態になったと思います。 社長のブログはコメントできないのでこちらに書き込みますが現状を社長自身が >まだまだ合格点はいただけないと思います と評価してますけどそれなら当面は倍増と言わずに3倍4倍ともっとアプリケーションサーバの台数を増やして下さいよ。 それにあまり詳しくない私にはアプリケーションサーバの台数の増加とデータベース分散化との効果の違いがよくわかりません。 データベースの分散化はスペックの低いサーバをココログで使用する為じゃ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://japan.internet.com/webtech/20110315/8.html