ScaleOut | Supership
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
例えば GC を止める・Ruby ウェブアプリケーションの高速化 - 2nd life (移転しました)
最近クックパッドでは、アプリケーションサーバの大半が Rails 2.3 から Rails 3 に置き換わったのですが*1、リリース前のベンチマークの時点ではあまりパフォーマンスが出ず四苦八苦していました。具体的には Rails 2.3 の時と比べ MRI 1.8.7 だとレスポンスタムが200%ぐらい遅い結果でした。Rails 3 になって実装が Merb core を取り入れ疎結合で綺麗になった反面、より多くのオブジェクトと・メモリを利用する様になった影響かと思います。 そこで Ruby インタプリタの変更*2を行い検証をしたところ MRI 1.8.7 (Rails 2.3と比べ) 約200%遅い MRI 1.8.7 -> Ruby Enterprise Edition 1.8.7 2011.03 (tcmalloc 無効) 約180%低速 MRI 1.8.7 -> Ruby Ente
Rails/Ajax高速化関係メモ - Rubricks Project
RubyKaigiでも発表させてもらったのですが、Rubricks0.6リリースに向けてパフォーマンスをがんばって上げております。 以下、つらつらと。 render_componentが遅い render_componentはrequest.dupしてコントローラに投げなおすようなつくりになってて無駄が多い。 シンプルなsimple_render_componentを自作して解決。 →コントローラの処理時間がに5倍近く高速化 IEはDOM操作を行うと重い 一般的にDOM操作よりもinnerHTMLの方が速い。 SpinelzをDOM操作ではなく極力innerHTMLで操作するように改良 →IEで約3倍の高速化 毎回JSライブラリを読み直しは重い 数百kbyteのJSライブラリを読み直すのに時間がかかっている。 ほとんどのJSをログイン時に先読みし、画面更新を全てAjaxベースで実施するよう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
