並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 158件

新着順 人気順

パフォーマンスチューの検索結果1 - 40 件 / 158件

  • なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − @IT

    ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1~5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture

    • CPU使用率は間違っている | Yakst

      Netflixのパフォーマンスエンジニアである筆者からの、topコマンドなどで表示されるCPU使用率(%CPU)は、いまや本当の使用率を表しておらず、チューニングなどのための指標として使えないという指摘。なぜそうなってしまったのか、何を見れば本当のCPU使用率がわかるのかをわかりやすく解説した記事。 私たちみんながCPU使用率として使っている指標は非常に誤解を招くもので、この状況は毎年悪化しています。CPU使用率とは何でしょうか?プロセッサーがどのくらい忙しいか?違います。CPU使用率が表しているのはそれではありません。私が話しているのは、あちこちで、あらゆる人たちに、あらゆる監視製品で、あるいはtop(1)でも使われている、"%CPU"という指標のことです。 あなたの考えているであろうCPU使用率90% : 実際 : "stalled"(訳注 : 以下ストールと言う)とは、プロセッサーが

        CPU使用率は間違っている | Yakst
      • MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ

        こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの?」みたいな経験はありませんか?不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、

          MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
        • ITインフラで起きる「もしも」のための12個のコマンド

          こんにちは。斎藤です。 ITインフラの障害は、多くの場合「予期せぬ」タイミングで発生します。特に、CPUリソースを多量に消費したり、Disk I/Oが輻輳している場合、その切り分けは困難な状況に陥りやすいものです。 そこで、本日はITインフラ、特にOS・ミドルウェアを支えるにあたって、問題解決を助けてくれるであろう12個のコマンドを取り上げてみます。「必ず押さえておきたい」5つのものと「更に覚えると便利なコマンド」7つの2節に分けてお話しします。 ※CentOS 6.4 (64bit)を前提に取り上げます 必ず押さえておきたいコマンド もしITインフラ管理者になりたてな方はぜひ サーバサイドのプログラマをやっていたのだけれど、ある日突然「君、サーバ管理担当ね!」と、バトンを渡される方っていらっしゃると思います。私も以前はそのクチでした...。そうなってしまったとき、まずは覚えておきたい5つ

            ITインフラで起きる「もしも」のための12個のコマンド
          • MySQLのEXPLAINを徹底解説!!

            以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約?を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか?そのためにはまず現在どのようにクエリが実行さ

              MySQLのEXPLAINを徹底解説!!
            • サイトを37倍に高速化した7つの手法 - オールアバウトTech Blog

              今回はオールアバウトのnnmrが弊社サイトAll About Japanの速度を高速化した経緯についてまとめます。 All About Japanとは そもそもAll About Japan(以下AAJ)とは何かといいますと、弊社が提供している訪日外国人向けの日本紹介サイトです。 外国人向けサイトで、英語、中国語(繁体字)、中国語(簡体字)、タイ語、韓国語の5か国語に対応しております。 「Anime」「Izakaya」「Ninja」といったような特集や、実際に観光する人向けのモデルルート記事が特色です。 ■ 特集 (url : http://allabout-japan.com/en/tag/sushi/ ) ■ モデルルート記事 (url : http://allabout-japan.com/en/article/222/ ) 技術的な紹介 LAMP環境です。 (サーバー構成は後に記述

                サイトを37倍に高速化した7つの手法 - オールアバウトTech Blog
              • 開発者のためのSQLパフォーマンスの全て

                前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検

                  開発者のためのSQLパフォーマンスの全て
                • mixiの生みの親“バタラ氏”が語るMySQLの意外な利用法 - TechTargetジャパン

                  日記だけで4億件のデータ ミクシィが運営するSNS「mixi」は、2007年7月末段階でユーザー数が1110万人。人が12人集まれば、1人はmixiユーザーというわけだ。ユーザーのアクティブ率(ログイン間隔が3日以内)は約62%と高く、2007年4月から6月の月間平均ページビューは117.5億に達した。日記だけでも4億件以上に上るなど、蓄積するデータ量も莫大。2004年3月のサービス開始から、わずか3年半で現在の巨大コミュニティーへと発展したのだ。 ミクシィは、「LAMP(OSのLinux、WebサーバのApache、DBMSのMySQL、開発言語のPerl、PHP、Python)」と呼ばれるWebシステム向けの標準的なオープンソースソフトウェア(以下、OSS)でシステムを自社開発し、安価なPCサーバを1000台以上連ねる超分散構成でmixiのサービスを支えている(広告配信など周辺機能では

                    mixiの生みの親“バタラ氏”が語るMySQLの意外な利用法 - TechTargetジャパン
                  • Macを大掃除して、快適&スピードアップ大作戦 | ライフハッカー・ジャパン

                    まず一番最初にすることは、Macの動きを遅くしたり鈍らせたりしている原因を突き止めることです。[アプリケーション]>[ユーティリティ]>[アクティビティモニタ]を開いて、その時起動しているアプリケーションやプロセッサのリストを見ます。 CPUのところをクリックして、CPUを使っている順に並べ替えてみます(この画像の場合:Firefox)。また、何がIntel アプリで、何がPower PC アプリなのかもチェックしましょう。Intel Macの場合は、Intelアプリのみの方がやっぱりいいです。アクティビティモニタを見て、不要なアプリやプロセッサが起動していたら要注意です。CPUやメモリを無駄に食っているものは、すぐに終了して再起動しましょう。 (2)起動項目を整理する 次は、Macログイン時に自動的に起動しているアプリをチェックしましょう。[システム環境設定]>[システム]>[アカウント

                    • Javaの謎のパフォーマンス劣化現象との戦い - Cybozu Inside Out | サイボウズエンジニアのブログ

                      こんにちは。アプリケーション基盤チームの横田です。 Javaの謎のパフォーマンス劣化にまつわる調査をしていたのですが、1ヶ月の苦労の末に原因がわかりましたので、報告させていただきます! 公開後に頂いたはてなブックマークでのご指摘・社内でのタイポ・読みにくいなどの指摘を受けてたので、謹んで修正させいただきます。 修正した内容につきましては、記事の最後を参照してください。 忙しい人のためのまとめ jdk-7u4以降のjdk-7 *1 でJavaのパフォーマンスが劣化する謎の現象 CodeCacheの容量限界に近づくとJITコンパイラを停止してコンパイルしたコードを捨てる機能が原因だった 起動オプションで回避できるので、長期運用するときは -XX:-UseCodeCacheFlushing, -XX:ReservedCodeCacheSize=128m をつける 上のオプションを設定した時に、C

                        Javaの謎のパフォーマンス劣化現象との戦い - Cybozu Inside Out | サイボウズエンジニアのブログ
                      • 『MySQL初心者に贈るインデックスチューニングのポイントまとめ2014』

                        サイバーエージェント公式ブログをご覧の皆さんこんばんは、インフラ&コアテク本部の須藤(@strsk)です。普段はAmebaのソーシャルゲーム全般のインフラを見つつ、日本語ラップの啓蒙をしながら弊社社員を素材にコラ画像をつくったりしています。好きなAAは麻呂です。 はい、というわけで今回はMySQLインデックスチューニングの基本的な流れについてまとめてみました。 ソーシャルゲームは更新も参照もめちゃくちゃ多いです。数秒のレプリケーション遅延も致命的なので適切なテーブル、クエリとインデックス設計が重要です。(何でもそうですけど)インデックスが多くなると更新コストなどが懸念されますが、インデックスが正しく使われていないクエリを放置している方が悪です。そんなこんなで、割と例も偏ったりしてるかもしれませんがあしからず。 前提としてはInnoDBを想定しています。MyISAMはほとんど使っていません。

                          『MySQL初心者に贈るインデックスチューニングのポイントまとめ2014』
                        • Devsの常識、DBAは非常識

                          AWS Summit Tokyo 2016 Developers Conferenceにて発表した資料です。 http://www.awssummit.tokyo/devcon/index.html

                            Devsの常識、DBAは非常識
                          • SQLのインデックスとそのチューニングについてのオンラインブック

                            開発者向けのSQLインデックス解説サイト、管理についての間違いない知識を提供します。 インデックスは開発時には忘れられがちである一方で、非常に効果的なSQLのチューニング方法です。Use The Index, Lukeでは、HibernateなどのORMツールの解説にとどまらず、SQLのインデックスについて基礎から説明します。 Use The Index, LukeはSQLパフォーマンス詳解のWeb上の無料版です。サイトを気に入って頂けたら、ぜひ書籍も購入してみて下さい。また、このサイトの運営をサポートする様々なグッズも販売しています。 MySQL、Oracle、SQL ServerなどにおけるSQLのインデックスUse The Index, Lukeでは、ベンダにとらわれないインデックスの説明を心がけています。製品特有の事柄については、以下のような表示をしています。 DB2Use The

                              SQLのインデックスとそのチューニングについてのオンラインブック
                            • Web高速化 || パフォーマンスチューニングBlog: インターオフィス

                              AWSアドバンスドコンサルティングパートナーの一員として活動する株式会社スタイルズが、AWS導入、移行、開発、セキュリティ、運用保守など、すべてのご相談に乗らせていただきます。 AWSを導入したいが何から始めたらいいかわからない 既存のベンダーが新技術に弱く、良い提案がもらえない クラウドの導入にセキュリティの不安がある AWSをとりあえず導入したが、さらに活用していきたい 社内にAWSの知見を持っている人がいない AWSならではのシステム開発を詳しく知りたい

                                Web高速化 || パフォーマンスチューニングBlog: インターオフィス
                              • なぜMySQLのサブクエリは遅いのか。

                                よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか?半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし

                                  なぜMySQLのサブクエリは遅いのか。
                                • はてなブログにおけるページ表示速度改善の取り組みについて - Hatena Developer Blog

                                  こんにちは、id:hakobe932です。はてなブログではユーザ体験の改善のために、ページ表示速度を向上させるための様々な取り組みを行っています。このエントリーでは、はてなブログで行っている、ブラウザキャッシュの活用、JavaScriptのページ最下部での読み込み、JavaScriptの圧縮、という3つの取り組みについて解説します。 ブラウザキャッシュの活用 同じ内容のJavaScriptやCSSを、ページを表示するたびにダウンロードすると、余分なHTTPリクエストが発生しますし、読み込み時間がかかります。 ブラウザのキャッシュを利用できれば、余分なリクエストを減らすことができます。はてなブログでは、なるべく長い間ブラウザにキャッシュを保存するために、JavaScriptなどの一部の種類のファイルのレスポンスに、以下のようなヘッダを指定しています。 $ curl -I http://hat

                                    はてなブログにおけるページ表示速度改善の取り組みについて - Hatena Developer Blog
                                  • O/Rマッパーによるトラブルを未然に防ぐ

                                    「ORMがトラブル起こすから嫌い」なんじゃなくて、「ORMが起こすトラブルが解決できないから嫌い」ってのがほんとのところじゃない?だったら解決方法を知ればいいんじゃね?というお話。「N+1問題」もろくに知らずにORMを批判せんでほしい。Read less

                                      O/Rマッパーによるトラブルを未然に防ぐ
                                    • ApacheとNginxの性能比較でevent_mpmの本気を見た

                                      はい、これは僕がいつも良く見るApacheとNginxの性能差に見えます。大体、ApacheはNginxの75%程度の性能に落ち着きます。数十バイトの静的コンテンツに対するリクエスト処理はNginxの得意分野だと思っていたので、大体こんなものです。 そこで、真面目にevent_mpmのチューニングを行ってみました。で、幾度となくベンチを試した結果導き出した、静的コンテンツに対する同時接続数100程度に対して最高のパフォーマンスを示すevent_mpmの設定は以下のようになりました。 [program lang=’apache’ escaped=’true’] StartServers 4 MinSpareThreads 4 MaxSpareThreads 4 ThreadsPerChild 2 MaxRequestWorkers 2 MaxConnectionsPerChild 0 [/p

                                        ApacheとNginxの性能比較でevent_mpmの本気を見た
                                      • 0から始めるNode.jsパフォーマンスチューニング

                                        近年の Node.js は API のサーバとしてはもちろん、Nuxt.js や Next.js といった SSR や BFF などフロントエンドのためのバックエンド言語としての人気が高まっています。 フロントエンドエンジニアがコンテキストスイッチ少なくバックエンドの整備ができることは非常に大きな利点です。 ですが、フロントエンド(ブラウザ側)とバックエンド(サーバ側)ではパフォーマンスチューニングで見るべき点が大きく違います。 しかし Node.js アプリケーションのパフォーマンスイシューの見つけ方などがまとまっている資料は少ないです。 そこで、本記事ではフロントエンドエンジニアが Node.js でパフォーマンスイシューを見つけ、改善するため自分が普段パフォーマンスチューニングを依頼されているときにみている基礎的なポイトをまとめていきます。 1. 計測ステップlink Node.js

                                          0から始めるNode.jsパフォーマンスチューニング
                                        • GIGAZINE - GIGAZINEのLoadAvarageを「27」から「2」へ下げた方法

                                          ここ3日間ぐらい超絶な重さだったのはサーバに物理的トラブルが発生したからではなく、単純に閲覧者数が満員御礼となり、各時間で倍増したためです。LoadAverageはひどいときで15分間の平均値「27.1」程度。瞬間最大風速だともっと高いです……明らかにまずい。 というわけで、Apacheのデフォルト設定で今までは大丈夫だったのですが、ついに高負荷サイト用の設定に変更せざるを得なくなりました。 そのため、実際に行った対処方法は以下の通り。1日30万PV近い動的サイトの高負荷を緩和させる方法として参考になれば幸いです。 まず大前提として、既にDNS逆引きや.htaccessの余計な読み込みなどは停止させていました。下記ページに書いてあることは実行済み。 @IT:Apacheパフォーマンス・チューニングの実践(1/2) この状態で負荷が15分平均で「27」になっていたわけです。 また、LoadA

                                            GIGAZINE - GIGAZINEのLoadAvarageを「27」から「2」へ下げた方法
                                          • mysql を高速化したいときに読むメモ (TechKnowledge)

                                            給料の振込口座として三井住友銀行に口座を持っています。自動支払いサービスを使用して光熱費等の公共料金の支払いをしていますが、先日それらの内の一つを失念してたことに気づきました。口座を確認した時にはすでに引き落としが完了していたため、手元の資金が心細くなった状態で数日を過ごさなければなりません。三井住友銀行で即日キャッシングが可能であれば、是非利用したいのですが。 運が良ければ、三井住友銀行の即日キャッシングは可能 三井住友銀行の特徴はまずクレジットカード会社との連携したサービスが魅力的なことがあげられます。キャッシングでは銀行カードローンですから、何より安い金利が大きい利点になります。概ね銀行系の審査に必要な時間は長くなるようですが、三井住友銀行ではカード発行が当日に行なってくれます。 三井住友銀行は即日キャッシングができるかと言うと微妙なことになります。申込から審査結果の連絡までは、土日

                                            • Railsアプリつくった - ✘╹◡╹✘

                                              最近APIサーバ用途でRailsアプリを1個つくったので振り返る。 概要 接続元はiOSやAndroidアプリとか、Webブラウザとか、別のWebアプリケーションとか。1ホストあたり秒間数百リクエスト、平均応答時間10msぐらい。Rails 4.1.0.rc2、Unicorn、Nginxを使ってる。正直Railsは全部入りで重いイメージがあったので何となく平均50ms以内程度であれば良いところだろうと思ってたけど、意外と速い。多分そもそもサーバの性能が良いんだと思う。実装時に気を付けたことは普段の開発と特に変わりない。いつもは大勢でワイワイ開発するものに少し手を加えるということが多いんだけど、今回は珍しく自分一人でつくったから目が行き届いてたのかもしれない。DBへの問合せの効率に気を配るとか、Rubyでの処理の無駄を省くとか、アプリケーションのプロセスに無駄なコードを読み込ませないとか、計

                                                Railsアプリつくった - ✘╹◡╹✘
                                              • ユーザーの体感速度を高めるためのJavaScriptチューニング(前編)

                                                連載「Webサイト・アプリ高速化テクニック徹底解説」第2回は、JavaScriptの高速化について、まずは前編、後編に渡ってユーザーの体感速度を向上させるための方法を紹介します。JavaScriptの同期・非同期の仕組みやscript要素のasync属性、defer属性について詳しく解説します。 今回から複数回に分けて、JavaScriptの高速化をテーマに解説していきます。まずは、ユーザーの体感速度を高めるためのJavaScriptチューニングということで、単純なJavaScriptの構文によるスピードを比較するようなものではなく、主にユーザー視点からの高速化を主眼に解説します。その中で、同期・非同期といったJavaScriptの仕組みやscript要素のasync属性、defer属性などについても触れていきます。 ユーザーの体感速度を向上させる 一概にJavaScriptの高速化といっ

                                                  ユーザーの体感速度を高めるためのJavaScriptチューニング(前編)
                                                • スマートフォンWebのフロントエンドを高速化する取り組み - クックパッド開発者ブログ

                                                  ユーザファースト推進部の丸山(@h13i32maru)です。 先日「撮るレシピ」というサービスを cookpad.com にて公開しました。「撮るレシピ」というサービスは料理本や雑誌のレシピを写真に撮ってクックパッド上に保存できるというものです。料理本や雑誌でレシピを良く見る方はぜひ使ってみてください(Androidアプリ版もあります)。 この「撮るレシピ」は全体公開前に一部のユーザに限定公開をしていました。そして全体公開をするにあたりフロント側のコードを全面的に書き換え高速化を行いました。その結果、最大で30倍高速化することができユーザの使い勝手が向上しました。以下が「書き換え前」と「書き換え後」の計測結果です(Android端末8機種 + iOS3機種で各操作のターンアラウンド時間*1を計測)。 閲覧系 最大: 30倍高速化(4.2秒→0.14秒) 平均: 15.7倍高速化(3.6秒→

                                                    スマートフォンWebのフロントエンドを高速化する取り組み - クックパッド開発者ブログ
                                                  • PHP製のWebアプリが遅い場合の基本チェック6点 - ほんじゃらねっと

                                                    先日別のチームから、 「PHPで作成したWebアプリの速度が遅いので助けてくれー」 という相談を受けた。 対応したものの、結構時間がかかって面倒だったので、 今後こういった問題が起こった時に使えるよう、チェックリストをまとめてやった。 基本的な内容だけど、 このチェックリストの内容をやってみて、それでもダメなら相談しなさい、 と伝えておくことで相談を減らすフィルタとして働いてくれるはずだ。 PHPプロジェクトに限らず、バックエンドでデータベースを使用している Webアプリのプロジェクトなら試す価値のあるものが多いはず。 調査や対応方法の手軽さ順で並べるとこんな感じ: Webブラウザのデベロッパーツールでレスポンスを計測する Webサーバ(Apache)のリクエスト時間をログに出力する ログ解析ツールでURL毎の付随リクエスト数を確認する データベースのスロークエリログを出力する プロファイ

                                                      PHP製のWebアプリが遅い場合の基本チェック6点 - ほんじゃらねっと
                                                    • Effective web performance tuning for smartphone

                                                      第三回DeNAゲーム開発勉強会の資料です。 https://atnd.org/events/59594Read less

                                                        Effective web performance tuning for smartphone
                                                      • RDBMSでコネクションプールが必要な理由、わからない。

                                                        Takayuki Shimizukawa @shimizukawa @masa_edw コネクションプールが無い場合、使い終わったコネクションが即解放されない(解放まで多少遅延する)ので実際に使っているコネクションの数より多く存在する。その分メモリを圧迫して効率が悪い。っていう話は聞いたことがあるよ(要出典 2013-09-04 09:27:28 ハイパーむとう @masa_edw @voluntas 現状で必要な状況は理解していますが、なぜそうなるのか理解していないということです。他にもたとえば、bitlyの呼び出しはコネクションプールを使うべきか?なぜ(べき、べきでない)のか?どういう要請でそうなのか?と言う問いに僕は答えられません。 2013-09-04 09:31:22

                                                          RDBMSでコネクションプールが必要な理由、わからない。
                                                        • 実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡

                                                          Slides of JDK Update (Especially Project Jigsaw) . https://jjug.doorkeeper.jp/events/33374

                                                            実例Javaトラブルシューティング! 〜稼働中のシステムを立て直した半年間の軌跡
                                                          • 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
                                                            • 最短かつ最速にアクセスする「DB高速化技術」(前編):ITpro

                                                              ポイント ・高度なインデックスやジョインを利用し,最短経路でデータにアクセス ・メモリー不足を自律的に解消し,キャッシュのヒット率を高める ・インメモリーDBは全データをメモリーで処理し,高速化を図る 目的地に早く到着したいなら,最短の経路を最速で行けばよい。これはデータベース(DB)でも同様だ(図1)。インデックスなどを使ってデータへの最短経路を見つけ,メモリー・アクセスを増やして,最速でたどり着く。DBにはそんな技術が詰まっている。 図1●データベース高速化技術のポイント ビットマップ・インデックスなどを使い、データにたどり着く最短の道を選ぶ。また、できるだけメモリーにデータをキャッシュさせておくことで、アクセスのスピードを上げる、という二つのポイントがある [画像のクリックで拡大表示] 以下では,(1)データにたどり着く最短の道を選ぶ仕組みと,(2)アクセスのスピードを上げる仕組みの

                                                                最短かつ最速にアクセスする「DB高速化技術」(前編):ITpro
                                                              • 日経電子版を速くする / nikkei-inside-frontend - Speaker Deck

                                                                Inside Frontend #2 の発表資料です https://inside-frontend.com

                                                                  日経電子版を速くする / nikkei-inside-frontend - Speaker Deck
                                                                • Where狙いのキー、order by狙いのキー

                                                                  2015/10/03 phpcon 2015 updated at 2016/01/13 about default_password_lifetime's default will be 0

                                                                    Where狙いのキー、order by狙いのキー
                                                                  • Windows Server 2008/2008 R2 関連ドキュメント | マイクロソフト 技術情報

                                                                    Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find

                                                                      Windows Server 2008/2008 R2 関連ドキュメント | マイクロソフト 技術情報
                                                                    • 複数のWebサーバでSSLセッションキャッシュを共有してSSL処理を高速化(Apache + mod_ssl + mod_socache_memcache) - 元RX-7乗りの適当な日々

                                                                      HTTPS(SSL利用)サイトがSEO的に優遇されるトレンドで、世間的にもHTTPS接続でサイト運用するサービスが増えてきています。 これが、ハイトラフィックサイトになってくると、このフロントエンドでSSL処理させることが負荷的にもなかなか辛いのです。 で、Apache 2.3以降では、Shared Object Cache Providerとして、memcachedが選択できるようになっています。 この仕組みを利用して、Apacheとmemcachedを並べることで、各サーバでユーザのSSL Session Cacheを共有しながらHTTPSリクエストを負荷分散できる構成を作ってみました。 WebサーバでSSLオフロード 常時SSLを利用したWebサイトを運用するために、SSLアクセラレータといったアプライアンス製品だとか、ソフトウェアだとApacheやNginxのSSLモジュールを使う

                                                                        複数のWebサーバでSSLセッションキャッシュを共有してSSL処理を高速化(Apache + mod_ssl + mod_socache_memcache) - 元RX-7乗りの適当な日々
                                                                      • G-WANはなぜ速いのか?をnginxと比べながら検証してみた - blog.nomadscafe.jp

                                                                        ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan  334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L

                                                                        • Javaメモリ、GCチューニングとそれにまつわるトラブル対応手順まとめ - 日記のような何か

                                                                          GC周りでトラブルシューティングした際の経験や、Web等で調べたことをまとめてみる。 前提 ・JVMは、Sun Javaを想定。(他は使ったことないです。。。) ・Sun Java 1.5-1.6を想定。 目標 マイナーGC、Full GCそれぞれが頻発することなく、かつそれぞれの実行時間を1秒未満に抑えること。 マイナーGCは1秒未満どころではなく、もっと短くなるべき。どれくらいが理想かは?(0.1秒未満ぐらいを目指したい?) 連続した負荷状態(想定されるピークアクセス)でもOutOfMemoryErrorが発生しないこと。 理想的な状態は、上記に加えて、Full GCの発生が低頻度であること。 具体的には、できるだけマイナーGCで短命オブジェクト(1回使ったらもう使わないようなオブジェクト。逆にセッションオブジェクト等は長命オブジェクトとなる)を破棄させて、短命オブジェクトが、Tenu

                                                                            Javaメモリ、GCチューニングとそれにまつわるトラブル対応手順まとめ - 日記のような何か
                                                                          • 3000req / sec と戦う - だるろぐ

                                                                            ざっくり概要 ピークで3000req / sec 毎分コンテンツ更新要求 コンテンツ更新の際は他所からデータをapi経由で受け取る コンテンツ更新にはTheSchwartzを使用 なコンテンツを色々してきたログ。 尚、ここに書く技術は大半が周囲のギークな方々にサポートしてもらったもので、僕自身が何かしたわけではない。残念すぎる。 構成 internet -> www(squid -> apache) -> app(memcached -> app) -> db フロントエンド wwwサーバがapacheとsquidを動かしている。apacheがリクエストを受け、squidのキャッシュが有ればそれを返し、無ければバックエンドのappサーバへproxy。 バックエンド appサーバがmemcachedとアプリを動かしている。 それぞれ冗長化してるけど、リクエスト数の割に台数は少ない。 技術があ

                                                                              3000req / sec と戦う - だるろぐ
                                                                            • JVMアプリケーションを運用する際のメジャーどころチューニングポイントメモ - yoskhdia’s diary

                                                                              JVMにチューニング項目は多々あれど、プロダクションで運用する際に予めおさえておきたい項目をまとめてみるエントリです。*1 勿論、OSもJVMもデフォルトである程度のパフォーマンスは発揮でき、計測を伴わないチューニングは悪手であることはよく知られています。 しかし、設定しておかないとパフォーマンスにそのまま影響すると分かるものを調べないのは裸で戦場に赴くようなものです。*2 どんな項目をどう変更すれば良いのか知っていることは重要な武器なのです。 なぜ調べるのか 今回、チューニングポイントを調べるにあたって、私のモチベーションはどこにあるのかを考えると、以下の要件を満たしたいということがあげられます。 アプリケーションとして求められる品質水準として動作する → 性能目標 異常時に事象を追うことができる ここでいう品質水準・異常とは、パフォーマンスが明らかに低い、アプリケーションがクラッシュす

                                                                                JVMアプリケーションを運用する際のメジャーどころチューニングポイントメモ - yoskhdia’s diary
                                                                              • 雑なMySQLパフォーマンスチューニング

                                                                                2019/01 JSUG勉強会の資料です。 この資料でDisっているのはJPAではなく、 ・何も考えずに「標準だから」というだけでJPAを選ぶ人 ・OSSに全くコントリビュートせずにフリーライドする人 です。

                                                                                  雑なMySQLパフォーマンスチューニング
                                                                                • 負荷試験コトハジメ

                                                                                  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

                                                                                    負荷試験コトハジメ