Forem: Swaathi Kakarla

Pattern Matching In Elixir

Swaathi Kakarla — Mon, 24 Aug 2020 15:53:07 +0000

If you’re someone who’s sick of writing huge IF and CASE statements, you’re not alone. As a relative newbie to functional languages, pattern matching is something I really enjoyed. It’s a great way to write idiomatic code - without the need for those long nested conditional statements.

Pattern matching is definitely not something new. It’s existed for decades as a powerful functional programming technique. I personally enjoy the way Elixir implements it, so much so that I always look out for ways to use it.

So, what is pattern matching? The name reveals as much - it’s a way to process and extract data based on its structure. With it, the “=” operator works more like a matching operator than an assignment operator. Let me show you what I mean.

It’s not the assignment operator anymore!

With pattern matching, the “=” operator is used to match values on either side. For example, if you were to do,

iex(1)> 4 = 5
** (MatchError) no match of right hand side value: 5
You get a “MatchError” exception. Here, Elixir is not trying to assign the value of “5” to “4”, but rather seeing if they’re equal.

If you’re associating this with the common “==” parameter, well you’re almost there. Technically MatchError could be equated to false, but the error information gives us more detail into what is exactly not matching. More on this down below!

Let’s see what happens when we try it with a variable.

iex(4)> x = 4
4

iex(5)> 5 = x + 1
5

iex(6)> 5 = x + 2
** (MatchError) no match of right hand side value: 6
In the first statement, x gets assigned the value of 4 because x is nil/null/empty.

In the second statement, x retains the value of 4 and since both sides match, we get no error.

However in the last statement, a MatchError is raised.

What’s really great is that you can use this across different data types,

Here’s another example,

iex(7)> [1, x, 5] = [1, 10, 5]
[1, 10, 5]
iex(8)> x
10
This is incredibly useful in parsing JSON responses,

iex(9)> %{topic: x} = %{name: "Swaathi", company: "Skcript", topic: "Elixir", source: "Internet"}
%{company: "Skcript", name: "Swaathi", source: "Internet", topic: "Elixir"}
iex(10)> x
"Elixir"
It works great with nested lists too!

Matching in case statements

Pattern matching in case statements makes the code so much more idiomatic. For example,

iex(6)> case {4, 5, 6} do
...(6)> {4, 5} -> "One"
...(6)> {4, 5, x} -> "X is #{x}"
...(6)> _ -> "Three"
...(6)> end
"X is 6"

You can see that not only the pattern is matched, but the missing element is also assigned to the variable “X”.

You can pattern match in if statements too - but it’s really frowned upon in the Elixir world. Generally if statements are less idiomatic and extremely limited as compared to case statements so you’ll see them used only in really rare scenarios.

Control the flow of logic

As someone who used to worship OO programming, I tried to bring most of those concepts into the functional world. I quickly realized the error in my ways.

Let’s take an example of a payment library. In the OOP world, there would be shared state across objects and a function for each payment method. Something like this,

class Payment
  attr_accessor :amount
  def initialize(amount)
    self.amount = amount
  end

  def pay_with_paypal(username, password)
    ...
  end

  def pay_with_card(number, expires_on, cvv)
    ...
  end
end

And then to execute, I would have called this,

p = Payment.new(100)
p.pay_with_paypal(“xxx”, “xxx”)

Or,

p.pay_with_card(“xxx”, “xxx”, “xxx”)

Now my OOP brain would convert this into FP like so,

defmodule Payments do
  def pay_with_paypal(login: login, password: password) do
    ...
  end

  def pay_with_card(number: number, expires: expires, code: code) do
    ...
  end
end

Well looks about right, no?

Not exactly. In Elixir, you can pattern match in functions too! This proves to be extremely useful when the function that needs to be executed is dependent on the parameters passed. The more idiomatic way to write this code would be,

defmodule Payments do
  def pay(:paypal, login: login, password: password) do
    ...
  end
  def pay(:card, number: number, expires: expires, code: code) do
    ...
  end
end

Here your function name remains the same (since you’re trying to pay at the end of the day), and the function that gets executed will be based on the first parameter.

Like so,

Payments.pay(:paypal, login: "xxx", password: "xxx")
What’s great about pattern matching in functions is that you can extract the parameter value as and when you’re determining what function to execute.

def run(%{state: "ready"}, ctx) do
  ...
end

def run(%{state: "pending"}, %{initialized: false } = ctx) do
  ...
end

In the first function, the value of ctx could just about be anything, however the second function will only get executed when the second parameter matches the pattern of “{initialized: false}” (when “initialized” is false).

It doesn’t end there. You can tag on “guard” statements too to functions!

def run(%{state: "ready", data: data}, ctx) when length(data) > 0 do
  ...
end

Now this function will execute only when “state” is ready AND the length of “data” is greater than zero. How useful is that! (Now you might start realizing why if statements are frowned upon.)

If the calling function matches none of these statements, Elixir will throw an error. However if you want to catch that too, you can just do this.

def run(_, _) do 
  ...
end

Here the “underscore” parameter acts as a catchall and will execute when none of the other functions match. Be careful to place this at the very end as the order of matching is top to bottom.

Conclusion

Pattern matching is a great way to write idiomatic functional code. It’s a powerful tenant of functional programming that makes it a joy to write conditional statements. Once you master it, you can clean up your code and optimize it in tons of places!

Concurrency In The Erlang VM

Swaathi Kakarla — Thu, 25 Jun 2020 07:26:17 +0000

Erlang is often referred to as the “concurrency oriented programming language”.

How did it get this name? How can a language created in the 80s for the telecom industry help us now?

Erlang or Erlang/OTP (Open Telecom Platform) was built in 1986 at Ericsson to handle the growing telephone user base. It was designed with the aim of improving the development of telephony applications. It is great for building distributed, fault tolerant and highly available systems.

So, what relevance does a technology built in the 80s have for us? It turns out that all the reasons for which Erlang was built for is extremely useful for web servers today. We need applications to be fast and reliable - and we want it now! Fortunately that’s possible with Phoenix, the web framework built on top of Elixir (a modern language built on top of Erlang). It has great features like hot code swapping and real time views - without JS!

How is all that possible? It’s largely due to how the language was built to be concurrent from bottom up - thanks to BEAM, the Erlang VM.

Before we go any further, let’s recap a few concepts from CS 101 - the Operating System!

Concurrency

In order to understand why concurrency in the Erlang VM is so special, we need to understand how the operating system processes instructions/programs.

The CPU is responsible for the working of a machine. It’s sole responsibility is to execute processes. Now a process is an isolated block of execution. They have their own memory, context and file descriptors. A process is then made up of many threads or the over used definition “a lightweight process”.

The CPU is responsible for executing these processes in the most efficient format. It can execute processes one after the other. This is known as “sequential execution”. This is the most basic and oldest method of execution. It’s also pretty useless for us today - even the refrigerators we use today can do more!

You might think that since your modern day computer allows you to do more than one thing at a time, the CPU is executing processes in parallel. Something like this,

However this is far from the truth. We are quite far from true parallelism. There’s a whole plethora of bugs that crop up when we try to go down this path.

The next best thing is concurrency. Concurrent execution means breaking up processes into multiple tiny bits and switching between them while executing. This happens so fast that it gives the user the illusion of multiple processes being executed at the same time - while cleverly circumventing the problems of parallelism.

It looks something like this,

You can see that the CPU switches between process 1 and 2. This is known as context switching. It is a pretty heavy task as the CPU needs to store all the information and state of a process to memory before switching - and then load it back when it needs to execute again. However we’ve worked on this problem for so many years that we’ve got insanely good at it.

One last thing …

The speed of program execution is dependent on the CPU clock cycles. The faster the processor, the faster your computer is. Moore’s law states that the number of transistors on an affordable CPU would double every two years. However if you’ve noticed, processors haven’t been getting that much faster in the past few years. That’s because we’ve hit a physical bump in the road. This happened when we realized going much higher than 4GHz is very difficult and futile. Speed of light actually became a constraint! This is when we decided to do multi-core processing instead. We scaled horizontally, instead of vertically. We added more cores, instead of making a single core powerful.

Okay I know we’ve covered a lot of material here. But what’s relevant for you to remember is that context switching is heavy and that we’ve moved on to multi-core processing now. Let’s see what tricks Erlang has up its sleeve that makes it the concurrency oriented language.

Concurrency Models

In the previous section we deduced that concurrency is the best way forward to achieve multiprocessing. Over the years various languages have introduced different algorithms to achieve concurrency. Let’s have a look at three of the most significant ones relevant to our topic of discussion.

1. Shared Memory Model

This is a commonly used model in popular programming languages like Java and C#. It involves different processes accessing the same block of memory to store and communicate with each other. It allows for context switching to be less heavier.

Though this sounds great in theory, it causes some unfriendly situations when two or more processes try to access the same shared memory block. It leads to situations like deadlocks. In order to overcome this, we have mutexes,locks and synchronization. However this makes the system more complex and difficult to scale.

2. Actor Model

This is the model used by Erlang and Rust to achieve concurrency. It depends on isolating processes as much as possible and reducing communication between them to message passing. Each process is known as an actor.

Actors communicate with each other by sending messages. Messages can be sent at any time and are non-blocking. These messages are then stored in the receiving actors mailbox. In order to read messages, actors have to perform a blocking read action.

3. Communicating Sequential Processes

This is a highly efficient concurrent model used by Go. It’s similar to the actor model in that it uses message passing. However unlike in the actor model where only receiving messages is blocking, CSP requires both actions to be blocking.

In CSP, a separate store called the channel is used to transfer incoming and outgoing messages. Processes don’t communicate with each other directly, but with the channel layer in between.

Actor Model

Let’s take a deeper look into the actor model.

An actor is a primitive form of concurrency. Each actor has an identity that other actors can use to send and receive messages from. When messages are received, they are stored in the actors mailbox. An actor must make an explicit attempt to read contents of the mailbox. Each actor is completely isolated from others and shares no memory between them. This completely eradicates the need for complex synchronization mechanisms or locks.

An actor can do three things when it receives a message,

Create more actors
Send messages to other actors
Designate what to do with the next message

The first two are pretty straightforward. Let’s look at it’s representation on a code level.

You can see here that spawning a new process in Elixir - is exactly that. Unlike other languages which use a multithreaded approach to deal with concurrency, Elixir uses threads.

The key thing to remember is that these are Erlang threads which are much more lightweight than their OS counterparts. On average, Erlang processes are 2000 times more lightweight than OS processes. There could be hundreds of thousands of Erlang processes in a system and all would be well.

Erlang threads also have a PID attached to them. Using this PID, you can extract information about the memory it occupies, functions it’s running and much more. Using the PID, you can also send messages to processes and communicate.

Let’s take a look at the final responsibility of an actor - designation.

You can see here that each process also has its own internal state. Everytime we send a message to the process, it does not restart the function with default values, rather it is able to retain information of the state of the running process. Inherently each actor is able to access it’s own set of memory, and keep track of it.

These three properties allow Erlang processes to be very lightweight. It eradicates the need for complex synchronization techniques and does not take up too much memory space for interprocess communication. All this contributes to high availability.

At this point of time, it’s a great idea to watch this quick 4 minute video of the actor model. After all, a picture is worth a thousand words, and a video even more! If you’ve got the time and want something much more in detail, have a look at this video where the creator of the Actor Model explains all that I’ve said in such an eloquent way.

BEAM

Well after so many topics, we’ve finally come to the actual Erlang VM - BEAM!

The BEAM VM was built to be able to both compile Erlang/Elixir files into bytecode (.beam) files as well as to schedule Erlang processes on the CPU. This level of control gives a huge advantage to efficiently and concurrently run processes.

When the VM starts, it’s first step is to start the Scheduler. It is responsible for running each Erlang process concurrently on the CPU. Since the processes are all maintained and scheduled by BEAM, we have more control over what happens when a process fails (fault tolerance) and are able to more efficiently use memory and perform better context switching.

BEAM also takes full advantage of the hardware. It starts a Scheduler for each available core allowing processes to run freely and efficiently, while still being able to communicate with each other.

BEAM allows Erlang to spawn thousands of processes and achieve high levels of concurrency. There is an awesome conversation on HackerNews about how the idea that thousands of processes lead to efficient concurrency.

Have a read!

Contributing Characteristics

Stay calm, we’re almost at the end!

Erlang concurrency is largely due to the Actor model and BEAM. However, there are many other constructs that ensure stability as well. I’m going to give you small pointers that you can pick up for further reading.

1. Supervisors

There is a special Erlang process called the Supervisor. It’s goal is to figure out what to do when a process fails. It helps it reset to an initial value so that it can be sent for processing once again.

2. Fault Tolerance

Joe Armstrong, (late) creator of Erlang, said the infamous line, “Let it crash”. He designed the fault tolerant language not with the goal of preventing errors from happening, but to build structures that handle error scenarios.

The entire thread is heartwarming, give it a read!

3. Distribution

Finally Erlang makes it extremely easy to build distributed systems. Each Erlang instance can act as a node in different devices and communicate just as easily as spawning processes.

4. No GIL!

Unlike other interpreted languages, most famously Ruby and Python, Erlang does not have to worry about the Global Interpreter Lock. The GIL ensures that only one Ruby/Python thread runs per process on the CPU. This is a huge blow to concurrency.

App servers like Passenger try to overcome this by creating multiple OS processors and run it on multiple cores. However as we saw before, OS threads are expensive to manage.

Conclusion

Erlang is a beautifully constructed and well throughout language. It’s truly passed the test of time and is so much more relevant in recent times.

Rails is Fast: Optimize Your View Performance

Swaathi Kakarla — Wed, 29 Jan 2020 15:13:44 +0000

In this post, we'll look into tried and true methods of improving Rails view performance. Specifically, I will focus on database efficiency, view manipulation, and caching.

I think the phrase "premature optimization is the root of all evil" has been taken a little out of context. I've often heard developers use this during code reviews when simple optimization techniques are pointed out. You know the famous, "I'll get it working and then optimize it" - then test it - then debug it - then test it again, and so on!

Well, thankfully, there are some simple and effective performance and optimization techniques that you can use from the moment you start writing code.

Throughout the post, we will stick to a basic Rails app, make improvements on it and compare results.

The basic Rails app has the following models:

Person (has many addresses)
- name:string
- votes_count:integer
Profile (belongs to Person)
- address:string

This is what our Person model looks like:

# == Schema Information
#
# Table name: people
#
#  id          :integer          not null, primary key
#  name        :string
#  votes_count :integer
#  created_at  :datetime         not null
#  updated_at  :datetime         not null
#

class Person < ApplicationRecord
  # Relationships
  has_many :profiles

  # Validations
  validates_presence_of :name
  validates_uniqueness_of :name

  def vote!
    update votes_count: votes_count + 1
  end
end

This is the code for our Profile model:

# == Schema Information
#
# Table name: profiles
#
#  id         :integer          not null, primary key
#  address    :text
#  person_id  :integer
#  created_at :datetime         not null
#  updated_at :datetime         not null
#

class Profile < ApplicationRecord
  # Relationships
  belongs_to :person

  # Validations
  validates_presence_of :address
end

There's also a seed file to populate 1000 people. We can do this with ease by utilizing Faker gem.

We're now going to create an action called "home" in ApplicationController.

def home
  @people = Person.all
end

The code for our home.html.erb is as follows:

<ul>
  <% @people.each do |person| %>
    <li id="<%= person.id %>"><%= render person %></li>
  <% end %>
</ul>

Let's do a dry run and measure the performance of our page against this.

That page took a whopping 1066.7ms to load. Not good! This is what we will aim to reduce.

Database Queries

The first step to building a performant application is to maximize resource utilization. Most Rails apps render something from the database onto the views, so let's try to optimize database calls first!

For the purpose of this demonstration, I'm going to use a MySQL database.

Let's look at how that initial load of 1066ms breaks down.

414.7 to execute 'controllers/application_controller#home'

...
(0.1ms)  SELECT "profiles"."address" FROM "profiles" WHERE "profiles"."person_id" = ?  [["person_id", 996]]
Rendered people/_person.html.erb (1.5ms)
(0.2ms)  SELECT "profiles"."address" FROM "profiles" WHERE "profiles"."person_id" = ?  [["person_id", 997]]
Rendered people/_person.html.erb (2.3ms)
(0.1ms)  SELECT "profiles"."address" FROM "profiles" WHERE "profiles"."person_id" = ?  [["person_id", 998]]
Rendered people/_person.html.erb (2.1ms)
(0.2ms)  SELECT "profiles"."address" FROM "profiles" WHERE "profiles"."person_id" = ?  [["person_id", 999]]
Rendered people/_person.html.erb (2.3ms)
(0.2ms)  SELECT "profiles"."address" FROM "profiles" WHERE "profiles"."person_id" = ?  [["person_id", 1000]]
Rendered people/_person.html.erb (2.0ms)
Rendered application/home.html.erb within layouts/application (890.5ms)

Completed 200 OK in 1066ms (Views: 890.5ms | ActiveRecord: 175.4ms)

519.2 and 132.8 to render "application/home.html.erb" and "people/_person.html.erb" partials.

Did you notice anything weird?

We made one database call in the controller, but every partial makes its own database call as well! Introducing, the N+1 query problem.

1. N+1 Queries

This is a very popular and simple optimization technique—but it deserves the first mention since this mistake is so prevalent.

Let's see what "people/_person.html.erb" does:

<ul>
  <li>
    Name: <%= person.name %>
  </li>
  <li>
    Addresses:
      <ul>
        <% person.profiles.each do |profile| %>
          <li><%= profile.address %></li>
        <% end %>
      </ul>
  </li>
</ul>

<%= button_to "Vote #{person.votes_count}", vote_person_path(person) %>

Basically, it queries the database for that person's profiles and renders each one out. So it does N queries (where N is the number of people) and the 1 query we did in the controller—thus, N+1.

To optimize this, make use of the MySQL database joins and the Rails ActiveRecord includes functions.

Let's change the controller to match the following:

def home
  @people = Person.all.includes(:profiles)
end

All the people are loaded by 1 MySQL query, and all their respective queries are loaded in another. Bringing N+1 to just 2 queries.

Let's look at how this increases performance!

It took us only 936ms to load the page. You can see below that the "application_controller#home" action does 2 MySQL queries.

Rendered people/_person.html.erb (0.3ms)
Rendered people/_person.html.erb (0.2ms)
Rendered people/_person.html.erb (0.3ms)
Rendered people/_person.html.erb (0.3ms)
Rendered people/_person.html.erb (0.3ms)
Rendered people/_person.html.erb (0.3ms)
Rendered people/_person.html.erb (0.3ms)
Rendered people/_person.html.erb (0.2ms)

Rendered application/home.html.erb within layouts/application (936.0ms)
Completed 200 OK in 936ms (Views: 927.1ms | ActiveRecord: 9.3ms)

2. Load Only What You Will Use

This is how the homepage looks.

You can see we only need the address, nothing else. But in the "_person.html.erb" partial we load the profile object. Let's see how we can make that change.

<li>
  Addresses:
  <ul>
    <% person.profiles.pluck(:address).each do |address| %>
      <li><%= address %></li>
    <% end %>
  </ul>
</li>

For a more in-depth look at N+1 queries, read ActiveRecord performance: the N+1 queries antipattern.

ProTip: You can create a scope for this and add it to the "models/profile.rb" file. Raw database queries in your view files aren't of much use.

3. Move All Database Calls to the Controller

Let's say, in the future of this make-believe application, you'd like to display the total number of users on the home page.

Simple! Let's make a call in the view that looks like this:

# of People: <%= @people.count %>

Okay, that's simple enough.

There's another requirement—you need to create a UI element that displays the page progress. Let's now divide the number of people on the page by the total count.

Progress: <%= index / @people.count %>

Unfortunately, your colleague doesn't know that you've already made this query and they proceed to make it again and again in the views.

Had your controller looked like this:

def home
  @people = Person.all.includes(:profiles)
  @people_count = @people.count
end

It would have been easier to reuse already calculated variables.

Though this does not contribute to a direct improvement in page load speeds, it prevents multiple calls to the database from various view pages and helps you prepare for optimizations that you can perform later, such as caching.

4. Paginate Wherever You Can!

Just like loading only what you need, it also helps to only show what you need! With pagination, views render a portion of the information and keep the rest to load on demand. This shaves off a lot of milliseconds! The will_paginate and kaminari gems do this for you in minutes.

One annoyance that this causes is that users have to keep clicking on "Next Page". For that, you can also look at "Infinite Scrolling" to give your users a much better experience.

Avoiding HTML Reloads

In a traditional Rails app, HTML view rendering takes a lot of time. Fortunately, there are measures you can take to reduce this.

1. Turbolinks

This comes wrapped up in your standard Rails app. Turbolinks is a JavaScript library that works everywhere (even without Rails, like on static pages) and degrades gracefully on unsupported browsers.

It converts every link into an AJAX request and replaces the entire body of the page via JS. This greatly improves performance as it doesn't have to reload the CSS, JS and images.

However, when writing custom JS you'll have to take extra precaution to write "Turbolinks safe JS". Read more about this here.

2. Use AJAX Requests

In the same vein as Turbolinks, you can convert some of your links and buttons into AJAX requests as well. The difference here is that you get to control what HTML gets replaced rather than replacing the whole body as Turbolinks does.

Let's see AJAX in action!

In the sample app, there's a "Vote" button for each user. Let's measure how long it takes to do that action.

Started POST "/people/1/vote" for 127.0.0.1 at 2020-01-21 14:50:49 +0530
Processing by PeopleController#vote as HTML
  Person Load (0.3ms)  SELECT  "people".* FROM "people" WHERE "people"."id" = ? LIMIT ?  [["id", 1], ["LIMIT", 1]]
   (0.1ms)  begin transaction
  Person Exists (4.5ms)  SELECT  1 AS one FROM "people" WHERE "people"."name" = ? AND ("people"."id" != ?) LIMIT ?  [["name", "Deon Waelchi"], ["id", 1], ["LIMIT", 1]]
  SQL (1.0ms)  UPDATE "people" SET "votes_count" = ?, "updated_at" = ? WHERE "people"."id" = ?  [["votes_count", 1], ["updated_at", "2020-01-21 09:20:49.941928"], ["id", 1]]

Redirected to http://localhost:3000/
Completed 302 Found in 24ms (ActiveRecord: 7.5ms)


Started GET "/" for 127.0.0.1 at 2020-01-21 14:50:49 +0530
Processing by ApplicationController#home as HTML
  Rendering application/home.html.erb within layouts/application

  Rendered people/_person.html.erb (2.4ms)
   (0.3ms)  SELECT "profiles"."address" FROM "profiles" WHERE "profiles"."person_id" = ?  [["person_id", 30]]
  Rendered people/_person.html.erb (2.2ms)
  ...

  Rendered application/home.html.erb within layouts/application (159.8ms)
Completed 200 OK in 190ms (Views: 179.0ms | ActiveRecord: 6.8ms)

That took the same amount of time as reloading the page, plus a little extra for the actual voting part.

Let's make it an AJAX request. Now, our "people/_person.html.erb" looks like this:

<%= button_to "Vote #{person.votes_count}", vote_person_path(person), remote: true %>

Our controller action returns a JS response, which looks like this:

$("#<%= @person.id %>").html("<%= j render(partial: 'person', locals: {person: @person}) %>");

As you can see, we're replacing only the content we need. We provide an HTML ID to hook onto a div and replace it. Of course, we can further optimize this by replacing only the button content, but for the purposes of this post, let's replace the entire partial.

Results?

Started POST "/people/1/vote" for 127.0.0.1 at 2020-01-21 14:52:56 +0530
Processing by PeopleController#vote as JS

  Person Load (0.2ms)  SELECT  "people".* FROM "people" WHERE "people"."id" = ? LIMIT ?  [["id", 1], ["LIMIT", 1]]
   (0.1ms)  begin transaction
  Person Exists (0.3ms)  SELECT  1 AS one FROM "people" WHERE "people"."name" = ? AND ("people"."id" != ?) LIMIT ?  [["name", "Deon Waelchi"], ["id", 1], ["LIMIT", 1]]
  SQL (0.4ms)  UPDATE "people" SET "votes_count" = ?, "updated_at" = ? WHERE "people"."id" = ?  [["votes_count", 2], ["updated_at", "2020-01-21 09:22:56.532281"], ["id", 1]]
   (1.6ms)  commit transaction
  Rendering people/vote.js.erb
   (0.2ms)  SELECT "profiles"."address" FROM "profiles" WHERE "profiles"."person_id" = ?  [["person_id", 1]]

  Rendered people/_person.html.erb (3.2ms)
  Rendered people/vote.js.erb (6.3ms)
Completed 200 OK in 31ms (Views: 14.6ms | ActiveRecord: 2.9ms)

30ms! That's it! How great is that?

ProTip: If you don't want to mess around with a bunch of HTML IDs and classes to figure out when/what to replace, consider using the render_async gem. It does a lot of the heavy lifting out of the box.

3. Use Websockets

One of the great things about an HTML reload is that it gets you fresh content from the server every time. With an AJAX request, you only see the latest content for the little snippet.

WebSockets are a great piece of technology that let your server push updates to the client, instead of the client requesting for new information.

This can be useful when you need to build dynamic webpages. Imagine you need to display the score of a game on your website. To fetch new content you can,

Tell your users to reload the entire page
Provide a reload button that refreshes just the score
Use JavaScript to keep polling the backend every second
- This will keep pinging the server even when there is no change in data
- Each client will make calls every second - easily overwheling the server
Use WebSockets!

With WebSockets, the server has control of when to push data to all clients (or even a subset). Since the server knows when data changes, it can push data only when there is a change!

Rails 5 released ActionCable, which lets you manage all things WebSockets. It provides a JS framework for the client to subscribe to the server and a backend framework for the server to publish changes. With action cable, you have the ability to choose any WebSocket service of your choice. It could be Faye, a self-managed web socket service, or Pusher a subscription service.

Personally, I'd choose a subscription for this, as it reduces the number of things you need to manage.

Okay, back to WebSockets. Once you're done setting up ActionCable, your view will not be able to listen to JSON input from the server. Once it receives it, the hook actions you've written will replace the respective HTML content.

Rails docs and Pusher have great tutorials on how to build with WebSockets. They're must-reads!

Caching

The majority of load time gets used up in rendering views. This includes loading all CSS, JS and images, rendering out HTML from ERB files and more.

One way to reduce a chunk of the load time is to identify parts of your application that you know will stay static for some amount of time or until an event occurs.

In our example, it's obvious that until someone votes, the home page will essentially look the same for everyone (currently there is no option for users to edit their addresses). Let's try to cache the entire "home.html.erb" page until an event (vote) occurs.

Let's use the Dalli gem. This uses Memcached to quickly store and retrieve fragments of information. Memcached does not have a datatype for storage, leaving you to store essentially whatever you like.

1. Caching Views

The load time for 2000 records without caching, is 3500ms!

Let's cache everything in "home.html.erb". It's simple,

<% cache do %>
  <ul>
    <% @people.each do |person| %>
      <li id="<%= person.id %>"><%= render person %></li>
    <% end %>
  </ul>
<% end %>

Next, install the Dalli gem and change the cache store in "development.rb" to:

config.cache_store = :dalli_store

Then, if you're on Mac or Linux, simply start the Memcached service like this:

memcached -vv

Now let's reload!!

That took about 537ms! That's a 7x improvement in speed!

You'll also see that there are far less MySQL queries because the entire HTML was stored in Memcached and read from there again, without ever pinging your database.

If you pop on over to your application logs, you'll also see that this entire page was read from the cache.

This example of course is just scratching the surface of view caching. You can cache the partial rendering and scope it to each person object (this is called fragment caching) or you can cache the entire collection itself (this is called collection caching). Further for more nested view rendering, you can perform Russian Doll caching.

2. Caching Database Queries

Another optimization you can do to improve view speed is to cache complex database queries. If your application shows stats and analytics, chances are that you are performing a complex database query to calculate each metric. You can store the output of that into Memcached and then assign a timeout to it. This means that after the timeout, the calculation will be performed again and then stored to the cache.

For example, let's assume that the application needs to display the size of a users team. This could be a complex calculation involving counts of direct reportees, outsourced consultants and more.

Instead of repeating the calculation over and over again, you can cache it!

def team_size
  Rails.cache.fetch(:team_size, expires_in: 8.hour) do
    analytics_client = AnalyticsClient.query!(self)
    analytics_client.team_size
  end
end

This cache will auto-expire after 8 hours. Once that happens, the calculation will be performed again and the latest value will be cached for the next 8 hours.

3. Database Indexes

You can also speed up queries by using indexes. A simple query to fetch all addresses of a person,

person.addresses

This query asks the Address table to return all addresses where person_id column is person.id. Without indexes, the database has to inspect each row individually to check if it matches person.id. However, with indexes, the database has a list of addresses that match a certain person.id.

Here's a great resource to learn more about database indexes!

Summary

In this post, we explored how to improve your Rails app's view performance by making improvements to database utilization, using third-party tools and services and restricting what users see.

If you are looking to improve your app's performance, start out simple and keep measuring as you go along! Clean up your database queries, then create AJAX requests wherever you can, and finally cache as many views as possible. You can move on to WebSockets and database caching after that.

However, be cautious—optimization is a slippery slope. You might find yourself as addicted as me!

P.S. For monitoring the performance of your Rails app in production, check out AppSignal's APM - built by Ruby devs for Ruby devs. 🚀

Guest author Swaathi Kakarla is the co-founder and CTO at Skcript. She enjoys talking and writing about code efficiency, performance, and startups. She’s also the chapter lead for Google Developers Group, Chennai!