Ruby on Rails Performance Tuning

Ruby on Rails Performance Tuning

Synchronises Assets between Rails and S3. Contribute to AssetSync/asset_sync development by creating an account on GitHub.

For something that is touted as being an “easy” to use framework, Rails is a pretty complex beast. Over the years it has progressed from a seemingly simple framework that “anyone” can learn to the intricate collection of add-ons, gems and extensions that make it the power house it is now. ruby on rails training will helps you to learn more skills and techniques.

Optimization is an overlooked aspect of Rails development that often isn’t covered in the tutorials you find online. With the sheer simplicity of snapping in a few gems, throwing together some quick Active Record queries, pushing to Heroku and forgetting about the rest, it’s all too easy to find your application running slow and sluggish, before long you need to backtrack and try to figure out what exactly you did that caused the slow down.

Writing better, leaner code is often the answer, although this article isn’t a coding guide, instead I’m going to list a few simple things you can do to get better performance from your application. These might not be applicable for everyone, but merely some tricks that iv learned that have helped me squeeze a bit more performance out of some recent projects of mine.

Use Unicorn As Your Default Rails Server This one is a pretty common one, but something I see new Heroku users missing out on a lot. Rails by default uses the “Webrick” server to run Rails, common practice was to often change this it use “Thin” instead.

The problem here is that both these servers don’t handle concurrent connections very well, not ideal for a production web server. There are ways to optimize this, but it’s just better and easier to switch to Unicorn.

Unicorn is a multi threaded web server and allows for multiple “workers” which effectively double and triple the amount of connections you can accept at a time by forking processes.

As an example, setting 5 worker processes allows for 5 concurrent connections. In a Heroku app, every time you scale a dyno, your increasing your maximum concurrent connections by 5.

4 x Dynos with Unicorn configured for 5 workers = 20 concurrent connections

You’ll read over the web that there’s configuration involved with unicorn, but really, it’s not much for a basic setup.

Example on my Heroku / Rails app, I used the default Unicorn config and followed instructions found here Adding Concurrency to Rails Apps with Unicorn , changing only 2 or 3 parameters, then I was up and running with Unicorn. About 10 minutes in total. Obviously do some quick Googling to see what works and is appropriate for your app.

With regards to how many workers you can run, that will depend on how heavy your application is and how much free memory you have remaining. ruby on rails certification training along with real time projects.

Heroku have made some suggestions about tuning your database connection limit in relation to your Unicorn workers here: Heroku Database | Calculating Required Connections

Host Your Assets Externally By now you’ve switched to Unicorn, and you’re feeling great that you can service more concurrent requests then before, except that when we think about page loads, one end user doesn’t translate to one request.

The problem is your page is loaded with resources such as JavaScript, CSS, images, favicon, fonts etc.

When a user hits your page and retrieves all these assets, they come down as multiple requests.

Those 5 unicorn workers are starting to lose their shine when you have 30 or 40 assets coming down the line per page load.

But wait, there’s more …

All browsers will have a HTTP request limit, which effectively queues HTTP requests to prevent people from opening too many connections per request. The amount of concurrent connections allowed per browser, per domain is typically 2 (The Two HTTP Connection Limit Issue).

When you consider a page loaded with images, CSS, JavaScript etc. It’s not hard to do the math here.

So, what’s the solution?

You’ve heard about compressing JavaScript and CSS then combining into a single file to reduce the HTTP requests per page right? Well what if you could offload some of those HTTP requests to another domain?

By simply introducing another domain into your page request, you’re offloading some of the request queue to another resource.

Automatic Remote Asset Hosting Alright, so you want to use S3, but you don’t really like the thought of having to manually move files to S3 every time you add new images to your site. No problems, there’s a gem for that called:

Asset Sync works by pushing your static files to Amazon S3 automatically on asset pre-compilation when deploying your app. This happens automatically after a push if you’re using Heroku, otherwise you just need to run

Page Caching When a page is cached, it’s stored in the /public folder as plain old static HTML. This gets served up by the web server much faster than normal as the HTML page can be served directly without needing to go through Rails at all.

Take for example, a standard home page for a business’s website. The home page may consist of several partials, a bunch of Rails helper methods for images, links and some precompiled CSS and JS.

A normal request will filter through the router first then to the controller, further onto the action then serve up the view.

The view of course then needs to render the various partials (which may also contain more Ruby/Rails items to process) and then switch out all the Rails helper tags for regular HTML.

This all happens pretty fast, but you need to think about how the performance of all this compounds when you add more functionality.

A cached page is served up as a single HTML file without having to bounce through the Rails stack, so none of this pre-processing needs to happen. Your web server dishes up the page as fast as it can retrieve it from the file system (which is pretty damn fast).

A cached page is also resilient to server errors as there is no back end processing required to serve it up. This is why by default, your 500 and 404 error pages are plain HTML pages in the /public folder. ruby on rails online training for more skills and techniques.

rails training ruby certification ruby on rails online best rails course rails online course

Bootstrap 5 Complete Course with Examples

Bootstrap 5 Tutorial - Bootstrap 5 Crash Course for Beginners

Nest.JS Tutorial for Beginners

Hello Vue 3: A First Look at Vue 3 and the Composition API

Building a simple Applications with Vue 3

Deno Crash Course: Explore Deno and Create a full REST API with Deno

How to Build a Real-time Chat App with Deno and WebSockets

Convert HTML to Markdown Online

HTML entity encoder decoder Online

Pros & Cons you must know before using Ruby on Rails for your startup

Click here, free ruby on rails course videos for you. It shows you best way to complete Ruby certification. OnlineITGuru guides you towards easy Web script

Explain Ruby on rails MVC

Our Ruby on Rails Training will provide you to learn about Rails and web applications development with realty. Our Ruby on Rails Course also includes live sessions.

Advantage of C Language Certification Online Training in 2020

C Language Online Training Course; CETPA offers exclusive live project based C Language Training in Noida, Delhi NCR Lucknow, Dehradun, Roorkee. C Language Online Course also available with certification and 100% placement assistance.

MuleSoft Certification Training | MuleSoft Training | ITGuru

Our Mulesoft Certification Training will provide you to learn the best testing tools easily with realty. Our Mulesoft Course also includes live sessions, live Projects.

Informatica Online Training | Informatica Certification Course OnlineITGuru

Get hands on experience of Informatica tool by live industry experts through Informatica online Training. Hurry up to enroll for free demo