ソーシャルゲームのためのMySQL入門 | BLOG - DeNA Engineering
こんにちはこんにちは。最近お腹痛いばっかり言ってることで有名なiwanagaです。 DeNAは外部的にはプラットフォーム的な部分の方がフィーチャーされることが多いですが、実はソーシャルゲームの提供も行っています。怪盗ロワイヤルとか、どこかで聞いたことがあるのではないでしょうか。 僕はDeNAでソーシャルゲームが誕生した辺りからずっとサーバサイドを見てきましたが、そんな運用の中で自分が貯めてきた知見とかTIPSをご紹介したいと思います。 かれこれ10タイトル近くはレビューしたり運用したりしてるため結構言いたいことはいっぱいあるので、小出しにしつつ評判よければ次も書きます。 ソーシャルゲームのためのMySQL入門一覧 ソーシャルゲームのためのMySQL入門 - Technology of DeNA ソーシャルゲームのためのMySQL入門2 - Technology of DeNA 「MySQL
mod_pagespeed Overview
Learn more Overview Page Speed extension mod_pagespeed for Apache 2 Get Started Page Speed extension mod_pagespeed for Apache 2 Security Considerations Documentation Performance Best Practices Optimize caching Minimize round trip times Minimize request overhead Minimize payload size Optimize browser rendering Page Speed rules (alphabetical) Avoid bad requests Avoid CSS expressions Combine external
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか 目次 この記事について FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか 背景 概観 詳細 一貫性と原子性 性能 FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか この記事について "How FriendFeed? uses MySQL to store schema-less data" の日本語訳です http://bret.appspot.com/entry/how-friendfeed-uses-mysql CC 2.5 でライセンスされています: http://creativecommons.org/
User Primary - A quick look at CouchDB Performance
I had a chance to play with CouchDB last week and carry out a few performance related experiments. The installation and initial configuration went surprisingly smoothly considering that CouchDB is a new project using a language, Erlang, that is not yet standard fare. I used the apt-get targets suggested on the CouchDB wiki, ran configure and make, and issued a few chmod commands so that my test us
Railsの画面生成を10倍高速化する方法 - 世界線航跡蔵
RailsでPageキャッシュをより広く活用する方法を考えてみました。以下、ちょっと長く前置きが続きます。 Rails遅杉 Railsは遅い。何が遅いって、Rubyが遅くてRoutingが遅くてRDBとRHTMLが遅い。RDBが遅いのは大抵のWebアプリケーションでは変わらない話、で、だからRailsなんかが評価される余地があるんだよね。RubyやRHTMLの遅さは柔軟性の代償として受け入れよう。なにしろRDBがもともと遅いんだから。ただ、Routingは無駄に高機能だったりして頭にくる。Rhino on RailsのSteve YeggeもRoutingは黒魔術だと言っていたし。私はActionPackの全てが黒魔術だと思うけど。 そういう訳で、RoutingをCで書き直すのはドリコムのみなさんがいつかやってくれると期待するとして(可能なら手伝いたいけどね)、当面の対応としてはキャッシュ
Apache MPMをめぐる冒険 〜eventとpreforkを比べてみるよ〜 : DSAS開発者の部屋
Apache 2.3からMPMの切替が実行時(起動時)に設定ファイルから動的に選択できるようになる点について、以前当DSASブログ内の記事で紹介しました。このMPMの切替によってどのようなメリットを得られるのでしょうか。実際にこれを動かしてみたときのCPU使用率とネットワークI/Oの変化を見ながら、それぞれのMPMモジュールの性能・特性を比較してみたいと思います。 まずは実験です。以下のような環境を用意しました。クライアント側については、ab(Apache Bench)によって単一のURLをひたすらダウンロードする単純なものです。しかも静的ファイルなので(中身はダミー)、純粋にApacheの転送能力のみの比較になります。サーバには、CPUはAtom D510、メインメモリ4GBを用意しました。クライアントとサーバの間はGbEで繋がっており、同一セグメント(中間ノード無し)となっております。
stress project page
stress is a simple workload generator for POSIX systems. It imposes a configurable amount of CPU, memory, I/O, and disk stress on the system. It is written in C, and is free software licensed under the GPL. Download Most questions should be answered by the FAQ. Build instructions are in the README. A simple list of changes per release is in the NEWS file. A detailed list of changes is in the Chan
サディストのための Ruby メトリクス計測入門 - たかみやの日記
ふぬけたコードをきたえるRuby で書かれたソースコードのまずい部分をメトリクス計測ツール (reek, roodi, flog, flay) を使って機械的に発見しましょうというお話です。それぞれのツールは次のことをチェックしてくれます。 reek: リファクタリングできそうな部分を発見 roodi: (reek とは別の指標で) リファクタリングできそうな部分を発見 flog: 複雑すぎる部分を発見 flay: 重複している部分を発見ポイントは、さまざまなチェックを rake コマンド一発でビシッとできるようにすることです。こうすることによって、その日の気分に左右されることなく一貫した厳しいチェックが繰り返しできるようになります。なおこの日記は、この記事を一部参考に書きました。ありがとうございます。 使い方コマンド一発で計測できます。 % rake quality もしコードにまずい部
ここギコ！: PostGISで1点からの半径検索は、UTMなりに変換してから検索するのがベストプラクティス？
2008年01月26日 PostGISで1点からの半径検索は、UTMなりに変換してから検索するのがベストプラクティス？ PostGISで半径x m内の地物を検索する場合、latlong（経緯度）で入っているデータだと空間インデックスが効かないので、どうするかと言う問題ですが。 以前、こんな記事を書いて、むりくりlatlong上で「半径x mの円」を内包する（内接ではない）矩形をざっくり計算し、それを空間インデックスと引き当てて、その後distance_sphere（latlongで入っているテーブルに対し、地球を球体近似した上での表面距離を算出する関数）の実行結果と比較する検索方法を紹介しました。 が、これは別にこれが常道というわけではなくて、GIS素人がちょっとずつ独学して、どんなやり方をすればいいかと試行錯誤した結果の産物です。 まあ言うなれば、ISSEIと同レベルのもの。 が、
Memcached のベンチマークツールを公開しました - higepon blog
Memcached のベンチマークツールを公開しました。自作の KVS のパフォーマンス測定に使っていたものです。 以下のように簡単にベンチマークがとれます。 $ mcbench -b 10000 -t 10 -n 1000 -s 127.0.0.1 -p 11211 -c get ==== mcbench started ======================= Server: 127.0.0.1:11211 10 threads x 1000 = 10000 commands. Inserting base data 10000 ... done Sending get Commands ... done ==== mcbench result ======================== Interval: 138 msec Performance: 72661 comma
アプリケーションがマルチスレッドでもマルチコアCPUを活かせない件 - blog.nomadscafe.jp
もっと詳しい方のフォロー募集です アプリケーションがマルチスレッドになってもネットワーク処理が分散されなければマルチコアを活かせない典型的な例です。id:viverの古橋さんがs100kpsとしてあげていた件にも近いかも。 memcachedで現象を確認します。最近のmemcachedはマルチスレッドで動くようになっているので、まずはそれを確認します。 $ memcached-tool localhost stats|grep threads threads 4 スレッドが4つで起動しています。 負荷がそれなりにある状態(8000req/sec程度)で、コマンドラインでtopを開き、「1」キーを押して、CPUごとの使用率を表示します。(例はFedora8 kernel-2.6.23) Tasks: 77 total, 1 running, 76 sleeping, 0 stopped, 0
Facebook Developers | HipHop for PHP: Move Fast
One of the key values at Facebook is to move fast. For the past six years, we have been able to accomplish a lot thanks to rapid pace of development that PHP offers. As a programming language, PHP is simple. Simple to learn, simple to write, simple to read, and simple to debug. We are able to get new engineers ramped up at Facebook a lot faster with PHP than with other languages, which allows us t
Facebook rewrites PHP runtime
A week ago, I let ya'll know that the core PHP team had been brought to Facebook's main campus. That team were forced to sign NDA's, and taken to a very quiet, secluded meeting room where some cool new Facebook-backed open source project was described. Well, I was able to put all the pieces together on this one, finally, and I now understand exactly what is up: Facebook has rewritten the PHP runti
JavaScriptのswitch文の速度はブラウザの違いでこんなにも差があった。 - 風と宇宙とプログラム
はじめに JavaScriptのswitch文は、CやJavaと異なりcaseのところに任意の式が書けるため、実行時にcaseの式も評価されるので基本的にはif-else文の並びと類似のものになります。つまり、caseの数に応じてパフォーマンスも低下すると予想されます。本当にそうなのか確認してみました。 測定した各ブラウザのバージョンは以下の通りです。 Firefox Chrome Safari Opera IE 3.5.6 4.0.249.30 4.0.4 (531.21.10) 10.10 8.0.6001 caseが数値リテラルの場合 パフォーマンスを測定するテストコードは下記のような簡単なものです。caseが1000個あるswitch文を10万回繰り返して実行したときの時間を測定しました。perf_test()関数の引数ｖに与える値に応じてcaseの条件で一致する場所が変わります。
キャッシュの大きいRDB vs インメモリデータベース、性能がどれだけ違うのか調べてみると
2週間ほど前に「インメモリデータベースがクラウド時代の主流になるという期待」というエントリを書きました。ハードディスクに代わり、メモリをデータベースの永続化手段とするインメモリデータベースは、超高速なアクセスとスケールアウトを実現する、クラウド時代のデータベースの主役になるのではないか、という内容です。 この記事に関して、TechVisorの栗原さんと次のようなやりとりをしました。 確かに、Oracle Real Application Cluster（以下、Oracle RAC）でデータベースが全部載るくらい十分にキャッシュ用のメモリを割り当てれば、メモリ上でデータベースを操作するインメモリデータベースと同じことではないのか、とも思います。 両者の違いは何かあるのでしょうか？ 調べてみることにしました。 インメモリデータベースは1000倍速い 調べてみるとすぐに、両者には明確な性能差があ
Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
MySQL :: How to Monitor MySQL's performance
Newsletters older than 6 months may have links that are out of date. Please use the Search to check for updated links. Here are some ideas, how you can monitor the database performance of your MySQL installation. Monitoring is always an iterative and continuous process. You need to learn what patterns are OK for your database and what are the signs of slight problems or even dangerous situations.B
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[PostgreSQL8.1.4] プランナが統計情報をどのように使用するか : planner-stats-details - Blue21(postgres)
Rails
