Hello List,
during a small dive into a system with aeolus for one colleague, I discovered that some views was really slow and seems that happen in randomic way.
This reason gave me the impression that we should do some benchmarks not with a mere ab or time curl but actually measuring the load time of the transaction[1], because this will, from my point of view identify possible holes/misconfigurations or simply things we forgotten to optimize/fix.
Also the video cited in [1] enlighted me on what really count to be measured.
To measure the transaction response, we can use a tool, Apache JMeter[2]. With this we will record a session of our interest and execute the load test on it. [3]
Hope to have your feedback on this,
Cheers, -FV
[1] http://blip.tv/clojure/craig-andera-performance-in-the-wild-5970188 [2] http://jmeter.apache.org/ [3] http://www.ibm.com/developerworks/java/library/j-ap04088/
On Thu, Feb 07, 2013 at 05:19:19PM +0100, Francesco Vollero wrote:
Hello List,
during a small dive into a system with aeolus for one colleague, I discovered that some views was really slow and seems that happen in randomic way.
Yes, I've noticed some really slow bits in the past as well. I would dare argue that performance hasn't been a focus for us.
This reason gave me the impression that we should do some benchmarks not with a mere ab or time curl but actually measuring the load time of the transaction[1], because this will, from my point of view identify possible holes/misconfigurations or simply things we forgotten to optimize/fix.
Also the video cited in [1] enlighted me on what really count to be measured.
To measure the transaction response, we can use a tool, Apache JMeter[2]. With this we will record a session of our interest and execute the load test on it. [3]
+1
Though another interesting idea is using New Relic[1]. While their site focuses on their monitoring of hosted, production apps, they also permit running a gem locally that will profile requests and help you see where time is being spent in the Rails stack. I've found it handy on past projects for identifying bad queries, inefficient views, and a memcache caching system that actually slowed things down.
Just another tool for the toolbox.
On Fri, Feb 08, 2013 at 02:30:59PM -0500, Matt Wagner wrote:
On Thu, Feb 07, 2013 at 05:19:19PM +0100, Francesco Vollero wrote:
Hello List,
during a small dive into a system with aeolus for one colleague, I discovered that some views was really slow and seems that happen in randomic way.
Yes, I've noticed some really slow bits in the past as well. I would dare argue that performance hasn't been a focus for us.
+1
This reason gave me the impression that we should do some benchmarks not with a mere ab or time curl a session of our interest and execute the load test on it. [3]
+1
Yay! Thanks for your +1.
Though another interesting idea is using New Relic[1]. While their site focuses on their monitoring of hosted, production apps, they also permit running a gem locally that will profile requests and help you see where time is being spent in the Rails stack. I've found it handy on past projects for identifying bad queries, inefficient views, and a memcache caching system that actually slowed things down.
Just another tool for the toolbox. [1] http://newrelic.com/
Yes that can be an option, and since you cited New Relic you let me recall of 2 really coool projects: errbit[1] and Riemann[2]
Cheers, Francesco
aeolus-devel@lists.fedorahosted.org
-
Francesco Vollero -
Matt Wagner