I work for Demandbase, a B2B marketing company, we help our client to identify the companies who visited their online properties.

We were using resque before, because of the nature of forking, the memory and compute power is a big cost for us. So we switched to sidekiq soon after you released it. And we love it.

We’re using it in several projects, this screenshot is just one of them, a larger one of course. This sidekiq cluster handles the aggregation of realtime traffic for some clients. There’re two major sidekiq workers, one normalizes the traffic, another one updates all the aggregation counts. Every task is very small and fast, and sidekiq is a perfect tool for it.

There’re 4 sidekiq worker servers, and every one has 4 processes which every one has 25 workers. As we are all on EC2, we use spot instances for part of the cluster so we can add more workers as needed, so it could grow up from 400 to 800 or more.

The technology is nothing special but solid, Rails + Redis + Sharded MySQL.

Thanks Libin and everyone else who entered. I hope Sidekiq Pro makes your system even better!

Today I decided to pull the trigger and call it 1.0! I’ve moved the Sidekiq Pro changelog to the sidekiq repo for better visibility for all Sidekiq users. Watsi, Litmus, Customer.io and Travis-CI are just a few of the companies that have upgraded to Pro.

To celebrate the 1.0 release, I’m giving away one free license to an existing Sidekiq user! All you have to do is tweet an image of your current dashboard “Processed” count and say you want Sidekiq Pro. Here’s The Clymb’s dashboard:

Example: “.@AcmeCorp wants Sidekiq Pro! http://example.org/dashboard.png”

A few days from now, I’ll collect all the tweets and draw one at random from a hat. Good luck!

In the Web UI, the Workers page shows you a listing of all worker status entries in Redis. When a Worker starts processing a job, it adds a status entry to Redis. When the job is complete, the worker removes its entry from Redis. If you see one or more entries linger for much longer, this is a symptom of a bigger problem:

1. The worker thread has locked up or is blocked by some other issue
2. The Sidekiq process crashed

Log into the host noted in the list and look for the process with the PID. If the PID exists, the job is probably locked up somehow. Send the TTIN signal to Sidekiq to print a thread dump which should give you an idea where the job is stuck. Modify your code as necessary to fix the issue.

If the PID is gone, the process crashed, the worker dies and the status entry is orphaned in Redis. A Ruby process can crash due to bugs in either the Ruby VM itself or in a native extension your application is using.

Process crashes can be a serious problem: any jobs executing during the crash are lost. Unless the jobs are optional, you probably want to stop the job loss ASAP and here you have two solutions: spend time or money to stop the loss. If you have time you can find a core dump, use gdb to get a backtrace and start investigating the code at fault. Debugging a crashed process is a highly technical subject and not something that I can really cover adequately in a blog post.

Alternatively, you can buy Sidekiq Pro and use its reliable queueing feature. I spoke with a Sidekiq user at Railsconf whose processes were crashing and losing jobs. They jumped at the chance: rather than spending days tracking down the bug, they could live with a crash once or twice a day since Upstart would just restart the process and immediately resume the job. It’s not the ideal solution but it stopped the loss of jobs and put out the immediate fire: now they could debug the issue at their leisure rather than needing to fix it ASAP.

You are invited to a whimsical evening of merriment and gamesmanship!

What: Board Games and Beverages
Where: Skyroom Lounge, top of Red Lion Hotel, across the street from Railsconf
When: Tuesday, 4/30 7-11pm

The Skyroom has a great view of Portland so try to get there before sundown. We should have enough games for everyone but bring your favorite if you’d like. They have food if you need a late dinner. They have room for 250 so I’m hoping we’ll have plenty of room for everyone.

If you’re in, please comment to RSVP!

Sunday 4/28

KidsCodeCamp, 10am-4pm, Multnomah Arts Center
PlanetArgon.com Gorge Hike, 12:30-6:30pm, meet at Convention Center

Monday 4/29

Tech Women’s Communities Social, 7-9pm, NewRelic HQ
Code Fellows Happy Hour, 7:30-9:30pm, Rontoms
ZenCoder and SendGrid Party, 7:30-9:30pm, Ground Kontrol
Pivotal Labs Mixer, 9-11pm, Spirit of ’77

Tuesday 4/30

RailsConf Run 1, 7am, Steel Bridge
Board Games and Beverages, 7-11pm, Skyroom Lounge
A Night in the Ruby Sky, 7:30-10:30pm, NewRelic HQ

Wednesday 5/1

Railsconf Bike Ride, 6:45pm
CodeClimate Drinkup, 6pm, Green Dragon
Kickstarter Meetup, 7pm, Dig a Pony
EngineYard / Elemental After Party, 7:30-10pm, Elemental Office
Lumosity Party (pw: lumos), 8:30-11:30pm, Spirit of ’77

Thursday 5/2

RailsConf Run 2, 7am, MAX Zoo Station

It turns out that Ruby 2.0 locks down what you can do in a signal handler in order to prevent unsafe or possibly non-deterministic behavior. You can’t take a Mutex within a signal handler anymore as this could result in a thread context switch or even deadlock. In fact you can’t even write to a Logger because it tries to use a Mutex internally.

I rewrote the signal handling to conform with the new restrictions: all handlers now just push the name of the signal onto a global array and the main thread polls once per second for unhandled signals. This isn’t perfect, polling is something to be avoided where possible, but I don’t know of a better solution and it’s a lot better than the previous “fat” handlers that did a lot of work.

40 hours / week * 50 weeks / year = 2000 hr / yr

Bill Gates is worth about $66 billion. He’s worked for about 33 years now.

66 billion / 33 years = $2 billion/year / 2000 = $1 million / hour.

Bill Gates has made roughly $1 million per hour over the length of his career. Most people would be happy to make that amount in a decade. No moral or judgment here, just an astonishing number to think about.

• 214,300 downloads
• 2,144 watchers
• 662 closed issues
• 266 forks
• 228 closed pull requests
• 44 versions released
• 1 Major Award™

Sidekiq Pro has been available for four months now and sales have ramped up as Sidekiq gained traction, exactly like I had hoped. January was my biggest sales month so far. Thank you to my Pro customers!

My goal for the first year was to become one of the big three: I wanted people to see Sidekiq as a peer to Resque and Delayed Job. I think that’s true now and believe Sidekiq has matched Delayed Job in terms of project velocity. For the next year, my goal is to overtake Resque and make Sidekiq the #1 background job library for Ruby. There will always be a place for other libraries for various reasons (e.g. redis not available) but I believe Sidekiq’s great performance and wide range of functionality can’t be beat by any competing library today.

It’s been fantastic working with new contributors, noticing more and more people recommend Sidekiq to their friends and seeing my vision of simple, efficient background processing becoming reality. I promise to continue support for Sidekiq and hope this year goes just as well as the first!

Some context for you: I was employee 33 and the third engineer to join. The test suite had hundreds of failures and had been running red for months. We were on REE, Rails 2.3 and Delayed Job – a stack that was current two years before – and had no error service to know what errors were happening in production. The site was deployed with fabric, a Python-based tool. The first two developers were overworked and fought fires all day, every day.

My first task was to upgrade our entire site infrastructure to state of the art but I also did my best to bring some sanity to our process. My first two weeks were spent just getting the test suite running green so I could start the upgrade process with some way to verify correctness. The entire upgrade process took me six weeks. Today we’re on Rails 3.2, Ruby 1.9.3 and Sidekiq Pro with help from Travis-CI Pro, Honeybadger, Librato Metrics, Papertrail and capistrano. We took to using GitHub pull requests like a fish takes to water – the peer code review has made a marked improvement in code quality. It took about 3 months but we slowly fought fires less and less every day.

Over the last year we’ve added major new functionality, including:

• Complete UI overhaul for a great experience on phones and tablets
• Clymb 365 stores with popular products all year around
• Overhauled shopping cart and checkout process
• Adventures and other “non-traditional” product types
• Multiple images per product
• Waitlist for sold out products
• Overnight, 2 and 3 day shipping options
• And huge improvements to our inventory, returns and administration backends

We’ve grown to 90 employees with 8 full time engineers and 2 more part time contractors. We now have dedicated teams for site infrastructure (aka devops), product development and business intelligence (aka analytics). If you’re in Portland*, interested in one of those areas and in joining a rapidly growing company, contact me (mike @ theclymb.com). I’m really excited for what the next year will hold.

* Unfortunately we can’t hire remote employees because it legally requires us to charge sales tax in those states.

The ranking is based on activity, contributors, pull requests and other factors so I literally could not have done this without those who used Sidekiq, sent PRs and entered issues. Thank you to Black Duck and all my users for using and believing in Sidekiq; I hope to make 2013 just as amazing!