Railsのパフォーマンスについてよくある問題とそれに対して戦いを挑むために必要なもの。
![Railsパフォーマンス基本のキ](https://cdn-ak-scissors.b.st-hatena.com/image/square/da63ee0936faa1c4f266d01bead98ce6f0dd2609/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F5c6d3549a22848fb9fbc41a8336539d7%2Fslide_0.jpg%3F5034174)
Railsのパフォーマンスについてよくある問題とそれに対して戦いを挑むために必要なもの。
あらすじ Web技術が複雑になる中で、JavaScriptのプロファイリングをとる方法とは。 プロファイリングを取るためのコードを手で書いてみましょう。 とてもシンプルで、かつ最高のJavaScriptプロファイラ sjsp を作りました。 本当にあった怖い話 上司 「とにかくJavaScriptのコードを速くしてくれ」 私 「分かりました、速くします」 (次の日) 私 「いいプロファイラがないなら作ればいいじゃない」 同じチームの人 「えっ?」 私 「最高のJavaScriptプロファイラ作ったよ」 同じチームの人 「「えっえっ???」」 私 「早速使ってみたらこことここが遅いって分かったよ」 同じチームの人 「「「この子は一体…」」」 JavaScriptのプロファイリングの難しさ 近年、Webブラウザーの処理速度は著しく向上し、その可用性の高さから、アプリケーションのプラットフォーム
NGINX is well known as a high‑performance load balancer, cache, and web server, powering over 40% of the busiest websites in the world. For most use cases, default NGINX and Linux settings work well, but achieving optimal performance sometimes requires a bit of tuning. This blog post discusses some of the NGINX and Linux settings to consider when tuning a system. You can tune almost any setting, b
Effectively managing memory at Gmail scale Stay organized with collections Save and categorize content based on your preferences. 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 me
最近のPlackとStarletにはパフォーマンス改善のため次のような変更が加えられています。 Plackに対する変更 (カッコ内はバージョン) Plack::Request::query_parameters の最適化 (1.0018) Plack::Middleware::AccessLog に Apache::LogFormat::Compilerの導入 (1.0023) Starletに対する変更 local $SIG{..} を無くし、rt_sig* system call が呼ばれる回数を削減 (0.17_01) headerとbodyを結合して一度に出力する閾値を1024から8192に変更 (0.18) ベンチマーク これらの変更の効果を確認するために、次のベンチマークを実行してみます まずアプリケーションはこんな感じ use Plack::Builder; use Plac
jsPerf — JavaScript performance playground What is jsPerf? jsPerf aims to provide an easy way to create and share test cases, comparing the performance of different JavaScript snippets by running benchmarks. For more information, see the FAQ. Create a test case Login with GitHub to Create Test Cases
概要 Linuxのパフォーマンス解析ツールであるperfの使いかたの紹介 背景 個人的にperfよくできてると思うので紹介したいというのと、 パフォーマンスカウンタの読み方ってあんまり知られてないみたいなので、 それの解説を書きたい。 構成 perf について説明したあと、パフォーマンスカウンタの読みかた、見かた、を説明する。 perfとは何か Linuxに付いてくるプロファイラ。 man perf によると、 NAME ---- perf - Performance analysis tools for Linux と、書いてある。名前がひどいのでなんとかしてほしい。 perf の特徴 個人的には、手軽に使えるのが素晴らしいと思う。 2.6.31以降カーネルに標準で付いてる。(Ubuntuだとlinux-tools-common(TODO:あとで確認)で入るはず) 特殊な設定が必要無く、
「なんでもありの」といううたい文句の通りに楽しめたチューニング大会#isucon に参加してきました。 livedoor Tech ブログ : なんでもありの Web アプリケーション高速化バトル、#isucon 開催のお知らせ 最初は参加するつもり無かったんですが、知ってる方がかなり参加されそうだったのと、MySQL Casual の帰りに@kamipo さんが 「3 人チームで#isucon に申し込んだけど、『kamipo』『未定』『未定』やねん!」 と悲しそうにしていたので、kamipo さんと 2 人チームで参加させて頂くことになりました。kamipo さんホントありがとう!!ちなみにチーム名はふたりとも大好きな「チームやすべえ」 あんま大したことができなかったし、藤原組とかいうや ◯ ざなチームが圧倒的な強さを見せたりしていたので、真面目な話はそちらにお譲りします! #isuc
We’ve made the very difficult decision to cancel all future O’Reilly in-person conferences. Instead, we’ll continue to invest in and grow O’Reilly online learning, supporting the 5,000 companies and 2.5 million people who count on our experts to help them stay ahead in all facets of business and technology. Come join them and learn what they already know. Become an O’Reilly online learning member
こんにちは。システム本部技術部たんぽぽGの森本です 先日のmixi大規模障害についてのブログです。 はじめにお断りしておきますが、弊社CTOがtwitterで公開した以上の情報はまだ得られておりません。 twitterでは書ききれなかった細部を補足してみたいと思います 現状判明しているのは以下の点です memcachedに大量の接続・切断を行うとmemcachedプロセスが突然終了することがある memcachedには異常時に終了するフローもあるが、同時に出力されるはずのエラーログは出ていなかった coreも出力されていなかった テスト環境にて追試を行ったところ、なんどか再現させることができましたが、確実に発生する条件は未だ不明です。 障害時の memcachedのバージョンは1.4.4, libeventのバージョンは1.3bです memcached の起動オプションは以下のとおり ./
The Terracotta Server provides powerful distributed in-memory data management capabilities for Terracotta products (such as Ehcache and TCStore) and is the backbone for Terracotta clusters. A Terracotta Server Array can vary from a basic two-node tandem to a multi-node array (Terracotta Server Array (TSA)) providing configurable scale, high performance, and deep failover coverage. Add distributed
ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1~5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture
speed/validity selectors test for frameworks. Every framework runs in his own iFrame, thus no conflicts can happen. Tests are run selector by selector, with an interval to prevent the browser from freeezing. Tests are run in a neutral environment, no library or framework is included in the main javascript test, to avoid favoritism. Tests are run against a local copy of this document. beta' src='s
アメリカ時間の昼ごろにTwitter上が一つのニュースで埋め尽くされました。 PHPをC++に変換して高速化する技術をFacebookが公開したというものです。世界中のPHPハッカーが注目する興味深いリリースという事でちょっと長いですが、リリースノートの和訳を行いました。 原文 http://developers.facebook.com/news.php?blog=1&story=358 Facebookにおいて重要なことのひとつが動作の速さです。過去6年間にわたって、PHPが提供する高速な開発ペースによって多くを成し遂げてきました。プログラミング言語としてみると、PHPはシンプルです。簡単に習得し、簡単に書き、簡単に読み、簡単にデバッグする事ができます。我々は他の言語よりも早くエンジニアを獲得し、それによってより早いイノベーションをすることができます。 今日、私は2年に渡って作業して
NTT Tech Conference 2022 での「Dockerからcontainerdへの移行」の発表資料です https://ntt-techconf.connpass.com/event/241061/ 訂正: P2. . 誤: ``` Ship docker run -it --rm alpine Run docker push ghcr.io/ktock/myalpine:latest ``` 正: ``` Ship docker push ghcr.io/ktock/myalpine:latest Run docker run -it --rm alpine ``` 最近勉強を始めたコンテナ技術に関する基礎的な知識をまとめました。 [訂正と注釈] p.27-30: 「Deployment」内の「Version: 1」 => 「Version: 2」 p.37: 「終了コード
Twitterを利用していると、ときどきクジラの絵の画面が表示されることがあります。これはTwitterの処理能力がパンクして一時的に利用不可になったときに表示されるお馴染みの画面。 2月9日にTwitter Engineeringブログにポストされたエントリ「The Anatomy of a Whale」(クジラの解剖学)では、Twitterのエンジニアたちがこのクジラの内部に分け入ってどのようにTwitterサーバの処理能力を向上させたのか、という話が詳しく語られています。 彼らが行ったのは、まず詳細なデータを取得して原因がどの辺にあるのかを推測すること。そこから多数の無駄な処理を発見し、ソースコードの修正による性能の向上に成功します。 元記事は非常に長いエントリになっていますが、問題の調査から解決に至るアプローチについて多くのエンジニアの方の参考になりそうな内容が含まれていますし、T
Facebookが大規模スケーラビリティへの挑戦で学んだこと(後編)~キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性 全世界で3億人を超える会員を抱え、世界最大のSNSとなったFacebook。同社の技術担当バイスプレジデント Jeff Rothschild氏が、10月8日に米カリフォルニア大学サンディエゴ校で行ったセミナー「High Performance at Massive Scale-Lessons learned at Facebook」の内容を再構成して紹介します。 (この記事は「Facebookが大規模なスケーラビリティへの挑戦で学んだこと(前編)~800億枚の写真データとPHPのスケーラビリティ問題」の続きです) キャッシュがスケーラビリティに大きな役割を果たしている Facebookの主な役割は、ユーザーが簡単に(友人たちの)情報を集めることがで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く