HTML5 Conference 11/25
光を超えるためのフロントエンドアーキテクチャ - Speaker Deck
HTML5 Conference 11/25
Ruby memory, ActiveRecord and Draper
At Appaloosa we often process CSV. When we process thousands of CSV lines of users that need to be added to (or removed from) a group, we are seeing a huge increase in memory. Sometimes the Heroku dynos cannot manage it. We will explain how we jump from this when processing 4_000 users (look at blue line but also time): memory profilerWe used stackprof, memory_profiler. We look at tool like speeds
どのようにしてデータベース負荷を80%削減するのか - Frasco
これまでWebアプリのクエリパフォーマンスを最適化してきましたが、それでもクエリ時間が15秒以上のランダムなスパイクが発生していました。そこでデータベースクエリのチューニングを始めました。まず、インデックス および Rack Mini Profiler を使用してホームページを高速化。それから高負荷なクエリを追跡して除去しました。 その結果、平均応答時間は約50ms、perc95は1秒未満と大幅に改善させることができました。しかし、まだ厄介な問題が残っていました。24時間のうちに、perc95の応答時間は15秒または30秒になり、短時間のタイムアウトが始まるのです。この記事では、これらの問題箇所を見つけて解決し、データベース負荷を80％削減させた方法を紹介します。 スパイクが発生したときの、ダッシュボード画面はこのようになります。 この一連のリクエストが非常に遅い理由を調べるために、メトリ
A Netflix Web Performance Case Study – Dev Channel – Medium
tl;dr: There are no silver bullets to web performance. Simple static pages benefit from being server-rendered with minimal JavaScript. Libraries can provide great value for complex pages when used with care. Netflix is one of the most popular video streaming services. Since launching globally in 2016, the company has found that many new users are not only signing up on mobile devices but are also
全世界からTypetalkを爆速で使える！キャッシュしないCDNによるAPI高速化 | ヌーラボ
Typetalkチームのインフラ担当の二橋 (@futahashi) です。 本稿ではTypetalkでキャッシュしないCDNを用いたAPI高速化を実現しましたので、その技術を紹介したいと思います。 Webアプリケーションに汎用的に使える技術で、簡単に導入できて改善効果も大きいので、興味を持たれた方は是非試してみて下さい！ Typetalkが抱えてた課題 Typetalk は世界中にサービス展開しているチャットツールです。 しかし、ユーザがサービスを利用する地域に依存してネットワークの応答時間に差がある問題がありました。 これは、サービスを単一のリージョンで提供しており、リージョンから離れた地域よりアクセスされると応答に時間がかかってしまうためです。 静的なコンテンツ部分はCDNによるキャッシュで高速化できていたのですが、動的な部分は対応ができていなかったため、応答に時間がかかっていました
Webアプリケーションのベンチマークをとるときに気をつけている10のこと - たごもりすメモ
10もないかも、と思いながら項目を書き出してみたら10以上余裕であってキリがないので10で収めた。いやあ、あるなあ。 仕事柄よくベンチマークを実行したりしてて色々と思うところが溜まっていたところ、以下のような記事を見掛けたのでなんか書こうと思った。ところでこの記事はベンチマークを実行するための準備作業がループを回して2時間かかるところの待ち時間に書かれている。 sfujiwara.hatenablog.com ISUCONといえば多少縁があるコンテストで、文中でISUCON5のことについても言及されているので、それも含めて。 自分が業務でいじっているのは "Webアプリケーション" というとちょっと違うんじゃないのというものばかりだが、いやー、最近なんでもHTTPで外部APIを作るからベンチマークのコツとしては大体変わんなかったりするよね。 なおこの記事でベンチマークはどのようなものかとか
Webパフォーマンス虎の巻
Webパフォーマンス向上施策のために、今更ながら超速本1を読んだので、今までの自分の知見と合わせてまとめてみます。 なるべく柔らかく、改善施策ってまず何をどうすればいいの？という疑問を持った人に向けて書いています。 ▪️格言 そもそもWebは速い。遅くしているのは我々です。大抵は技術の問題ではなくて、人の問題。 引用元： テクニックではなく、今、本気で取り組むべきWebパフォーマンス （html5jパフォーマンス部 部長 竹洞さん） 心得 パフォーマンス向上に対する施策は大別すると以下の２通り 軽量化 （単純にやりとりするデータ容量を小さくすること） 圧縮 削除 最適化 （その時に最も適している実装・実行をとること） 経路・順番の変更 非同期 もっとも遅くしている原因を探して、それを対策するのが原則。「対効果」が絶対的正義である。手段から入るのは愚策。まず先に原因を知ることが重要。 ▪️1
[翻訳] たった一つの設定変更が如何にしてクエリのパフォーマンスを50倍も改善したか （How a single PostgreSQL config change improved slow query performance by 50x）
先日、「How a single PostgreSQL config change improved slow query performance by 50x」というPostgreSQLのSSD環境でのチューニングの記事を見つけたのですが、これをTweetしたらRTやLikeを比較的たくさん頂きました。 How a single PostgreSQL config change improved slow query performance by 50x https://amplitude.engineering/how-a-single-postgresql-config-change-improved-slow-query-performance-by-50x-85593b8991b0 How a single PostgreSQL config change improved sl
GitHub - SamSaffron/allocator_bench: bench of various memory allocators
sam@arch allocator_bench % STRESS_THREADS=8 ruby test_all.rb ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux] built-in mem: 186336 duration: 3.422897896 built-in mem (MALLOC_ARENA_MAX=2): 135780 duration: 3.492815563 mimalloc master: 236204 duration: 2.947209624 rpmalloc master: 291428 duration: 2.823917527 tcmalloc 2.0 mem: 142860 duration: 2.796963668 tcmalloc 2.1 mem: 134952 duration:
How we halved our memory consumption in Rails with jemalloc
One of the earliest projects I was involved in at Valiant was investigating ways to optimise performance and memory consumption in our Rails web application. Although I had heard the age-old complaints about Rails applications being slow, bulky and prone to memory bloat, I had yet to come across any practical, easy-to-navigate solutions to these issues. Until we discovered jemalloc. In this blog p
なぜPythonはこんなにも遅いのか？ | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) Pythonは高い人気を誇り、DevOps、データサイエンス、Web開発、セキュリティの分野で使われています。 しかし、速度に関しては高い評価が全くありません。 JavaとC、C++、C#、Pythonの速度を比べるには、どうしたらいいのでしょう？ 答えは、実行するアプリケーションのタイプに大きく左右されます。完璧なベンチマークはありませんが、[手始めに比べる手段](https://algs4.cs.princeton.edu/faq/)としてはThe Computer Language Benchmarks Gameが適しています。 私は10年ほどthe Computer Language Benchmarks Gameを参照していますが、Java、C#、Go、JavaScript、C++などの他言
docker-build-battle?slide=51
Strategien, Taktiken und Muster der Legacy-Ablösung
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SpeedCurve | Website Performance Monitoring
luckyframeworkで驚異的なスループットを出した話 - Speaker Deck
Nicolasさんのツイート: "A brief analysis and comparison of the CSS for Twitter's PWA vs Twitter's legacy desktop website. The difference is dramatic and I'll touch on some reasons why."
GitHub - uknmr/gas-webpagetest
GitHub - ankane/dexter: The automatic indexer for Postgres
Lower memory usage of your Rails app with jemalloc.🍭 | Bubblin Superbooks Official Blog
Ruby Language Metrics (Public Beta) | Heroku Dev Center
GitHub - heroku/barnes: Tell StatsD about request time, GC, objects and more. Latest Rails 4 and Ruby 2.1 support, and ancient Rails 2 and Ruby 1.8 support.