タグ

performanceに関するtakuya-aのブックマーク (14)

  • サーバーさんに本気を出してもらうために憶えておきたい設定項目

    cpuspeed がオンだと.... — はせがワン (@hasegaw) 2014, 5月 29 ミドルウェアのスループットを測ろうと思ったのですが cpuspeed などの設定をぜんぜんやっていませんでした。。。 経験上、チューニング過程でいじりたくなるようなパラメータを思い出してみます。 パワーマネジメントに関する設定はオフにする UEFIやBIOSにはパワーマネジメント設定がありますが、これらを無効にするとプロセッサなどが無条件で定格クロックで走り続けます。ピーク性能を高めたり瞬発力を上げるためにはパワーマネジメントはオフにします。当然ながらベースの消費電力やファンの騒音は増えますが、かわりにいくらかピーク性能の向上が見込めます。 Hyper Threading はレイテンシーとスループットのトレードオフ Hyper Threadingは、たぶん、コア内でパイプラインを取り合うから

  • Webpack チャンク最適 テクニック - Qiita

    ターゲット 巨大なSPAを作ってしまった人へ 巨大なSPAを作らないように気をつけたい人へ 今回はJSだけにフォーカスするが、もっというと、 超速 を読んでください。 注意:資料は、webpack チャンクの挙動を概念的に説明することを重視しているので、 webpack の詳細な設定や、出力ファイル名などは実際の処理と一致しない。適宜自分の手元にある設定とすり合わせるように。 昨今のJSビルド問題と、その解決のためのゴール設定 巨大なJS(+最近は in JS された各種SVGCSS)はダウンロードだけではなく、UIスレッドのCPUをブロックする。 これはとくにCPUが貧弱な端末で体験が悪化する。そしてビルド時間で開発者体験を阻害する。 できれば webpack 推奨の 144kb 以内にしたい…が現実的に難しいので、 せめて 350kb ぐらいに抑えたい。 SPAなら (ローディン

    Webpack チャンク最適 テクニック - Qiita
  • 様々なrate limitアルゴリズム - Carpe Diem

    概要 インターネットに晒されているWebサービスでは TV等で紹介されたことによる大量流入 悪意ある人物からの攻撃 クライアントのバグに依る大量リクエスト など、来想定していた以上のトラフィックが来ることはよくあります。 単純にシステムを構築すると大規模トラフィックに対応できずシステムがスローダウンしてしまうため、何かしらrate limitをかけておいた方が良いです。 ただしrate limitと一口に入っても色々あるため、今回は主なrate limitアルゴリズムを紹介します。 Leaky bucket Leaky bucketはデータ転送レートを一定にする(=上限を設定する)アルゴリズムです。 下の図のように、様々な流量の水流がそのバケツに流れ込んでも小さな穴からは一定の水流が流れ出す仕組みです。 ref: What is the difference between token

    様々なrate limitアルゴリズム - Carpe Diem
  • JVMの比較を目的とする新しいパフォーマンスベンチマーク”Renaissance”

    フルスタック開発者のためのBallerina: バックエンドAPI開発ガイド この記事では、REST API開発のためのプログラミング言語"Ballerina"の直感的な構文について解説します。さらに、認証や承認、OpenAPIツール、可観測性、SQL/NoSQLクライアントライブラリなど、重要な言語機能についても論じます。記事を読み終えれば、Ballerinaが次のバックエンドAPI開発の有力な候補である理由がよく理解できるでしょう。

    JVMの比較を目的とする新しいパフォーマンスベンチマーク”Renaissance”
  • 秒間100万リクエストをさばく - Googleの共通認可基盤 Zanzibar - 発明のための再発明

    はじめに Googleの提供するサービス郡が共通して利用している認可システムにはZanzibarという名前がついています。ZanzibarはGoogleDrive・Google Map・Youtubeなどの巨大なサービスにも使用されています。 そのため、利用量も凄まじく 数10億のユーザー 数兆のACL(access control list) 秒間100万リクエスト もの量をさばいています。 にも関わらず、Zanzibarはこれを10ミリ秒以内に返します(95パーセンタイル)。 この記事では、そんなZanzibarの内部構造に関する論文「Zanzibar: Google’s Consistent, Global Authorization System」の中から、主に大量のリクエストをさばくための工夫を紹介します。 ちなみに、以前Googleの社内システム用の認可システム「Beyond

    秒間100万リクエストをさばく - Googleの共通認可基盤 Zanzibar - 発明のための再発明
  • 6万ミリ秒でできるLinuxパフォーマンス分析 | Yakst

    NetflixのシニアパフォーマンスアーキテクトであるBrendan Gregg氏による、Linuxサーバにログインして60秒でまず調べることのまとめ。 パフォーマンス問題でLinuxサーバーにログインしたとして、最初の1分で何を調べますか? Netflixには、多数のEC2 Linuxからなるクラウドがあり、そのパフォーマンスを監視したり調査したりするための数々のパフォーマンス分析ツールがあります。その中には、クラウド全体にわたる監視を行うAtlasや、オンデマンドにインスタンスの分析を行うVectorがあります。これらのツールは多くの問題を解決する手助けをしてくれますが、各インスタンスにログインし、標準的なLinuxパフォーマンスツールを実行する必要がある場合もあります。 この記事では、すぐ使えるはずの標準的Linuxツールを使いコマンドラインにおいて、最適化されたパフォーマンス調査を

  • Linux benchmark scripts and tools

    August 14, 2023 by Hayden James, in Blog LinuxThis list of Linux benchmark scripts and tools should prove helpful for quick performance checks of CPU, storage, memory, and network on Linux servers and VPS. Check each script before running from the command line. Most of these scripts will benchmark the CPU, memory, storage, and network. In most cases, the CPU Model, frequency, and number of cores w

    Linux benchmark scripts and tools
  • 6年くらい前に自作した metric がそこそこ有用だと思うので、OSSで公開します | GREE Engineering

    こんにちわ。せじまです。 秋くらいから艦これ再開したので、ちょうどよいWindowsタブレットはないものかと物色しており、 Surface GO LTE Advanced(一般向け)の発売を待ちわびている今日この頃です。 はじめに はるか昔kernel 2.6 の頃、Load Average が低めに出てしまうというバグがありました。 当時、弊社では Load Average を監視項目の一つにしていたため、これには大いに困りました。 また、その頃、私は resource monitoring に力を入れていたのですが、以前 blog でも書かせていただいた通り、MySQLのサーバ一台あたり200以上のmetricを収集していたため、「多すぎてどれを見ていいかわからない」といった声が社内から上がっていました。 そういった諸々の問題を解決するため、6年くらい前、私はあれこれ思案して、新しい

    6年くらい前に自作した metric がそこそこ有用だと思うので、OSSで公開します | GREE Engineering
  • GitHub - Microsoft/Ethr: Ethr is a Network Performance Measurement Tool for TCP, UDP & HTTP.

    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.

    GitHub - Microsoft/Ethr: Ethr is a Network Performance Measurement Tool for TCP, UDP & HTTP.
  • jemalloc/TUNING.md at dev · jemalloc/jemalloc · GitHub

    jemalloc/TUNING.md at dev · jemalloc/jemalloc · GitHub
  • ISUCON8 で予選を突破したのでまとめる - stop-the-world

    ディメンジョナルハイソサイエティぬれねずみというチーム名で ISUCON8 に出場しました。言語は Perl を選択しました。 結果は 40,867点で、13位 / 528組。 技術的なことについては、すでにチームメンバーの2人が書いてくれているので、自分からは主にそれ以外のことについてまとめます。チームメンバーのブログは以下: ISUCON戦に出られることになった - hitode909の日記 ISUCON8予選を突破した - $shibayu36->blog; メンバー構成 同じ会社の同僚3人で出ました。 id:hitode909 アプリケーションエンジニア Perl めっちゃ書ける、普段から業務でバリバリ使ってそう 出場は3回目 id:shiba_yu36 アプリケーションエンジニア Perl めっちゃ書ける 初出場 id:takuya-a アプリケーションエンジニア Perl

    ISUCON8 で予選を突破したのでまとめる - stop-the-world
    takuya-a
    takuya-a 2018/09/24
    僕以外のメンバーが強すぎた回です
  • I/O負荷の正確な状況はiowaitでは分かりません - Qiita

    さくらインターネットのアドベントカレンダー9日目として、サーバ屋らしく、運用に関するコマンドの使い方を紹介します。 サーバの負荷が高まってきたときに、vmstatやtopなどのコマンドで調査する事が出来ますが、I/O負荷をwa(iowait)によって判断する人も多いと思います。 ただ、結論から言うと、iowaitは正確にI/Oの負荷を表しているわけではありません。 これらを、実際に演習をしながら見ていきたいと思います。 iowaitとidle iowaitとはあくまでも、CPUが空いているのにI/Oがボトルネックになっているプロセスを示しているだけで、CPUの利用率が高いときにはI/Oがボトルネックになっていてもiowaitが上がりません。 同様に勘違いされがちなのが、id(idle)はCPUの空きを示しているというものですが、idleは必ずしもCPUの空き時間を示しているものではありませ

    I/O負荷の正確な状況はiowaitでは分かりません - Qiita
  • リニューアルした日経電子版が高速すぎてヤバイ件|こんぴゅ

    経済新聞は国内を代表する経済誌だ。その電子版はwebでの継続課金を大成功させ、いまや50万以上の有料会員を擁するモンスターサイトだ。 その日経電子版が11月6日に全面リニューアルしたのだが、公開後、web業界がにわかにざわついた。表示速度が爆速だったのだ。日経公式もモバイルで2倍の表示速度を達成したと堂々と宣言していた。 webサービスは継続率こそ神KPIで、その継続率には速度が大きく影響する。 これはチェキらないとヤバイと感じ、友人のkitakさんとスピードの秘密を調査してみた。 Fastlyをコンテンツキャッシュに使う殆どのデータはFastlyを経由して取得されていた。Fastlyは最近注目を集めているCDN(世界中にエッジサーバーを配置し、高速にコンテンツを配信するサービス)で、非常に高機能でユニークなサービスだ。 一般に、CDNはいったん世界中にコンテンツをばらまくと、それを無

    リニューアルした日経電子版が高速すぎてヤバイ件|こんぴゅ
  • ISUCON 5予選で5位通過した話 - ゆううきブログ

    ISUCON 5の予選で2日目3位、全体で5位のスコアで通過した。 メンバーは id:ntakanashi さん, id:astj さんと自分の3人で、「はむちゃん」というかわいいチーム名で参加した。 言語は当然Perl。 役割分担は id:astj さんの記事にも書いてあるけど、だいたい以下のようなものだった。 id:y_uuki : ミドルウェアより下をお任せ / ログ解析して改善ポイントの洗い出し id:ntakanashi : オンメモリにしたりモジュールを入れ替えたり諸々チューニング id:astj : クソクエリやN+1をちまちま潰していくISUCON 5の予選に参加して全体5位で通過しました - 平常運転 昨年のISUCON 4に参加したときに、少なくともISUCON予選においてはアプリケーションロジックの改善/改変がスコアに対して支配的だと感じていた。 そこで、インフラ担当

    ISUCON 5予選で5位通過した話 - ゆううきブログ
  • 1