タグ

performanceに関するHashのブックマーク (82)

  • Rils4で Russian Doll Caching を楽しむためのまとめ [俺の備忘録]

    Google+ボタン はてなブックマークボタン 更新日時: 2014年01月11日(土) 作成日時: 2013年11月12日(火) 前の記事 / 次の記事 Rails4では従来の page cache や action cache は廃止され、 デフォルトのキャッシュ機構としては、Rails3までの fragment cache のようなものだけが使える。 Rails4のこのキャッシュ機構は今のところ RussianDollCaching、cache_digests、fragment cache 等と 呼ばれているみたいだけど指し示すものは全部同じもの。 というか最初別々の何かだと思ってて無駄に嵌まった。 Rails4で内部的に使われているgemが、 従来のRailsにおける fragment cache を進化させた cache_digests であり、 cache_digestsの仕組

  • パフォーマンス比較 Cassandra、Mongodb、SQLite、H2、MySQL、Postgres - cypher256's blog

    下記のようなシステムでパフォーマンスが良さげな SQLite を使用予定ですが、もっと速いものが無いか確認のため他のデータベースのパフォーマンスを計測してみました。SQL 利用前提ですが、NoSQL が圧倒的な性能を出す場合は検討する必要があるので KVS も確認しました。 データ件数は 1 億件程度、JDBC SQL 利用可能 INSERT、UPDATE はバッチ SELECT は主キーアクセス性能を重視 将来スケールアウトのための分散はありえるが、スタンドアロンで遅いのはだめ データベースのパフォーマンス比較 計測したデータベース データベース名 タイプ 形態 評判 計測についての備考 SQLite RDB 組み込み ※2 おもちゃ、Android標準 JDBC操作 ※1 H2 RDB 組み込み ※2 組み込み最速 JDBC操作 ※1 Derby RDB 組み込み ※2 Java標準で

    パフォーマンス比較 Cassandra、Mongodb、SQLite、H2、MySQL、Postgres - cypher256's blog
  • mk(pt)-query-digestをもっと活用しよう! - 筋トレとともに生きるDBAの雑記

    もはやこれが無くては障害対応ができないぐらい中毒になっているmk-query-digestさんについてです。 mk-query-digest - Analyze query execution logs and generate a query report, filter, replay, or transform queries for MySQL, PostgreSQL, memcached, and more. 例えばこんなことが起きたときは、何を差し置いてもまずtcpdumpを取りに行きます。 状況がおさまってしまってからでは遅いのです。 Load Averageの高騰 Too Many Connections lock wait timeout tcpdump -i bond0 -s 65535 -x -n -q -tttt 'port 3306' > tcpdump.out

    mk(pt)-query-digestをもっと活用しよう! - 筋トレとともに生きるDBAの雑記
  • Post by @derwiki

    We have a legacy system in our production environment that keeps track of when a user takes an action on Causes.com (joins a Cause, recruits a friend, etc). I say legacy, but I really mean a prematurely-optimized system that I'd like to make less smart. This 500m record database is split across monthly sharded tables. Seems like a great solution to scaling (and it is) -- except that we don't need

    Post by @derwiki
  • パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合

    MySQL 5.1で追加された機能にパーティショニングがある。これは適切に利用すれば非常に強力な機能であることは間違いないのだが、使いどころが難しい。なぜなら、 インデックスをつけるだけでカバー出来る場合が多い。 パーショニングを使わずに、単にテーブルを分けてしまえばいい。 テーブルが巨大にならないとあまり効果を実感できない。 使い方を間違えると性能が落ちてしまう。 などの問題があるからだろう。 そんなわけで、今日と明日でパーティショニングが役に立つシーンを2つ紹介しようと思う。今日は一つ目、インデックスをつけたいカラムのカーディナリティが低い場合だ。カーディナリティとは日語に訳すと濃度とか訳されるが、要は値の種類(分散具合)のことである。例えば、YesかNoの2つの値しかとらないカラムは非常にカーディナリティが低く、インデックスをつけるととても効率が悪い。インデックスを使って目的の行を

    パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合
  • Clojure プログラムを並列化したら遅くなったり複雑になったりするというのは何かの間違いではないかと思って確かめたら,やっぱり間違いだった件 - tnoda-clojure

    前回の Java と比べて Clojure が 3 倍以上遅いというのは何かの間違いではないかと思って確かめたら,やっぱり間違いだった件 の続きです. 今回は,前回普通に書いた並列化なし Clojure プログラムを並列化させます. 普通に書いた並列化なし Clojure プログラムのコードは前の記事を参照してください. 「普通に書いた Clojure プログラム」の並列化この記事では, pmapReducersの 2 つの方法を使って「普通に書いた Clojure プログラム」を並列化し, 並列化前と並列化後の実行時間を比較し,どちらが速いかを確認します. また,コードの変更点を確認することで,並列化によりどれだけコードが複雑化するかを議論します. pmap による並列化「普通に書いた Clojure プログラム」からの変更点は次の 2 つです: mappmap に置き換えた(1

    Clojure プログラムを並列化したら遅くなったり複雑になったりするというのは何かの間違いではないかと思って確かめたら,やっぱり間違いだった件 - tnoda-clojure
  • 2008-06-29

    mysqlを利用していて、indexをちゃんと張っているのにパフォーマンスが出ない。 explain でも type = ref / key = INDEX 等が表示されているのにすごくクエリーが遅かったりする。 思い切って index を消したら逆にパフォーマンスが改善した! why? データ件数が数万件を越えたあたりからパフォーマンスが劇的に下がった。 と、悩んでいたりしませんか? そんな悩みのひとつの解決策になってくれるかもしれません。 テストは vmplayer 上の debian etch で行います。 ホスト環境 intel Q6600 メモリ2Gの WindowsXPです。 クエリーをキャッシュされないように、クエリキャッシュを 0 にします。 /etc/mysql/my.cnf query_cache_size = 0 #no cahce debug swapで遅くなると困

    2008-06-29
  • LinkedIn Mobile Moved from Rails to Node: 27 Servers Cut and Up to 20x Faster | Hacker News

    If you are thinking about using node.js for this reason[1] on most sites, you are optimizing poorly. LinkedIn didn't worry about this until after they were a public company.If Python/Djando or Ruby/Rails can get your app out the door and into customer hands faster, it is almost always the right thing to use. 1. There are certainly other, very valid, technical reasons for choosing node.js over othe

  • ClojureのSTMは使い物にならない

    0x00. Clojureがいけてる件について ここ数ヶ月でClojureをどんどん実戦投入してみているが、その成果は素晴らしいの一言に尽きる。Javaでは考えられなかったほどスマートかつ柔軟にデータ処理が可能であり、「あれ、こんなに短い記述でできちゃうのか!」と驚かされることが多い。そんなわけで、何でもかんでもJavaで片付けてきた筆者はここにきてClojureにかなり惚れ込んでおり、電子書籍やらウェブサイトやらで格的に情報収集を進めているのだが… 0x01. Clojureの並列プログラミング 現時点では、Clojureを実戦投入したのは、ちょっとした処理に使うツール的なものだけである。理由は単に、筆者がまだClojureの初心者だからだ。しかしそろそろメインの仕事であるサーバアプリケーションやウェブアプリケーションでも使いたくてウズウズしてきており、そのような視点からさらに調査を進

    ClojureのSTMは使い物にならない
  • ISUCON公式Blog:

    Tweet 12月25日 9:30更新 「ライドと椅子のマッチング」の実装例のコードを修正しました。 ---- こんにちは、ISUCON14の作問チーム・NaruseJunのとーふとふです。この記事では、ISUCON14の問題として出題した「ISURIDE」の解説と講評をお届けします。今回の問題は、NaruseJunのメンバーが所属するポケットサインが作問を担当し、LINEヤフーの皆さんにフロントエンド実装でご協力いただきました。さらに、アドバイザーとしてfujiwaraさんにも参加していただき、非常に充実した作問体制を整えることができました。 それでは、ここから「ISURIDE」全体の構成や狙い、ボトルネックの仕掛けなどを順を追って解説していきます。 「ISURIDE」とは競技当日流したサービスの概要紹介動画は以下からご覧いただけます。 今回の問題では、いわゆるタクシー配車・ライドシェア

  • #isucon 2013 予選をトップ通過してきた(はず)。 - 双六工場日誌

    あとに回すと、ブログを書くハードルが上がってしまいそうなので、取り急ぎ。*1 さて、10月5日、6日と2日間の日程で開催された、isucon(いい感じにスピードアップコンテスト)の予選に参加して、なんと、総合トップで通過いたしました!!!!! 今回は、まずは予選突破を目指して参加したのですが、いろいろな幸運が重なり、現時点で予選総合トップ! 現時点では、運営の方のAMI審査で問題がなければ、という条件付きではありますが。 すでに、参加チームの幾つかからブログ報告が出ていますが、ほかのチームがかなりアプリ側のコードに手を入れているのとは、対照的にスコアの大半はインフラ側チューニングです。 特に、フロントにおいたnginxで以下にリクエストを捌くかがスコアアップの決め手になっています。 また、アプリの言語はPythonを選びました。Python 3.3が使われていたのにはちょっと戸惑いましたが

    #isucon 2013 予選をトップ通過してきた(はず)。 - 双六工場日誌
  • 最速配信研究会 - 「コネクションプーリング都市伝説」はほんとに都市伝説?(その2

    ずいぶんと間が空いてしまったが, 「コネクションプーリング都市伝説」はほんとに都市伝説?(その1)の続きについて書きたい. まず題に移る前にシリアル処理とパラレル処理の違いについて説明したい. シリアル処理ととパラレル処理 シリアル/パラレル処理というのは複数のタスクがあった場合の処理の方法で シリアル処理 → タスクを一つずつ処理する. パラレル処理 → タスクを並列に処理する という違いがある.一般にタスクの処理時間が一定で共通のボトルネックが 存在する場合,パラレル処理はシリアル処理に比べて遅くなる. 図1と図2は全タスクを処理し終わる時間はどちらも3単位で違いがないように見えるが, 平均処理時間を見てみると図1は2単位が平均処理時間になるのに対して,図2の方は 2+2/3単位が平均処理時間となるので不利になっているのがわかると思う. 実際にはこれに加えてタスクの切り替えのコストが

    最速配信研究会 - 「コネクションプーリング都市伝説」はほんとに都市伝説?(その2
  • 多次元配列の見えないリフレクションに注意 - tnoda-clojure

    速い Clojure の大敵といえば Java リフレクションです.*warn-on-reflection* を true にしておくと,REPL でリフレクションを警告してくれるので便利です. user> (def alist (java.util.ArrayList.)) #'user/alist user> (.add alist :foo) Reflection warning, NO_SOURCE_FILE:1 - call to add can't be resolved. ← これ true しかし,全てのリフレクションを検出して知らせてくれるわけではありません. *warn-on-reflection* を true にして次の defn foo を実行してみます. user> (set! *warn-on-reflection* true) true user> (def

    多次元配列の見えないリフレクションに注意 - tnoda-clojure
    Hash
    Hash 2013/07/07
    多次元配列では*warn-on-reflection*でも検出されないこっそりリフレクションが使われているという話. > 多次元配列を操作するときには,おとなしく全ての次元について型ヒントをつけたほうが良さそうです
  • Rails アプリケーションのパフォーマンスについて RubyKaigi 2013 で発表しました - クックパッド開発者ブログ

    インフラストラクチャー部の成田です。 先日開催された RubyKaigi 2013 で、 "High Performance Rails" というタイトルの発表をしてきました。 スライドと動画 発表の様子は ustream の録画をご覧ください。 [ustream id=33559705 hwaccel=1 version=3 width=480 height=302] スライドは以下にアップロードしてあります。 High Performance Rails (long edition) // Speaker Deck なお、発表時間の都合上、当日はここから 40 枚ほどのスライドを削除してしまいました。発表に使った短いバージョンのスライドはこちらです。 発表の概要 クックパッドは 2008 年から Ruby on Rails を採用し、ずっと使い続けてきました。サービスが成長するとともに

    Rails アプリケーションのパフォーマンスについて RubyKaigi 2013 で発表しました - クックパッド開発者ブログ
  • 大規模サービスでプログラマが注意すること(基礎) | GeNERACE labo

    みなさん、こんにちは。 GeNERACEのピンキリエンジニアひろゆきです。 いきなりですが、少しだけ自己紹介をしますと、前職やら何やらで比較的、大規模とよばれるサービスの開発、運用していました。 今回はその経験から得たノウハウ的なものをご紹介させて頂きたいと思います。 既にそういったサービスを経験されている方には当たり前のことかもしれませんが、これから参加される方、または、参加したばかりの方のお役に少しでもなれば幸いです。 データベースとの関わり方に気をつける これは基でありながら、かなり重要なため、関わり方(今回はRDB)について書きます。 (MongoDBなどのNoSQLと呼ばれるものは別のノウハウになるかと思います) 大規模サービスとなりますと、どうしても高負荷なものになりがちです。 単純にサーバースペックの問題もありますが、プログラムの実装方法で解決できる場合もあります。 それ

    Hash
    Hash 2013/05/17
    DB話メイン
  • Javaのパフォーマンスについての9つの誤信

    JVMはプロファイリングを利用してコードの最適化を行います。対象は頻繁に利用されるコードパスのみですが,徹底的に行うことで大きな効果を上げています。JITコンパイルされたコードに関しては,現在では多くの場面において (その割合も増えつつあります) C++の実行速度を凌駕しています。 このような事実にも関わらずJavaが今でも低速なプラットフォームとして認識されているのは,おそらくは初期バージョンのJavaプラットフォームでの経験が,歴史的な負のバイアスとして働いているためでしょう。 早まった結論を出す前に,客観的な見地に立って,最新のパフォーマンス結果を評価するようにお勧めします。 2. Java コードの1行にはそれ自体で意味がある 次の短いコード行を考えてみてください: MyObject obj = new MyObject(); Java開発者ならば誰でも分かるように,このコードはオ

    Javaのパフォーマンスについての9つの誤信
  • 16の言語と57のフレームワークを比較したベンチマークが凄い

    いつの時代もより高速に動作するフレームワークや言語に対する関心は高いものですが、そんな疑問に答えるWeb Framework Benchmarksの最新版が公開されています。こちらのベンチマークはテスト用のコードや環境がオープンソースになっており16の言語(C C# Clojure D Erlang Go Groovy Haskell Java JavaScript Lua Perl PHP Python Ruby Scala)と57のフレームワークについて最適な実装が集められてテストされているという点で一般性があります。また実行環境もEC2と実マシンの2種類をそれぞれ実行している点も興味深いです。 気になるテスト結果のうち特に複雑度の高いデータベースから複数件のデータを取得してHTMLページとして出力した場合の結果は下記のとおりです。 堂々のトップに輝いているのはServletで最大で1

    16の言語と57のフレームワークを比較したベンチマークが凄い
    Hash
    Hash 2013/05/07
    Java, Java, Go, Clojure, Java, Scala...
  • TechCrunch | Startup and Technology News

    Limited space! Get on waitlist to be the first to know when tickets go live!

    TechCrunch | Startup and Technology News
  • VPS > VPSベンチマーク比較完全版[GMO/カゴヤ/お名前/さくら/Serversman(DTI)/conoha+専用サーバ]

    全て 1.このサイトについて 2.作品DB開発/運用 3.ホームページ制作技術 4.Perl 5.C言語 / C++ 6.検索エンジン&SEO 7.サッカー 8.自分のこと 9.Linux 10.旅行 11.思ったこと 12.パソコン 13.Berkeley DB 14.その他技術系 15.企画 16.スマートフォン 17.鑑賞 18.皆声.jpニュース 19.インターネット業界 20.運用マニュアル(自分用) 21.技術系以外実用書 22.料理 23.ALEXA 24.アニメ 25.会計 26.漫画 27.設計書 28.色々サイト作成 29.サーバー 30.自分専用 31.生活 32.OP/ED/PV 33.ゲーム 34.DB整備 35.新規開始作品紹介 36.英語圏の話題 37.大道芸 38.映画 39.PHP 40.ダイエット 41.Mac 42.JavaScript 43.MySQ

  • マルチコアとネットワークスタックの高速化技法

    10GbE、40GbEなどの極めて高速な通信をサポートするNICが、PCサーバの領域でも使われるようになってきている。 このような速度の通信をソフトウェア(OS)で処理し高い性能を得るには様々な障害があり、ハードウェア・ソフトウェア両面の実装を見直す必要がある。 セッションでは、ハードウェア・ソフトウェア両面にどのような改良が行われてきており、性能を引き出すにはどのようにこれらを使用したらよいのかについて紹介する。

    マルチコアとネットワークスタックの高速化技法