analysis

Scaling Ruby on Rails Applications Conclusion - Part 2

Continuing our post series about rails app performance. This week we are going to see a summary of our current analysis. Final Analysis Considerations - Part 2 On advanced caching problems, the benefits are even less worth it. If you are managing huge enterprise-level applications with thousands of simultaneous user access and a team to maintain your application, you will benefit from advanced caching. Our analysis has shown us no significant improvements when compared to the basic caching scenario.

Scaling Ruby on Rails Applications Conclusion - Part 1

Continuing our post series about rails app performance. This week we are going to see a summary of our current analysis. Final Analysis Considerations - Part 1 We have already concluded all our experiments and wet extensively thought all of them. The raw data and the Jupyter notebook, which produce these experiments, are available to download in the appendix A. To organize the ideas behind this study and what we have accomplished so far, we will recapitulate the most important parts and how they correlate to each other.

Test Analysis - Advanced caching

Continuing our post series about rails app performance. This week we are going to see a summary of our current analysis. Tests analysis Comparing box plot 7.43 a and 7.22, referring for percentile 50% of the requests, we see the same behavior and the same mean response time interval. Figures 7.43 b and 7.23 as on box plot for 50% show the exact time interval and outliers groups. As the reader might already expect, the same behavior happens when we are talking about 95% of the requests on plots 7.

Explanatory analysis - Advanced caching

Continuing our post series about rails app performance. This week we are going to see a summary of our current analysis. Exploratory analysis 2 cores and 8000MB RAM {:class=“img-fluid”} Accordingly to what we have been studying so far, we will focus this part of the analysis on 1 to 100 simultaneous users. Unlike the last section, where we relied on rails gem’s automatic caching to make things simpler a bug-free, we will use advance caching strategies where we select specific parts of the code in the cache.

Tests Analysis on Improved code

Continuing our post series about rails app performance. This week we are going to see a summary of our current analysis. Tests analysis Before we jump into a general analysis of our case scenario, we would like to use the plot 7.20 and 7.21 to demonstrate why focus on simulations with a higher number of users is of no need for us in this study. First, let us look at the plot 7.

Explanatory analysis - Simple caching

Continuing our post series about rails app performance. This week we are going to see a summary of our current analysis with . 2 cores and 8000MB RAM {:class=“img-fluid”} Let us stop here for a moment. We have a 2 cores cluster, only 9000MB dedicated to running the simulations, and ramp users access during 60 seconds. The reader might remember from the last chapter that we will focus on or analyze one to one hundred simultaneous users because, after that, we start to throttle the host machine.

Tests methodology and enhancements proposal

Continuing our post series about rails app performance. This week we are going to see our tests methodology and enhancements proposal. By this time, the reader might already have guessed correctly; our proposed enhancements are related to cache. For this study, we are going to use Redis it as a cache server. Following Towards Scalable and Reliable In-Memory Storage System: A Case Study with Redis, we are using a similar configuration based on a five nodes cluster.

Proposed Improvements on Ruby on Rails application performance test compare

Continuing our post series about rails app performance. This week we are going to see a summary of our proposed improvements. Strategy to decrease page load time As we are trying to deliver data as fast as possible to increase a web application’s performance, our goal is simple: cache. We are going to implement some caching on Consul on some levels. First, we are going to cache only translations, i18n1 related queries.

Exploratory analysis on Ruby on Rails application performance test compare

Continuing our post series about rails app performance. This week we are going to see a summary of our current analysis. Tests analysis Now we have to split this task into 2 tasks; first, we are going to compare the results between 16GB and 26GB of memory to see what changed, separately for 4 and 8 cores, then we look at jumping from 4 to 8 cores at 26GB of memory.

Exploratory analysis on Ruby on Rails application performance very memory

Continuing our post series about rails app performance. This week we are going to focus on varying the amount of memory of our simulated cluster. 8 cores and 16000MB RAM We are investigating the cluster performance focusing on process power only (amount of cores of the cluster), but we were limited to 8291MB of RAM. What if we increase the cluster memory? We will check out what happens when we increase the cluster memory to 16384MB and 25000MB.

Exploratory analysis on Ruby on Rails application performance

Hi folks, this week we are going to take a look at our experiments running a fixed amount of memory, 9000mb, but varying our core count, to understand the processor impact on our cluster simulation. Let’s dive in! 2 cores and 9000MB RAM {:class=“img-fluid”} As expected, as we increase the number of simultaneous users accessing the application, the number of answered requests decreases as low as 20%. But, let us take a look from the other side, starting with simple math.

Scaling Ruby on Rails application

Now i will try a series of posts discussing performance increase on a Ruby on Rails application. To do so, we are going to use Consul as a sample application. In this first post, we are going to see the lab environment where the tests will the performed. Each batch of tests will be released on a week basis, after all posts have been releases, i will drop the raw files.