タグ

関連タグで絞り込む (28)

タグの絞り込みを解除

tuningに関するkoyhogeのブックマーク (22)

  • Application Performance Monitoring (APM) with Elastic Observability

    Search and analytics, data ingestion, and visualization – all at your fingertips.

    Application Performance Monitoring (APM) with Elastic Observability
    koyhoge
    koyhoge 2016/11/13
    JavaScriptのパフォーマンス解析と改善点を明確化するサービス。試してみたい。
    リンク

  • MySQLのクエリ集計手法いろいろ | Ore no homepage


    Webサービスを開発/運用してるモンとしては、いろんなWebサービスを触ってみなきゃアカンってことで、アメリカの若モンに大人気ってふれこみのsnapchatに登録してみた。これでリア充の仲間入りやと思ったが、snapchat友達が同僚二人しかいないうえに、利用シーンがあまり思い浮かばないwwオジサン困っちゃいました。画像とか送信できるんだけど、数秒で消えるの。むしろそこがウリっていうね。どうやって遊ぼうか…。2月はブログ書かなかったなーと思ったのでMySQL小ネタ。世間的にも自分的にも真新しくもなんともないTipsです。 innotopで集計 実は以前、Qiitaに書いたので↓をば。。。 http://qiita.com/la_luna_azul/items/505ca441b8c8e6a87aaa 流れるクエリ、ロックの状況、トランザクション(show engine innodbs
    MySQLのクエリ集計手法いろいろ | Ore no homepage

  • MongoDBの単体性能（前編）


    はじめに MongoDBは使い始めるのが簡単で、インターフェースもJSONを出し入れするだけとシンプルなため、DBMSに関して知識が少ないアプリ開発者でも簡単にアプリを開発することができます。サクッとアプリを作り、サンプルデータで動作を確認し、いざ本番データで動かしてみたら﹁あれ？思った以上に性能が出ない﹂なんてことはないでしょうか？ ﹁MongoDBはNoSQLなんだから速い﹂という思い込みは危険です。MongoDBをはじめとするNoSQLは﹁水平分散(シャーディング)が得意で、水平分散すれば単体構成よりも速い﹂というのは事実ですが、単体構成が速いかどうかはチューニング次第です。また﹁NoSQLなんだからRDBMSより速い﹂という考えもよくありません。単体性能を比較した場合、どちらが速いかは単純には比較できません。 ﹁じゃあ、性能を上げるために水平分散をしよう！﹂と考えるかもしれませんが
    MongoDBの単体性能（前編）
    koyhoge
    koyhoge 2015/07/22
    MongoDBの問題点の切り分け。
    リンク

  • nginxのパラメータチューニングとh2o - Qiita


    (追記:タイトルが少々煽り気味な気がしたので微妙に変更しました。) h2oとnginxの性能比較 nginxよりも速いとされるh2oですが、実際に自分でもローカルでベンチマークを取ってみました。環境は以下の通りです。 EC2のc4.8xlargeインスタンス gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) Linux ip-172-31-13-40 3.14.35-28.38.amzn1.x86_64 #1 SMP Wed Mar 11 22:50:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux nginx-1.8.0 h2o-1.2.1-alpha1 wrk(ベンチマーク) ベンチマークコマンド 実行するベンチマークコマンドは以下になります。なお、オプションはできるだけRequest/secが大きくなるように調
    nginxのパラメータチューニングとh2o - Qiita
    koyhoge
    koyhoge 2015/04/28
    c4.8xlargeで「秒間82万リクエスト。」
    リンク

  • Facebookアプリを、HTML5でどうしてサクサクにできたのか。Sencha Touch開発チームが用いた3つのテクニック


    Sencha Touchの開発チームがHTML5で高速に動作するFacebookアプリを開発したことを紹介した1つ前の記事 ﹁Facebookのモバイルアプリが失敗した理由はHTML5のせいじゃない。HTML5でサクサク動くFacebookアプリを作って見せたSencha Touch開発チーム﹂は、非常に多くの読者に注目されました。 この記事で紹介したSencha Touch開発チームのブログ﹁The Making of Fastbook: An HTML5 Love Story﹂の後半では、どのようなテクニックを用いて高速なHTML5アプリケーションを実現したのかも紹介されています。 この記事では、その3つのテクニックについてポイントを紹介したいと思います。タイムラインやニュースフィードのようなユーザーインターフェイスを備えたモバイルアプリケーションは、これから広く開発されていくことにな
    Facebookアプリを、HTML5でどうしてサクサクにできたのか。Sencha Touch開発チームが用いた3つのテクニック

  • スマートフォン向けWebサイトの表示速度 高速化手法

    対象読者 スマートフォンWebサービス開発者 特に、フロントエンド周りの開発に従事する方 スマートフォン向けWebサイト高速化のテクニック スマートフォンはOS／デバイスの進化が激しく、要求される最適化の内容も半年で別物になることがあります。そのため最適化に際しては、案件ごとの状況や目的、デバイス／OSのシェアに応じて、まずターゲット端末を選定し、問題の検出を行います。 この記事では「iPhone 4＋iOS 5」を想定して話を進めます。実際に「iPhone 4＋iOS 5」はよく現場でも最も動作が重い組み合わせとしてターゲット端末に挙がります。これはiPhone 4がRetinaディスプレイを採用したことで960×460ピクセルの高解像度を備えながら、CPUなどのデバイス性能が潤沢とはいえず、ボトルネックが生まれやすいためです。iOS 4ではなくiOS 5をターゲット端末として扱うのは、

    スマートフォン向けWebサイトの表示速度 高速化手法

  • Introducing Dex: the Index Bot for MongoDB queries recommendations | MongoLab - MongoDB Hosting

    Greetings adventurers! MongoLab is pleased to introduce Dex! We hope he assists you on your quests. Dex is a MongoDB performance tuning tool, open-sourced under the MIT license, that compares logged queries to available indexes in the queried collection(s) and generates index suggestions based on a simple rule of thumb. To use Dex, you provide a path to your MongoDB log file and a connection URI f

  • GitHub - mongolab/dex: Index and query analyzer for MongoDB: compares MongoDB log files and index entries to make index recommendations

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - mongolab/dex: Index and query analyzer for MongoDB: compares MongoDB log files and index entries to make index recommendations
    koyhoge
    koyhoge 2012/07/27
    10gen謹製のMongoDBパフォーマンスチューニングツール。
    リンク

  • PHP Performance

    PHP Performance June 10, 2012. Moscow Rasmus Lerdorf http://talks.php.net/show/devconf Twitter: @rasmus

  • LinaroがAndroid 4.0.4を高速化、Pandaboard上でStockなAndroid 4.0.4の2倍高いベンチマークスコアを叩き出す | juggly.cn

    ARMアーキテクチャー用オープンソースソフトウェアの最適化などを手がけるエンジニア組織 LinaroがAndroid 4.0.4の処理性能の高速化に成功したというニュースが伝えられています。 LinaroのBernhard Rosenkränzer氏が香港で開催された同組織のミーティングにおいてデモを披露したそうです。デモではTI OMAP 4430を搭載したPandaboardを2つ用意し、片方にGoogle提供のAOSP版Android 4.0.4を、もう一方にLinanoがビルドしたAndroid 4.0.4をインストール。Google Playストアで公開されているベンチマークアプリ 「oxbench」の「3D」を実行したところ、AOSP版は30fps、Linaro版は60fpsという結果が得られたそうです。Linaro版はソースコードに手を加え、独自のツールチェインを使用してビル

    koyhoge
    koyhoge 2012/06/10
    ソースパッチだけでtoolchainそのままでどの位速くなるんだろ?
    リンク

  • ［3］Linuxカーネルの“巨大なロック”が原因と判明


    大規模サイトの性能改善作業とは、どういうものなのか――。リクルートの中古車情報サイト﹁カーセンサーnet﹂を全面リニューアルした体験を基に、その実態をレポートする。第1回、第2回はミドルウエアのチューニングを行った。後半はLinuxカーネルに原因があると判明するまでの調査に進む。様々なツールを組み合わせて追跡していった。 中古車情報サイト﹁カーセンサーnet﹂の性能試験が本格的に始まって10日目。試験の開始当初は、ブラウザーの表示に10秒もかかるなど目標性能に遠く及ばなかった。しかし前回までで紹介したように、ファイル共有システム﹁NFS﹂の設定変更、Webサーバー﹁Apache﹂のパラメーター修正、PHPアプリケーションの見直しによって、性能は劇的に向上した。 リクルート入社3年目の私は、今回の性能検証プロジェクトのリーダーとして、得意分野を持つチームメンバーと一緒に対策を進めていた。カッ
    ［3］Linuxカーネルの“巨大なロック”が原因と判明

  • チューニンガソンで優勝してきました : DSAS開発者の部屋


    7/9(土)にチューニンガソン というイベントに参加して優勝してきたので、その報告と、何を考えてどんなチューニングをしたのかを 記憶の範囲で公開したいと思います。 今回のチューニンガソンのお題は、WordPress(ja) + php + Apache + MySQL で、abを使って wp-comment.php 経由でコメントのポストをすることで計測が行われました。 MySQLとApacheを立ち上げたらWordPressが動く環境が渡され、そのWordPress自体は設定ファイルを含めて 改造が一切禁止、WordPressの実行をショートカットするチートも禁止です。 0. 試合前日 環境がAWSとAMI Linuxということは事前に公開されていたため、前日にAWSに登録して少しだけAMI Linuxを 触ってみました。yumベースだけどCentOSと違って結構新しいバージョンが用
    チューニンガソンで優勝してきました : DSAS開発者の部屋

  • tuningathon #1に参加してきました


    どうもコンニチワ。 去る2011.7.9に開催されたチューニング大会 tuningathon に参加してきました。 結果は2位。惜しかった！すごくすごく楽しかったです。 よくよく考えたらうちの会社のクライアント企業の方々もいらっしゃっていたりして、こりゃ負けられないぞ、と気づいたのは結果発表が半分すくらい済んでからでした。 まぁあまり細かいことは気にせずみんな参加したらいいと思うよ！俺が許す！ 主催のゼロスタートさんと技評さん、会場提供していただいたECナビさん、サーバ提供していただいたAmazonさんありがとうございました！ さて、今回は結果が出てほっとしたわけですが、具体的に何をやったのかメモっておきますのでご参考まで。 問題解決のアプローチを晒す意味で、やったことを順番に書いてみます。 ちなみに環境はMacBookAirです。会場のほとんどの人がMacでしたね。 まずtop,vmst

  • 稼動統計情報を活用しよう(3) — Let's Postgres


    NTT オープンソースソフトウェアセンタ 笠原 辰仁 有用な情報を持つテーブル / ビュー 稼動統計情報を持つテーブルとビューの一部について、どのような情報を蓄積しているかを紹介します。前ページで稼動統計情報の取得方法を述べましたが、紹介したもの以外にも、下記に示すように色々な情報が取得できます。 pg_stat_database DB単位で、実施された表スキャンやインデックススキャン数などが確認できます。DB単位でざっくりとしたアクティビティ状況を確認するのに便利です。このビューでは下記の項目を確認できます。 pg_stat_database 名前 ver. 説明

  • 稼動統計情報を活用しよう(1) — Let's Postgres


    NTT オープンソースソフトウェアセンタ 笠原 辰仁 稼動統計情報とは、PostgreSQLが独自に収集・記録している情報です。性能やDB内で起こっている問題などを把握する上で、とても重要です。DBMSでの稼動状況を確認・把握するのに非常に便利なので、この情報を活用し、問題の早期発見やチューニング方法の選択に役立てましょう。 稼動統計情報で分かること 稼動統計情報を活用すると、DBMSを運用する上でとても便利な情報が得られます。特に有用なものを紹介します。なお、稼動統計情報の内容はPostgreSQLのバージョンで若干異なり、新しいバージョンほど得られる情報が増えています。詳しくは﹁有用な情報を持つテーブル/ビュー﹂を見てください。 DB単位のコミット数やロールバック数 DB毎に、トランザクションのコミット回数やロールバック回数が分かります。それぞれ、スループットとエラー発生数と置き換える

  • XtraDB 5.5版 性能調整中


    色々ありましたが、最近、やっと 5.5.x 版のXtraDBを開発中で性能を確認しています。 SSD で試したりもしているのですが、今まで気にしていなかったことが意外に重要なことに色々気づいたので覚え書き。 SSD で更新系が多い処理で高性能を出すコツ1．Linux native AIOを利用する。 (5.5 共通) SSDはIOが速いので︵？︶、今まで通りInnoDB内部のaioを使うとちょっと非効率で、運が悪いと暫く処理されないリクエストが出てくる可能性がありそうです。5.5 ではもう内部のaioにはパッチを当てずにデフォルト通り Linux native AIOを使うことを推奨します。使えない環境の人は、なんとか使えるようにしてからビルドしてください。。。2．圧縮機能を利用しない。 データページの圧縮機能はSSDの折角速いIOレスポンスを殺します。もしもデータの容量がSSDに

  • Tuning Your PostgreSQL Server/ja - PostgreSQL wiki


    作者 Greg Smith、Robert Treat、およびChristopher Browne PostgreSQLは性能よりも幅広い互換性を目的に設定された、基本設定で配布されています。 デフォルトのパラメータでは、使用中のシステムを過小評価してしまう可能性が高いです。 最終的に把握しなければならない項目のすべて︵必要ならばGUC Three Hour Tourを参照してください︶に引きずり込まれないように、ここで基本を簡単に紹介することでお助けしようと思います。 これらはPostgreSQLの初心者は気にしない、もっとも一般的なもののようです。 ここで紹介した概要を読んだ後により詳しく知りたければ、各節にてパラメータの名前をクリックしてください。 最新のPostgreSQLのマニュアルの関連文書にリンクしています。 さらにServer Configuration Tuningには、こ

  • ニコニココメントサーバーにおけるメモリ使用量増大問題の調査と対策 - ドワンゴ 研究開発ブログ

    はじめに コメントサーバーは、ニコニコ関連サービスのコメントを司るサーバーである。本稿は、ニコニコ広場で起こったコメントサーバーメモリ使用量増大問題について、我々コメントサーバー担当が行った調査と対策のまとめである。 今回のメモリ増大問題の解決にあたり、「仮説を立てる + 計測する→修正する→確認する」というパターンを繰り返した。このパターンは、ソフトウェアの様々な問題を調査するのに適用できる、基本パターンである。 コメントサーバー概要 コメントサーバーについて簡単に概説する。 コメントサーバーはニコニコ関連サービスのコメントを管理するサーバーである。基本的な機能は、新しいコメントの保存、およびコメントの出力である。ニコニコサービスのユーザーがコメントサーバーに直接触れることはなく、ニコニコのプレイヤーがコメントサーバーと直接やりとりを行う。ニコニコ動画の例でいうと、コメントサーバーを使用

  • グリーCTOが語る、大規模ソーシャルゲーム開発の舞台裏


    9月1日、ゲーム開発者向けカンファレンス﹁CEDEC 2010﹂において、SNS﹁GREE﹂を運営するグリー株式会社︵以下 グリー︶が﹃大規模ソーシャルゲームのつくりかた ～60分でわかるサーバサイド技術～﹄と題するセッションを講演した。 一日あたり億単位のトラフィックを捌くインフラはどうなっているのか。技術者2名が解説したインフラ構築のノウハウや、ソーシャルゲームと一般のオンラインゲームとの違いについて紹介する。 オンラインゲームとソーシャルゲームとの違い 最近テレビCMでも目にする機会が多くなってきたSNS︵ソーシャルネットワーキングサービス︶の﹁GREE︵グリー︶﹂。2010年6月時点の数字で、会員数2059万人、月間353億ページビューという言わずとしれた大人気サイトだ。中でも携帯電話向けソーシャルゲームが特徴的で、専用機向けのゲームと比べるとコアゲーマー以外のプレイヤーも多く、利
    グリーCTOが語る、大規模ソーシャルゲーム開発の舞台裏

  • MySQL5.5.3-m3のDATETIME型のバグ。あとMySQLの DATETIME型は本当に遅いのか検証してみた - 2010-04-30 - 小野マトペの業務日誌(アニメ制作してない篇)


    バグの話 近々ふぁぼったーDBのInnoDB化を企てているので、それに伴いMySQL5.0.67(Tritonn)から、先日リリースされたばかりのMySQL5.5.3-m3に乗り換えてみた。RC(リリース候補)版ということで、GA版とほぼ変わらない品質と聞いたので、割と軽い気持ちでインストールしたんだけど、いきなりバグにハマった。 バグとは、DATETIME, TIMESTAMP, DATE, TIME型と文字列定数との結合でインデックスが使われない、というもの。 以下のような、date(DATE型)の結合しかしていないクエリでも、dateインデックスが使われず昇順フルテーブルスキャンされ、20秒くらい掛かった。 select date from STATUS force index(date) where date='2010-01-19' limit 10; この現象は、5.5.3,5
    MySQL5.5.3-m3のDATETIME型のバグ。あとMySQLの DATETIME型は本当に遅いのか検証してみた - 2010-04-30 - 小野マトペの業務日誌(アニメ制作してない篇)
  • 1 2 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.