This article was adapted from my Rails World talk “Rails and the Ruby Garbage Collector: How to Speed Up Your Rails App”. Ruby’s garbage collector is designed to be adaptable, scaling from short Ruby scripts to running apps that serve millions of requests per second. While it’s designed to be adaptable, it may not work optimally for every use case. For this reason, Ruby’s garbage collector support
Ruby 3.3がリリースされた。YJITには非常に多くの改善が含まれたリリースだったが、 NEWS解説記事やリリースパーティーでは 2点しか触れられなかったので、この記事ではRuby 3.3でYJITがどう改善されたかについて解説する。 YJITは既に実用段階 YJITはRuby 3.1で導入されたが、Ruby 3.2の時点でexperimentalのマークが外れ、実用段階となった。 Ruby 3.2では、以下のような企業で性能改善が報告された。 DeNA: 40% 高速化 GMOペバボ: 18% 高速化 STORES: 6.5-7.5% 高速化 Timee: 10% 高速化 メドピア: 2.8% 高速化 BOOK☆WALKER: 20-30% 高速化 Discourse: 15.8-19.6% 高速化 Lobsters: 26% 高速化 CompanyCam: 20-40% 高速化 弊
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
この記事は Akatsuki Advent Calendar 2019 1日目の記事です。 はじめに アカツキでは Ruby on Rails を使ったゲームサーバを開発・運用しています。ゲームの体験を向上するために、レスポンスタイムは一つの重要な要素となるため、種々のパフォーマンスチューニングを行なっています。今回はその一例として、環境変数を1つ設定するだけで、あるAPIのレスポンスタイムが10%も改善した例をご紹介します。 TL;DR 多数の時刻を含むレコードを扱う Ruby on Rails サーバでは、 TZ 環境変数を設定することで、デフォルトタイムゾーン設定ファイル /etc/localtime へのアクセスが減り、高速化が図れるかもしれません。 効果は Time オブジェクト1個あたり数μsの短縮といったオーダーですが、チリも積もれば山となり、数千個のレコードを処理するAPI
はじめに Rails のログファイルに CACHE (0.0ms) という行が出力されることがある。 CACHE (0.0ms) SELECT `users`.* FROM `users` WHERE `users`.`id` = '1321459' LIMIT 1 [["id", "1321459"]] ここから以下のことがわかる。 このリクエストでこのクエリが発行されるのは2回目またそれ以上である 結果をキャッシュから返したのでDBには問い合わせていない クエリキャッシュ この仕組みはクエリキャッシュというもので、Rails 2.0 で導入された(らしい。よく知らない)。 Rails ガイドだと Caching with Rails: An overview — Ruby on Rails Guides に記載されている。 1.5 SQL Caching Query caching i
https://speakerdeck.com/k0kubun/number-ginzarb の資料作成のためのnewrelic_rpmのコードリーディングメモ。バージョンはv4.3.0。 Railtie→Agent#start まで require 'newrelic_rpm'でRailtieが作られる まずRailsの場合、普通にGemfileにgem 'newrelic_rpm'を書くと、Bundler.requireされた時にNewRelic::Railtieが定義される。 if Rails::VERSION::MAJOR.to_i >= 3 module NewRelic class Railtie < Rails::Railtie initializer "newrelic_rpm.start_plugin" do |app| NewRelic::Control.instanc
はじめに テストを書くことは、特にRubyやRailsのコミュニティにおいて開発の重要なプロセスですが、テストの完了に長時間を要するようにならないと、テストスイートのパフォーマンスを気にしない傾向があります。身に覚えがありませんか？ 専用のテストプロファイラであるTestProfを用いて、Railsテストのパフォーマンスボトルネックを特定して修正する方法を学びましょう。 私はEvil Martiansに入社した最初の年から、さまざまなタイプのRailsアプリケーション（モノリス、モジュリス（モジュラー+モノリス）、APIのみ、Hotwireなど）に取り組んできました。これらのアプリケーションは、どれもテストスイートの速度面に改善の余地がまだまだ残されていました。 私はテスト高速化のヒントやノウハウを集めるようになり、最終的にそのノウハウをすべてTestProfという名のメタgemに盛り込み
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
