Are all of your Ruby on Rails applications running perfectly? If that?s the case, you can probably stop reading and go check Facebook.
You are still here? Good!
When applications are new and fresh, everything seems really good but over time problems often surface. Over the years we have been able to identify and categorize the difference types of problems we have seen. Your problems are not unique, you are not alone.
Does your application exhibit any of these problems?
Performance is probably the single biggest problem than can face a Ruby on Rails application. Things usually start out fine but over time but issues appear that can be caused by many things. Your web site starts out new, no users, no data on state-of-the-art hardware. A few years later, that?s not the case any longer.
One tool we use to help profile issues in application is Skylight. This is a great too that gives insight into what?s happening behind the scenes in your application and provides guidance to finding a solution.
Your website started with only a handful of users but grew over time, now you have thousands or maybe hundred of thousands. What worked at the beginning probably is not working now. It may be time to:
You may not consider too much data to be a problem but as your website grows, you add users, orders and all the components that go along with it, optimizations may need to be implemented.
It is unlikely there is a single solution to a slow database but a combination of several improvements.
Websites may start out on a single virtual machine (VM) and as time goes by and demands change, it may be time to examine how your hosting is holding up. Is the CPU at or near 100% utilization? Is memory always maxed out and the VM is constantly using swap space?
It may be time to consider a hardware move that is more up to the task, whether a new VM or dedicated hosted or co-located hardware. Profiling the application will reveal what?s happening under the hood and give guidance about a possible hardware upgrade.
The topic of scaling means many things but in our daily work it means constant monitoring and making small changes proactively as the application moves forward.
Your application is a living thing and needs care. It?s better to address the scaling needs of the application before users notice.
When is it time to scale? Sometimes it?s hard to know but a tool such as Scoutcan help by visualizing what resources your application is using. Is memory used up? Are the CPU?s 100% utilized? Scout has helped us many times.
When a web site is first built, it?s fresh. It?s wonderful. As a developer, it?s nice to be the one to write that first line of code. But, we don?t often get to experience that pleasure.
Developers come and go on your project and the turnover can lead to new bugs being created, side-effects being introduced and the overall health of the application in decline.
This compounding of defects in code leads to a wealth of problems that seem to appear overnight. Only a well-planned course of action can stop the creation of additional bugs and stop existing ones.
One of the worst problems to have are those effecting the stability of the application. The web site will give errors to users at what seems like random times. Server reboots fix things for a while but over time, issues return.
These can be some of the most difficult problems to solve and the most frustrating to users. Not resolving these problems can lead to users leaving your service and finding a replacement, one that stays running.
When an error occurs in your application Ruby is usually trying to tell you something. Having a way to collect the messages (errors) in your application will help pinpoint stability problems and the bugs that cause them. We use a tracking tool called Honeybadgerto help us out. An error occurs and we get notified with the details and a path to fix the issue.
It can happen that your application has a small team, maybe even a single developer, and suddenly a the key person is no longer available. You lose:
A plan should be in place, an insurance policy if you will, to keep moving when someone leaves. It could include aligning your company with a Ruby on Rails company who has the ability come up-to-speed quickly, is part of the ongoing development and be able to create a knowledge base for future developers. Mitigate risk.
Future posts I will provide guidance how you can address each of these issues and how to use the tools.
The bottom line is; your Ruby on Rails application can be fixed. New life can be breathed into it, but you have to know where to look and which tools to use. Of course knowing how to use the tools helps as well. Not everyone has the desire to crack open the code or dig into the running application to find places to tune.
We do provide a service we call Rails Rescues. This service helps a business address these problems. If interested, please take a look and contact me with any questions.
Tags: rails rescues, ruby, ruby on rails