(勤務先に投稿した社内ブログの焼き直しです) ある日同僚から ActiveJob の perform_later で Barbeque にキューした非同期ジョブの起動が遅いと言われた。が、非同期ジョブの使い所について個人的な考えを書いてみることにする。 相談は「非同期ジョブの結果をユーザーに返しているため、高速になって欲しい。現状、最大で数分の時間を要す旨のメッセージを表示している」という内容でした。具体的には {内部 API} が重く、一部の処理を非同期ジョブにしていてユーザー体験の悪化につながっているとのこと。 盲目的に非同期にしても嬉しいことはない 結論としては、非同期にするのであれば丁寧にやれば良いけど、そもそも同期的でよくない? と考えて欲しいと返した。 まず、個人的にはユーザーアクション起因かつユーザーへフィードバックする必要のある処理を非同期ジョブにするのは本当に長時間かかる
新年あけましておめでとうございます。 @rosylilly です。 この前 SRE 養成講座の体験授業配信 をしたんですが、その時にハンズオンの一環で Ruby 製アプリケーションをいじって高速化してみる。という内容を実施しました。 コンセプトとしては、『ちゃんと設定ファイルを書くだけでも高速化する』という感じです。作業としてはアプリケーションをいじらずに、設定だけいじって高速化する、ということなんですが、結局何がどれくらい効くのか、というのを事前に参考値レベルで弾いておかないとぶっつけ本番になっちゃうな、ということで何がどれくらい効くのかを試してからにしようということで、事前に調査したときのベンチテストと何を変えたかの記録になります。 ベンチマークの前準備 今回はほぼ何もしない Sinatra アプリケーションを作って、その性能差から測ります。ということで用意した性能測定用何もしない S
この記事は Akatsuki Advent Calendar 2019 1日目の記事です。 はじめに アカツキでは Ruby on Rails を使ったゲームサーバを開発・運用しています。ゲームの体験を向上するために、レスポンスタイムは一つの重要な要素となるため、種々のパフォーマンスチューニングを行なっています。今回はその一例として、環境変数を1つ設定するだけで、あるAPIのレスポンスタイムが10%も改善した例をご紹介します。 TL;DR 多数の時刻を含むレコードを扱う Ruby on Rails サーバでは、 TZ 環境変数を設定することで、デフォルトタイムゾーン設定ファイル /etc/localtime へのアクセスが減り、高速化が図れるかもしれません。 効果は Time オブジェクト1個あたり数μsの短縮といったオーダーですが、チリも積もれば山となり、数千個のレコードを処理するAPI
smarthr.connpass.com 行ってきました。十数人で各々が好きなところから読み始めて、最後に見所や気づきを喋る流れでした。initializersを読んでいく人やモデル中心に見ていく人など様々。近日中に全員のメモが公開されるとのことですので、そのときはリンク追記します。会場を提供してくださったSmartHRさんありがとうございました。 追記 先週金曜の dev\.to コードリーディング会に参加した皆さんのメモはこちらに公開されてますhttps://t.co/uipqG1pYxu— ぷりんたい (@spacepro_be) 2018年8月13日 追記ここまで 以下は自分のメモ。やはりdev.toと言えば爆速なので、CSSをheadタグに埋め込んでいたり、キャッシュってどうやってんだろうなーといったところを中心に読みました。最後の所感にも書きましたが、爆速サイトをつくるためのイ
Redis を使って応答時間を半分にした話 はじめにはじめまして。 5月にFiNCに入社し、サーバーサイドの Rails エンジニアをやっている亀田と申します。 今回は、Redis を使ってチャットのパフォーマンスを改善した話について書きたいと思います。 チャットで起きていたパフォーマンス問題FiNCアプリにはチャット機能があります。ユーザー同士のコミュニケーションにも使えますし、お得情報の配信やユーザーのサポートなどでも利用しています。 その中で、ユーザーサポートの社内オペレーション用ツールに、（業務に支障が出るレベルではないものの）表示が重いという問題が発生していました。具体的には、対象となるルームのレコードを取得するために数百ミリ秒かかっており、レスポンスを返すまでに合計で1秒前後かかっているという状況でした。 分析をしてみたところ、インデックスを使って対象となるレコードを取得した後
これは何? レスポンスタイムが遅くて辛いけど原因が特定できないときに役立つツールをまとめてみました Rails以外でも使えるものも一緒くたに書いているけど、気にしない! やらないこと それぞれのツール詳細な説明 気が向いたら個別記事を書く 環境 Rails 4.2.* ruby 2.3.* New Relic パフォーマンス監視サービス 運用フェイズ アクション実行時にどの処理にどれだけ時間が掛かったかをメトリクス収集してくれる 参考 newrelic - New Relic の各製品紹介: New Relic ってアプリケーションパフォーマンス監視ツールじゃないの？ - Qiita 以降のツールは基本的には開発、テスト時に使用するやつです rack-mini-profiler パフォーマンス計測ツール(gem) アクション実行時に、ブラウザにレンダリングに掛かった処理の時間を表示してくれ
Goodpatch CTOの id:sadah です。 これはGoodpatch Advent Calendar 2015の25日目のエントリです。 Prottというサービスではパフォーマンスチューニングのために、Railsアプリケーション/フロントエンドの改善、ミドルウェアのバージョンアップ、SPDYやHTTP/2の導入、オンプレミス環境からAWSへの移行などを行ってきました。 今回はその取り組みの一部をご紹介します。 Slides 10月にGoodpatch Engineer Meetupというイベントをやって、Prottのパフォーマンスチューニングについて話した。 Goodpatch Engineer Meetup Vol.1 - connpass イベントの内容はこちらにまとまっている。 Goodpatch Engineer Meetup Vol.1を開催しました | MEMOPA
こんにちは。技術部の吉川です。 クックパッドでは、ユーザーが快適にサービスを利用できるように本番環境でのパフォーマンスを向上させるための様々な工夫がなされています。 ところでパフォーマンスを気にするのは本番環境だけで良いのでしょうか？ 開発環境に目を向けると、そこにもユーザーがいます。開発者です。開発環境のパフォーマンスが向上することで、開発者が快適にサービスを開発できるようになります。 今回はそういった開発環境でのパフォーマンス向上のための取り組みについてご紹介します。 ※ なお先日 Ruby2.2化されました が、今回紹介するものはそれ以前に実施されたため、Ruby2.2で同じ結果になるとは限りません。 状況 今回対象とするのはcookpad.comのアプリケーションです。 近年はMicroservices化を進めていますが、それでも本体のレシピサービスのアプリケーションは依然として非
Railsのパフォーマンスについてよくある問題とそれに対して戦いを挑むために必要なもの。
http://k0kubun.hatenablog.com/entry/2015/03/31/004021 を見て、「faml は slim と同等とか言いながら slim よりずっと遅いじゃん」と思われると悔しいので一応解説しておく。 なお、このエントリは slim 3.0.3 と hamlit 0.4.2 に基いている。 なぜこのベンチマークで faml が遅いのか、結論から言うと、この中で faml だけ自動 html エスケープが有効になっているからだ。 haml はデフォルトでは自動 html エスケープは無効であり、hamlit もそれに倣っている。 slim のベンチマークで用いている slim のビューでは == を使って明示的に html エスケープを無効化している https://github.com/slim-template/slim/blob/v3.0.3/ben
Optimizing Rails for Memory Usage Part 1: Before You Optimize This is part one in a four-part series on optimizing a potentially memory-heavy Rails action without resorting to pagination. The posts in the series are: Part 1: Before You Optimize Part 2: Tuning the GC Part 3: Pluck and Database Laziness Part 4: Lazy JSON Generation and Final Thoughts We recently built an API server for a mobile appl
[rails][refactoring]railsのボトルネック探しツール railsを実装しているときに、N+1問題回避するためにincludeしたり、処理をかき変えたりするが、やるんだったら最小で最大の効果を上げたい。 むしろ意味の無い所のチューニングには時間を費やしたくない。 そんなときにお薦めなツールをQiitaで見つけたのでご紹介 miniprofiler 各ページ表示やSQLの処理時間を計測し、表示してくれるツール。 class ApplicationController < ActionController::Base protect_from_forgery before_filter :miniprofiler private def miniprofiler if Rails.env.development? || (current_user.try(:role) ==
前回は『N+1件』問題を解決して、パフォーマンスを改善することができました。今回はページ表示部分（View）に関する処理を変更することでパフォーマンスを改善したいと思います。 まずは、前回終了時点のパフォーマンスを確認しておきましょう。 だいたい１秒弱かかっているようですね。そういえば前回、クライアントマシンのスペックを記載するのを忘れていました・・・筆者は Mac Book Air 2012 mid （デュアルコア2.0GHz Intel Core i7）／メモリ８G を使用しています。 それでは、チューニングを初めましょう！ パフォーマンス・チューニング２：Viewヘルパー さらなるパフォーマンスの改善を行うためには、どの処理に負荷がかかっているのかを知ることが不可欠です。rack-mini-profilerの表示を確認し、当たりをつけましょう。『959.0ms』という部分をクリックし
本記事は英語版ブログで公開された記事の翻訳版です。 パフォーマンスはどんなアプリケーション開発者にとっても大きな懸念です。問題なのは、人は往々にして、実際にパフォーマンスが下がりはじめ懸念すべき事態になるまで問題を放置しがちだという点です。パフォーマンス対策は前もって講じておくべきもので、ほころびが出はじめてから取りかかるのでは遅すぎます。たまのレビューで済ませるのではなく、プロセスの一環に組み込むことが必要です。この記事では、パフォーマンス向上のために開発者が自分でできるいくつかの対策について見ていきます。まずはデータベースです。 データベースのパフォーマンス Railsを使う場合、ActiveRecordやDataMapperといったORMを使えばアプリケーションからのデータ取得を楽にできますが、それだけにデータベースとのやりとりを改善する最適化やリファクタリングの重要性をおろそかにし
Alexander Dymo Alex is the co-author of the KDevelop IDE for Linux and Mac and was the founding engineer at Acunote. 1 Introduction I often hear that Rails is slow. This has become a common theme among the Ruby and Rails community. But it is actually a myth. It's easy to make your application up to 10x faster just by using Rails in the right way. Here's what you need to know to optimize your Rails
peek/peekという、パフォーマンス測定を目的としたRails用プラグインのコードを読んだ。rack-miniprofilerを知っている人はそういう類のもの。peekはGitHubやGitHub Enterpriseで利用されている。peekの構造は、リクエストIDごとに情報を保存する機能、リクエストIDを元に情報を取得する機能、そして情報を描画する機能の3つの部分に分解できる。 リクエストIDごとに情報を保存する この処理は、HTMLを返却するためのリクエストの処理中に行われる。リクエストの処理中に実行される様々な処理について、それらの実行時間や実行回数を計測し、計測結果を保存する。保存先は、故意に設定しなければメモリ (厳密にはとあるクラスオブジェクトのインスタンス変数) に保存されるが、保存先をRedisやMemcacheに変更することもできる。 リクエストIDを元に情報を取得
HeartRails Tech Blog ハートレイルズのエンジニア、デザイナーによるブログです。 ウェブサービス、スマホアプリ、IoT デバイスの開発に関連する技術的な情報を発信していきます。 こんにちは、ハートレイルズの境 (@kazsakai) です。好きなエクスペンダブルズはドルフ･ラングレンです。 さて、弊社ではよくサーバーサイドを nginx+passenger+Ruby on Rails という構成でサービスを構築しています。 Rails を使っているのは社名が HeartRails だから、というわけでは全くなく、単に僕が昔から Ruby を使っていたからで、他意はありません。 passenger は今や Rails/Rack アプリ向けの標準ミドルウェアみたいな存在で、このおかげで随分 Rails の運用が楽になっています。passenger のリリース以前は手製スクリプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
