Chrome 55 uses ~30% less memory than Chrome 54
Chrome 55 uses ~30% less memory than Chrome 54 We use headless Chrome to drive our service so we were very interested in the alleged memory improvements of Chrome 55 reported 2 months ago. Weather.com was the first site to crash our service due to a 300MB memory cap we had on a Docker container. Weather.comChrome 54Chrome 55Memory reduction Chrome task manager
Linux Performance
static, benchmarking, tuning: sar, perf-tools, bcc/BPF: bpftrace, BPF book: Images license: creative commons Attribution-ShareAlike 4.0. This page links to various Linux performance material I've created, including the tools maps on the right. These use a large font size to suit slide decks. You can also print them out for your office wall. They show: Linux observability tools, Linux static perfor
開発環境のパフォーマンスチューニング - クックパッド開発者ブログ
こんにちは。技術部の吉川です。 クックパッドでは、ユーザーが快適にサービスを利用できるように本番環境でのパフォーマンスを向上させるための様々な工夫がなされています。 ところでパフォーマンスを気にするのは本番環境だけで良いのでしょうか？ 開発環境に目を向けると、そこにもユーザーがいます。開発者です。開発環境のパフォーマンスが向上することで、開発者が快適にサービスを開発できるようになります。 今回はそういった開発環境でのパフォーマンス向上のための取り組みについてご紹介します。 ※ なお先日 Ruby2.2化されました が、今回紹介するものはそれ以前に実施されたため、Ruby2.2で同じ結果になるとは限りません。 状況 今回対象とするのはcookpad.comのアプリケーションです。 近年はMicroservices化を進めていますが、それでも本体のレシピサービスのアプリケーションは依然として非
ISUCON5予選を全体1位で通過しました - 酒日記 はてな支店
ISUCON5 の予選1日目にチーム「fujiwara組」(@fujiwara, @songmu, @sugyan) として参加して、全体通して1位のスコアで通過しました。 isucon.net 今回は ISUCON 1 の時の優勝チームを再結成という形になったわけですが、最初はISUCON 4の時と同じ社内のチームででようかと思ってたんですよね。ところが昨年優勝チームだった「LINE選抜 生ハム原木」が今回参戦できないということで、sugyanがチームどうしよう、と困っていたのでつい…*1 初代fujiwara組を再結成しよう— fujiwara (@fujiwara) 2015, 5月 27 準備 今回はOSは Ubuntu(バージョン非公開)なのが事前にレギュレーションで公開されていたので(前年まではCentOS, Amazon LinuxなどのRedHat系ディストリビューションで
Railsアプリを66％スピードアップ ― Railsキャッシュの完全ガイド | POSTD
(訳注：2016/3/2、頂いた翻訳フィードバックをもとに記事を修正いたしました。) Railsアプリでのキャッシングは、「たまに夕食を一緒にするけれど、本当はもっと頻繁に一緒にいるべき友達」に少し似ています。パフォーマンスをまじめに考えるRailsアプリのほぼ全てで、もっとキャッシングを使えるはずですが、ほとんどのRailsアプリでは、完全にキャッシングを避けています。それでも普通は、Railsで高速なサーバ応答を達成するための唯一の道は、キャッシングの知的な利用なのです。約250msの応答時間を、簡単に50～100msに高速化できます。 定義についての注意 ― この記事は、アプリケーション層のキャッシングのみを対象としています。HTTPキャッシング（これは全く別の難物で、あなたのアプリケーションに実装する必要はありません）は、別の機会で扱いましょう。 するべきキャッシングをしない理由
はてなで大規模サービスのインフラを学んだ - ゆううきブログ
中〜大規模サービスのインフラの様子を知りたいアプリケーションエンジニア向けに、もともとアプリケーションコードを書いていた視点から、個人的な体験をベースにはてなで大規模サービスのインフラを学んだ過程や学んだ内容の一部を紹介します。 Webアプリケーションのブラックボックス Webアプリケーションフレームワークの向こう側 なぜ複数のサーバが必要なのか 突然のWebサービス3層構成 リバースプロキシ アプリケーション データベース その他のコンポーネント キャッシュは麻薬 飛び道具としてのKVS/NoSQL 非同期処理 バッチ処理 Mackerelの場合 参考 まとめ Webアプリケーションのブラックボックス 今年もはてなインターンの時期が近づいてきた。 毎年ではないけど、はてなインターンでは「インフラ講義」というのをやっている。 今年はインフラ講義の講師としてアサインされたのでちょうど何を話そ
とあるサイトの高速化についてフロントエンドでやったことまとめ。 - Toro_Unit
業務で携わっている案件なのですが、アクセス数の急増が見込まれるイベントがありまして。準備期間も少なく、バックエンド側でできることがほぼないという状況でサイトを落とさないようにがんばる！というお仕事でした。レガシーソースてんこ盛り。CSSプリプロセッサとか何それ状態。 そこで実施した対策のまとめです。サーバー・アプリケーション・サイトの構成によって、効果の大小はありますが、比較的効果があったと思われるものをつらつらと。 リクエストの削減とファイルサイズの最適化 まず一番最初に考えなければいけないのがリクエスト数です。すごいおおざっぱに言うと、WEBサーバー（ApacheとかNginxとか）への負荷は、PV数×リクエスト数です。PVがそんなに無くてもそのページのリクエストがめちゃくちゃ多いとそれだけでかなりの負荷になります。リクエストを半分にできれば2倍の人数がさばけるってことに、すげーおおざ
ISUCONでNginxとMySQLをDocker化したときのパフォーマンス - ゆううきブログ
現実的なWebサービス環境において、Docker化によるパフォーマンス低下がどの程度のものか調査するために、 ISUCON4 の予選問題のうち、Nginx と MySQL 部分を Docker 化してベンチマークをとってみた。 典型的なWebサービスシステムの3層構造（Proxy, App, DB）を構築し、ベンチマーカーにより高ワークロードを実現できるので、ISUCON の予選問題は適当な題材といえる。 Docker のパフォーマンスについて留意することは先日書いたエントリに全て書いてる。 上記のエントリを要約すると、Docker のパフォーマンスについて重要なこととは storage-driver の選択 (AUFS or Device mapper or ...) Volume の ON / OFF AUFS などの差分ファイルシステムをバイパスするかしないか Host networ
How We Made GitHub Fast
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
ハイパフォーマンス ブラウザネットワーキング、読むべき本だった - terurouメモ
Twitterで「なんかやばそうな本が出るぞ！！！」みたいな事を言っていたら、それが偶然拾われて、献本して頂く流れになりました。オライリーさん、ありがとうございます。 とりあえずざっと全体を流し読みした（と言っても3時間弱は読んだ）ので、書評っぽいことを書いておく。 ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化posted with amazlet at 14.05.10Ilya Grigorik オライリージャパン 売り上げランキング: 4,747 Amazon.co.jpで詳細を見る 読むべき人間 以下に該当する人間に対しては必読に値する本だと思う。 HTTPを扱うアプリケーション*1のアーキテクチャを設計する人間 Webサーバ等のHTTPに関連するインフラを担当する人間 HTTP 2.0、WebSocket、Server-S
ORDER BY狙いのキーが何故速いか - 時計を壊せ
どの最適化が効くんや…とググった。 以前も調べた気がしたが思いだせず、ひたすらググる羽目になったので、 反省してブログに残す。ふつーにmysqlのdocumentに書いてあった。 http://dev.mysql.com/doc/refman/5.7/en/limit-optimization.html If you use LIMIT row_count with ORDER BY, MySQL ends the sorting as soon as it has found the first row_count rows of the sorted result, rather than sorting the entire result. If ordering is done by using an index, this is very fast. バージョン古いけど日本語のほ
はてなブログにおけるページ表示速度改善の取り組みについて - Hatena Developer Blog
こんにちは、id:hakobe932です。はてなブログではユーザ体験の改善のために、ページ表示速度を向上させるための様々な取り組みを行っています。このエントリーでは、はてなブログで行っている、ブラウザキャッシュの活用、JavaScriptのページ最下部での読み込み、JavaScriptの圧縮、という3つの取り組みについて解説します。 ブラウザキャッシュの活用 同じ内容のJavaScriptやCSSを、ページを表示するたびにダウンロードすると、余分なHTTPリクエストが発生しますし、読み込み時間がかかります。 ブラウザのキャッシュを利用できれば、余分なリクエストを減らすことができます。はてなブログでは、なるべく長い間ブラウザにキャッシュを保存するために、JavaScriptなどの一部の種類のファイルのレスポンスに、以下のようなヘッダを指定しています。 $ curl -I http://hat
Ruby on Rails/Ajaxのパフォーマンスをあげる5つの方法の部分的超訳メモ
Vitamin Features >> 5 Ways to Optimize AJAX in Ruby on Rails http://www.thinkvitamin.com/features/ajax/5-ways-to-optimize-ajax-in-ruby-on-rails の部分的超訳メモ Ruby on Rails/Ajaxアプリの5つの最適化。 データベースのインデックスの最適化 冗長なSQLクエリを除く レスポンスの圧縮、極小化 フラグメントキャッシュ レンダリング前のクライアントサイドのJavaScriptキャッシュ データベースのインデックスの最適化 † QueryTrace pluginをインストールすると、次のようなログがlog/development.logに残る。 Conversation Load (0.001538) SELECT * FROM conv
無料パフォーマンステスト | 負荷テスト
これまで、負荷テストの実行には専門知識と実行環境の準備に多くのコストが必要でした。社会からWebサービスの性能に関する不具合をゼロにするために、簡単、無料、圧倒的な負荷テストサービスを提供します。 ユーザビリティ サーバの応答速度は常に変化し、利用者の直帰率に大きく影響を与えます。サーバの応答速度を可視化し、日々計測することで、すみやかに問題個所を発見できます。 性能測定 サーバの性能不足により、せっかくの営業機会を失うサイトが多く存在します。サーバの性能を正しく把握することで、予測される負荷に応じたサーバの増強ができます。 負荷チェッカー／カレンダーを利用したテスト（ジョブ）の予約や、グラフィカルな結果画面を準備しており、初心者の方にも大変使いやすいサービス。インスタントテスト／URLを入力するだけで、すぐに負荷テストを行うことができます。シナリオテスト／ログインが必要なページや複数のペ
Effectively managing memory at Gmail scale | Articles | web.dev
Introduction While JavaScript employs garbage collection for automatic memory management, it is not a substitute for effective memory management in applications. JavaScript applications suffer from the same memory related problems that native applications do, such as memory leaks and bloat, yet they must also deal with garbage collection pauses. Large-scale applications like Gmail encounter the sa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rails高速化戦略 / Speeding Up Rails
ヤフー社内でやってるMySQLチューニングセミナー大公開
Javaトラブルに備えよう #jjug_ccc #ccc_h2
Ruby on Rails on MySQL チューニング入門
サーバー未経験者がソーシャルゲームを通して知ったサーバーの事
