タグ

パフォーマンスに関するitpcfgのブックマーク (4)

  • Lighthouseを使ってVuex.jsで書いたポートフォリオサイトを爆速化する - Kekeの日記

    記事はVue.js Advent Calendar 2018の第3日目の記事です。 はじめに GCPの無料枠が終了したため、ポートフォリオサイトはクローズドしましたが、引き続き記事はご覧いただけます。 私は以前、インターンシップなどの選考に備えて自分のポートフォリオサイトなるものを作りました。 しかし、あまりに速くデプロイしたかったことからパフォーマンスについて一切無視した結果、とてつもなく遅いサイトができてしまいました。 結局、他人に見せるには恥ずかしいサイトになってしまい、今回の記事で爆速にできればと思います。 サイトはこちらで、SEO対策OGPも実装したので以下のように展開されます。 要約 自分のポートフォリオサイトがロードまで8秒近くかかっていたのがキャッシュ込みで0.3秒くらいになった クリティカルレンダリングパスを知ることが重要 Chrome DevToolを使い倒すとよ

    Lighthouseを使ってVuex.jsで書いたポートフォリオサイトを爆速化する - Kekeの日記
  • AWS X-Ray による ISUCON8 本選問題の解析 - 酒日記 はてな支店

    ISUCON8 の選問題は、競技者がコントロールできない外部 API 呼び出しを多数含んだ出題内容でした。 講評では、 サービスの特性を適切に分析した上で、まとめるところはまとめたり、遅延させるところは遅延させるなど ……とさらっと書かれていますが、実際そんなことを短時間で分析することは可能なのかよ!という話題が競技後の懇親会でもあったので、それ AWS X-Ray でできるよ、というエントリをまとめておきたいと思います。 今回の解析は Perl 版の初期実装に対して行ったものですが、なぜ Perl かというと AWS の公式 SDK にない X-Ray 関連の CPAN モジュールを自分が書いているので、その宣伝も兼ねています。(blogエントリ書いてなかった) AWS::XRay Plack::Middleware::XRay Devel::KYTProf::Logger::XRay

    AWS X-Ray による ISUCON8 本選問題の解析 - 酒日記 はてな支店
  • Dockerコンテナが遅くなるもう一つの原因 | POSTD

    前回の ブログ記事 では、Kubernetesの話と、 ThoughtSpot がKubernetesを開発インフラのニーズに合わせてどのように取り入れたかをご紹介しました。今回はその続報として、最近の興味深いデバッグ経験について少々駆け足になりますがお話ししていきます。記事も「コンテナ化と仮想化はノットイコールである」という事実に基づいており、たとえcgroupの上限がどれも高くない値に設定されホストマシンで十分な演算能力が利用できるとしても、コンテナ化されたプロセス同士がリソースの競合を起こす場合があることを示したいと思います。 ThoughtSpotでは内部のKubernetesクラスタで 多数のCI/CDや開発関連のワークフロー を稼働させており、ある1点を除いては全てが順調でした。唯一問題だったのは、ドッカー化された製品コピーを起動すると、パフォーマンスが期待を極端に下回るレベ

    Dockerコンテナが遅くなるもう一つの原因 | POSTD
  • いまさら聞けないLinuxとメモリの基礎&vmstatの詳しい使い方 - Qiita

    さくらインターネット Advent Calendar最終日は、硬派にLinuxのメモリに関する基礎知識についてみてみたいと思います。 最近はサーバーを意識せずプログラミングできるようになり、メモリの空き容量について意識することも少なくなりましたが、いざ低レイヤーに触れなければいけないシチュエーションになった際に、OSを目の前に呆然とする人が多いようです。 基的にLinux のパフォーマンスについて、メモリをたくさんつめばいいとか、スワップさせないほうが良い とか、このあたりは良く知られたことだと思います。 ただ、なんとなく ps コマンドや free コマンド などの結果を見るだけでなく、もう少しメモリのことについて掘り下げてみてみたいと思います。 メモリとキャッシュ Linux におけるメモリの状態を大きく分けると「使用中のメモリ」「キャッシュ」「空きメモリ」「スワップ」の 4 つに分

    いまさら聞けないLinuxとメモリの基礎&vmstatの詳しい使い方 - Qiita
  • 1