How The Design Patterns Are Used In Mina Gem

How often do we look inside a Gem to see what’s inside it? Well – there is SO MUCH to learn from the code. Sanjiv digs inside the Mina gem and unearths the various design patterns that it uses.

An excellent article for developers to learn design patterns not from the book but directly from the implementation. It’s always easy to relate to something concrete that just read about it.

Sanjiv Kumar Jha's avatarnarutosanjiv

Mina is popular gem for fast deployment of simple ruby on rails apps. I found these design patterns being used in mina and we can learn how to use them from these real live implementations.

  1. Singleton Design Pattern.
  2. Delegation Pattern

If you are unfamiliar with Design patterns, I strongly recommend reading  Gang Of Four’s Design Pattern book. You can also have a quick wiki reference.

Singleton Design Pattern

In simple terms, Singleton design pattern mean there should be single instance of class, hence mostly used to provided global state of app.

The Singleton module implements the Singleton pattern. We include this module in a class for implementing singleton pattern. Mina gem uses the singleton pattern for storing configuration options to accessed data globally.  Here is the code from `lib/mina/configuration.rb`

1: require 'singleton' 2: module Mina 3: class Configuration 4: include Singleton 5: 6: module DSL 7: def self.included(base) 8: [:set, :fetch, :remove, :set?, :ensure!…

View original post 570 more words

Pro-tip: Scaling properly with Nginx worker_process and max_pool_size

Sometimes, it the things around us that work but need to be configured properly to scale up. Nginx configuration are just like that.

Shweta talks about her experience with scaling up performance by tweaking the nginx parameters to improve API performance drastically.

Shweta Kale's avatarLearn with fun

This post talks about worker_process and passenger_max_pool_size options for nginx and how these configurations play an important role for scalability.

Recently our client reported that API performance was  bad and it was taking a few minutes to respond! But, when we tested this API this was quite efficient and was responding in few milliseconds. What was wrong? As the number of users increased, the number of concurrent requests to the server had also increased. Initially, it was only 100’s of request per second coming to a server but now it was about 4 k requests per second and we realised that we had not scaled our server to handle this load.

When this problem arrived I thought of breaking down the problem in steps.

  • First I checked RDS instance. It was using 20%
  • I revisited all queries they were optimized enough. So database was not bottleneck
  • Sent unauthorized request to the server so with less processing…

View original post 578 more words