恭喜, 站点创建成功! 这是默认index.html,本页面由系统自动生成 本页面在FTP根目录下的index.html 您可以修改、删除或覆盖本页面 FTP相关信息,请到“面板系统后台 > FTP” 查看
Recent posts: 28 Apr 2023 » eBPF Observability Tools Are Not Security Tools 01 Mar 2023 » USENIX SREcon APAC 2022: Computing Performance: What's on the Horizon 17 Feb 2023 » USENIX SREcon APAC 2023: CFP 02 May 2022 » Brendan@Intel.com 15 Apr 2022 » Netflix End of Series 1 09 Apr 2022 » TensorFlow Library Performance 19 Mar 2022 » Why Don't You Use ... 26 Sep 2021 » The Speed of Time 06 Sep 2021 »
はじめに Xcode 6 でユニットテストのようにパフォーマンスをテストする機能が追加されました。 これによって重そうなロジックにパフォーマンスの測定を設定しておき常に計測することができます。 例えば、画像や動画、音声など圧縮データのエンコード/デコード処理、大量のデータをソートする処理、暗号化する処理などが、ざっと思いつく重い処理です。 今回はサンプルとしてログ出力で追加されたprintlnとNSLogのパフォーマンスを比較してみます。 測定してみる パフォーマンスの測定はユニットテストと同じように扱われますが、Assertがある訳ではなくself.measureBlock()の中で呼び出されたコードが計測対象になります。 新規にプロジェクトを作成するとTestクラスが作成されますが、そこにもself.measureBlock()が作成されるようになりました。 今回必要なソース テストさ
My talk for BayLISA, Oct 2013, launching the Systems Performance book. Operating system performance analysis and tuning leads to a better end-user experience and lower costs, especially for cloud computing environments that pay by the operating system instance. This book covers concepts, strategy, tools and tuning for Unix operating systems, with a focus on Linux- and Solaris-based systems. The bo
昨年末からずっとこんなことをしてまして、この時期になってようやく今年初のブログ記事です。 進捗的なアレがアレでごめんなさい。そろそろ3年目に突入の @pandax381です。 RTT > 100ms との戦い 経緯はこのへんとか見ていただけるとわかりますが「日本と海外の間を結ぶ長距離ネットワーク(いわゆるLong Fat pipe Network)において、通信時間を削減するにはどうしたらいいか?」ということを、昨年末くらいからずっとアレコレやっていました。 送信したパケットが相手に到達するまでの時間(伝送遅延)を削減するのは、光ファイバーの効率の研究とかしないと物理的に無理なので、ここで言う通信時間とは「TCP通信」における一連の通信を完了するまでの時間です。 伝送遅延については、日本国内のホスト同士であれば、RTT(往復遅延時間)はだいたい10〜30ms程度ですが、日本・北米間だと10
まずそもそもKPIってなんやねん、と。 Key Performance Indicator 業績管理評価のための重要な指標 KPIとは【Key Performance Indicator】(重要業績評価指標) - 意味/解説/説明/定義 : IT用語辞典 用語的な意味はこんなとこですが、ここではざっくり「DB性能評価指標」と考えてください。 うちの会社では定常的にMySQLから情報を吸いあげて、これを蓄積しつつ性能管理に役立てています。 これをDB KPI管理なんて呼んでいます。 著作権が怪しいのでソースを載せるのは控えますが、延々とshow statusの60秒間の平均を取るスクリプトをdaemontoolsで回し続けています。 取得対象はCom_[insert|delete|update|select]、Innodb_rows_% (うちはInnoDBばかりなので) あたりです。 累積
最近うぇぶ業界では、開発効率や構築効率を求める動きが活発のように見受けられますが、ここで改善効率について手を伸ばしてみましょう。 改善効率とは、開発後期やサービス開始後の運用フェーズにおいて、クソコードやクソクエリ、データの蓄積によるレスポンスの悪化などを、自動的に検知し、開発者にオラオラ改修をプッシュするための仕組みのことでございます。 はじめに ここで紹介する内容はドリコムで実際に運用しているものですが、別にドヤ顔するようなものではなく、中規模以上の企業ならば似たようなことやそれ以上のことをやっているであろう、至極当然な内容です。それでも、それなりに種類が増えてきたことと、それなりの効果を得られていることが実感できているため、いったんまとめてみようと思った次第です。 ウチのサービスのサーバーサイドは Ruby on Rails + MySQL が基本なので、その対策手法になります。WE
SSDはNANDフラッシュメモリの上書きができないという特性上、空き領域が少なくなると性能が落ちてくるし、以下略*1なわけですが、Trimコマンドで論理的に削除された領域をSSDに伝えることで性能の劣化を抑制する効果が期待できる。 ext4ファイルシステムでTrimコマンドを有効にするには、discardオプションをマウント時に指定するとよいです。 sudo mount -t ext4 -o discard /dev/sdb1 /mntこれでめでたしめでたしと思いきや、ext3からext4にするとなんかえらい書き込み性能が落ちてて、これはどうやらext4ではデフォルトでライトバリアが有効になってるのが要因ぽいので、ext3だったころとおなじ感じで使うにはライトバリアを無効にする必要があります。 sudo mount -t ext4 -o discard,barrier=0 /dev/sdb
1 Copyright 2009 Sun Microsystems inc The World’s Most Popular Open Source Database MySQLのパフォーマンスチューニングと よくある落とし穴 松信 嘉範 (MATSUNOBU Yoshinori) Principal MySQL Consultant, Sun Microsystems yoshinori.matsunobu@gmail.com 2 Copyright 2009 Sun Microsystems inc The World’s Most Popular Open Source Database テーマ • ハードウェア選定、バージョン選定 • ロードなどの更新処理のパフォーマンス改善 – 今日のセッションのメイン • レプリケーション • 全文検索 • その他 3 Copyright 20
« Paper: Tempest: Scalable Time-Critical Web Services Platform | Main | ESPN's Architecture at Scale - Operating at 100,000 Duh Nuh Nuhs Per Second » Authored by Chris Fregly: Former Netflix Streaming Platform Engineer, AWS Certified Solution Architect and Purveyor of fluxcapacitor.com. Ahead of the upcoming 2nd annual re:Invent conference, inspired by Simone Brunozzi’s recent presentation at an
比較的新しいカーネルを採用したLinuxディストリビューションでは、ファイルシステムのI/Oバリア (I/O barrier)機能がデフォルトで有効になっています。例えばRedhat Enterprise Linux (RHEL) 6やSUSE Linux Enterprise Server (SLES) 11等はインストール直後の状態でext4ファイルシステムのI/Oバリアが有効になっているようです。 I/Oバリアは簡単にいうと、「バリア命令」の後で発行されたI/Oは、バリア命令の前に発行されたI/Oの後に必ず実行されるようにする仕組みです。つまりI/Oの順序(物理ディスクに反映される順番)をまもらせる仕組みといえます。 ファイルシステムにI/Oバリア機能が追加されたのは、ファイルシステムが不整合な状態になる可能性を減らすためです。 そもそも、急な電源断でもファイルシステムの不整合が起こ
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
by Wander Boessenkool (Red Hat) Tuning systems can be a time consuming art. Not only does it involve extensive profiling of your systems, as well as continuous monitoring, but keeping tuning setting applied continuously can be quite a chore as well. Especially if the tuning needs of your systems change throughout the day. Imagine a database system that is used to process orders from customers. In
At MySQL Connect 2013, I talked about how we used MySQL 5.6 at Facebook, and explained some of new features we added to our Facebook MySQL 5.6 source tree. In this post, I'm going to talk about how we made full table scan faster in InnoDB. Faster full table scan in InnoDB In general, almost all queries from applications are using indexes, and reading very few rows (0..1 on primary key lookups and
PhantomJS is a headless WebKit with JavaScript API. YSlow for PhantomJS is a command line script that allows page performance analysis from live URLs, unlike YSlow for Command Line (HAR) where a pre-generated HAR file is needed in order to analyze page performance. YSlow for PhantomJS also introduces new output formats for automated test frameworks: TAP (Test Anything Protocol) and JUnit, other fo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く