hohoho_ho2005のブックマーク - はてなブックマーク

JVMとGCのしくみ - ITエンジニアとして生きる
先日職場でJVMの話をしてた。ちょうどいい機会だからちょっとまとめたいと思う。 JVMの構成まずはJVMの構成について。JVMには３つの領域が存在する。 Permanent領域（非ヒープ領域） New領域（ヒープ領域） Old領域（ヒープ領域） Permanent領域にはJVMにロードされたクラスやメソッドの情報、New領域にはインスタンス化されたオブジェクトの情報、Old領域には寿命の長いオブジェクトの情報が管理される。（「寿命の長い」については後述のScavenge GCを参照。） Permanent領域は非ヒープ領域、New領域とOld領域はヒープ領域となる。非ヒープ領域には基本的にGCは走らず、JVM起動時に静的な情報が管理される。（※）一方、ヒープ領域はインスタンス化されたオブジェクト情報といった動的な情報が管理され、GC対象となる。 ※ユーザ定義のクラスローダーが存在する
hohoho_ho2005 2013/10/01
jvm

java
リンク
rspecを高速化するsporkとその仕組み - ITエンジニアとして生きる
最近rspecでRailsのテストコードを書いてました。書いたテストコードは動かしながら確認していくわけですが、その１回１回の実行時間がとても長くて困ってました。（私の環境では１回の実行で大体１０秒くらいかかってました。）「なんでこんな時間かかるんやろう？」と思って調べてみたところ、どうやらrspec実行の度にRails環境をロードするため時間がかかっていたようです。 rspec実行の度にRailsをロードしていたのでは時間がかかって当然ですね。何か良い方法ないのかな？と思っていたら「spork」なるものを発見したので導入してみました。 sporkの導入GitHub - sporkrb/spork: A DRb server for testing frameworks (RSpec / Cucumber currently) that forks before each run t
hohoho_ho2005 2013/10/01
rspec

spork

Ruby
リンク
Amazon RDSのリードレプリカ＋Rails4.0＋multi_dbを試してみました - ITエンジニアとして生きる
Webで負荷分散する場合、アプリケーションは簡単にスケールアウト出来ますが、DB（がRDBMSの場合）は１つに集約するパターンが多いと思います。しかしこの構成だとどうしてもDBが性能面でのボトルネックとなりがちで、それを解消する１つのスケーリングテクニックとしてReadをレプリカへ分散させるというものがあります。今回はそれをAmazon RDSのリードレプリカとmulti_dbというgemを使って試してみました。すでにDBはRDS（MySQL）を利用しているがリードレプリカは利用していない、ということをスタート地点としています。 Amazon RDSのリードレプリカAmazon Web Services ブログ: Amazon RDSの新機能：Read Replica(リードレプリカ)の発表リードレプリカとはその名の通り、RDSの読取り専用複製インスタンスです。 RDSマスタから定
hohoho_ho2005 2013/10/01
aws

Rails
リンク
1