Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 16:59:00 GMT)

Reducing MySQL's memory usage on OS X Mavericks

Posted by Sun, 24 Nov 2013 15:22:00 GMT

Recently, I found myself re-installing everything from Homebrew and began to notice that MySQL was consuming nearly half a gig of memory. Given that I don’t do too much with MySQL on a regular basis, I opted to override a handful of default configuration options to reduce the memory footprint.

As you can see, a fresh MySQL install via homebrew was consuming over 400mb of memory.

Here is how I reduced my memory footprint:

$ mkdir -p /usr/local/etc

Unless you already have a custom MySQL config file, you will want to add one into this directory.

$ vim /usr/local/etc/my.cnf

We’ll then paste in the following options into our file… and save it.

  # Robby's MySQL overrides
  [mysqld]
  max_connections       = 10

  key_buffer_size       = 16K
  max_allowed_packet    = 1M
  table_open_cache      = 4
  sort_buffer_size      = 64K
  read_buffer_size      = 256K
  read_rnd_buffer_size  = 256K
  net_buffer_length     = 2K
  thread_stack          = 128K

Finally, we’ll restart MySQL.

$ mysql.server stop

If you have MySQL setup in launchctl, it should restart automatically. After I did this, my MySQL instance was now closer to 80mb.

So far, this has worked out quite well for my local Ruby on Rails development. Mileage may vary…

Having said that, how much memory are you now saving?

Setting Akamai Edge-Control headers with Ruby on Rails

Posted by Tue, 19 Jun 2012 04:54:00 GMT

Just a short and sweet little tip.

Several months ago we moved one of our clients over to Akamai’s Content Delivery Network (CDN). Ww were previously using a combination of Amazon S3 and CloudFront with some benefits, but we were finding several key areas of the world were not s covered by Amazon (yet) for asset delivery. Along with that, we really wanted to take advantage of the CDN for more of our HTML content with a lot of complex rules that related to geo-targeting and regionalization of content.

I’ll try to cover those topics in another post, but wanted to share a few tidbits of code that we are using to manage Akamai’s Edge-control caches from within our Rails application.

With Akamai, we’re able to tell their Edge servers whether it should hold on to the response so it can try to avoid an extra request to the origin (aka our Rails application). From Rails, we just added a few helper methods to our controllers so that we can litter our application with various expiration times.

  # Sets the headers for Akamai
  # acceptable formats include:
  #   1m, 10m, 90m, 2h, 5d
  def set_cache_control_for(maxage="20m")
    headers['Edge-control'] = "!no-store, max-age=#{maxage}"
  end

This allows us to do things like:

  class ProductsController < ApplicationController
    def show
      set_cache_control_for('4h')
      @product = Product.find(params[:id])
    end
  end

Then when Akamai gets a request for http://domain.com/products/20-foo-bar, it’ll try to keep a cached copy around for four hours before it hits our server again.

Rails Development Performance Tip - dev_mode_performance_fixes

Posted by Wed, 29 Aug 2007 01:57:00 GMT

When you’re running a Rails application in development mode, you might notice that it takes a little longer for requests to get processed and this is somewhat intentional as the framework is was designed to allow you to run the application and make live changes to it. This way you can do some basic functional tests from your web browser, work on HTML/CSS changes, or anything else that might need to be done in development mode.

Anyhow, this can be slow from time to time and if you’ve done much Ajax work, you might be familiar with how slow this can feel when performing some basic tasks. Well, thanks to Josh Goebel, we can speed up things with a new plugin he just released.

To install via piston:

cd vendor/plugins; piston import http://svn.techno-weenie.net/projects/plugins/dev_mode_performance_fixes/

To install via script/plugin:

./script/plugin install http://svn.techno-weenie.net/projects/plugins/dev_mode_performance_fixes/

Josh has posted some benchmarks and in my totally basic tests… shows about four times (4x) speed improvement for reqs/sec!

How does it work? From what I can tell, it works somewhat like autotest, in that keeps things cached and when it sees files modified, it re-caches the changes. He’s made it so that the stack doesn’t need to reload for each request, which is quite slow.

Since it’s development-mode only, I’d encourage you to install it and give it a whirl.

Have Fun!

YSlow and Rails performance: Getting UJS and AssetPackager to play nice

Posted by Fri, 27 Jul 2007 17:40:00 GMT

Yesterday, I started to dig deeper into YSlow and decided to pick an application that we recently launched for a client. The performance grade that I saw at first was an F, which wasn’t surprising to me because we knew that there was going to be some fine tuning in the near future.

There is a lot of JavaScript in this application and we have several files to break up stuff to make it more maintainable. However, in production, we really don’t need to send the client (browser) 19 different JS files. We’ve been using mod_deflate to compress these files, but it doesn’t solve the problem of having several connections opening to download all the necessary JavaScript. The same is true for our CSS files.

At RailsConf, DHH announced that an upcoming version of Rails would bundle all the stylesheet and javascript files into one file and compress it. We’re running on 1.2.x for this application and decided to look at the AssetPackager plugin as a good solution to this problem.

I installed the plugin via piston and ran the following task, which is provided by AssetPackager.

rake asset:packager:create_yml

This went ahead and created config/assets_packager.yml. I then went ahead and updated our capistrano configuration to call the rake task after updating the code on the server when deploying.


desc "all of our other tasks/commands to run after updating the code" 
task :after_update_code do
  #
  # all of our other tasks/commands
  #
  run "cd #{release_path} && rake RAILS_ENV=production asset:packager:build_all" 
end

The first thing that I noticed was that the yml file that gets generated will not make any assumption as to what order the javascript libraries should be loaded. So, immediately, line 1 of our compressed javascript file was causing an error as the code was trying to reference a library that hadn’t been defined yet (showed up later in the file). So, when you do this, you’ll need to organize the yml file to load things in order that they are needed. This was also a good opportunity for us to say, “oh, we’re not using that one anymore. Let’s remove it.”


--- 
javascripts: 
- base: 
  - prototype  
  - effects
  - scriptaculous
  - controls
  - dragdrop
  - application
  - slider
  - pngfix
  - nav
  - lowpro
  - lightbox
  - folder
  - builder

Great, so we re-dployed and everything at first glance seemed fine… or so we thought!

We used the unobtrusive javascript plugin for this project and it seems that we couldn’t just compress every single file. Each page has a behaviors javascript file and since everything was being compressed into one file (and cached), RJS calls quickly broke throughout the site. OH NO!

So, I opted to merge all of the other javascript files and use the standard way of including unobtrusive javascript in the application layout.


<%= javascript_include_merged :base %>
<%= javascript_include_tag :unobtrusive %>

We also removed lowpro from the list of javascript files to compress since the ujs plugin is currently including this when we call <%= javascript_include_tag :unobtrusive %>. I plan to look into modifying this so we it’ll only include the page-specific behaviors and not load the lowpro javascript file (so we can compress that as well).

Once this was re-deployed, we saw that the RJS issues were resolved and everything felt to be loading quicker. But, let’s look at YSlow again for step 1 in improving the performance of the application.

side note: the following grading was also after making some other adjustments that were suggested by YSlow, which I’ll discuss in another blog post soon.

So, where we once had a grade F, we now have an D… which is due to the client having us add several (four) external javascript files for mint, google analytics, etc. We’re only loading 3 javascript files for the application, when we were originally loading many more.

Obviously, there is some more tuning to be done, but we went from a grading of 43 to 74 in about three hours of time spent reading the YSlow documentation, adding asset_packager, and making various tweaks to our web servers (as suggested by YSlow).

Until next time…

Related Posts: