Skip to content

Instantly share code, notes, and snippets.

@kwleland
Last active October 18, 2015 18:40
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kwleland/47d042ff14fc72b6e1f6 to your computer and use it in GitHub Desktop.
Save kwleland/47d042ff14fc72b6e1f6 to your computer and use it in GitHub Desktop.
At Monmouth Telecom we provide high-availability cloud based telephone systems for medium to large companies. Because
we have written our own code in Ruby it is easy for us to customize or add additional features at the request of customers,
often at no charge, and that is key to our business.
Several years ago our engineering team developed a real time display panel for managers and operators alike that kept people
abreast of the status of phone extensions, conference bridges, and call queues, as well as allowing a variety of call control
features. We wrote this in ruby so that it would be easy to extend. The web display panel accesses customer data through
Active Record and is based on HTML5 with canvas and web sockets so it doesn’t require setup on the customer site.
Unsurprisingly it was one our more popular features and so we immediately started monitoring Rubinius as our migration path
for the day when one core of our 8 processor cores would become insufficient to meet demand. Well earlier this year the time
was upon us and we made the switch to Rubinius.
The port took some thought because even though the code was originally written with threading from the start, certain
shortcuts were taken that don’t work when the threading runtime is actually parallel. But the important thing was that the
changes were minor for us. We had a few containers that were infrequently accessed from multiple threads and mutexes were easy
to add for these without harming performance. We did have a memory leak, where we were leaking old threads, but here is where
the amazingly efficient and powerful built-in runtime instrumentation of Rubinius came to our quick rescue. We just turned on
the “statsd” information and sent it to a time-series database as described on the Rubinius website and the culprit was
identified and fixed in 6 hours without the addition of any debug code! I must also say here that the Rubinius team has been
both highly effective and kind in the way they have helped us and many others on the Gitter/Rubinius chat board and
Github-Rubinius/issues system as we have gone through our migrations or evaluations.
And today, our production realtime display app in Rubinius is a joy. Now each customer feels as though they have an entire
Xeon cpu core behind them when they do something a bit CPU intensive, albeit infrequent, like a screen resize. So our
previously fast app is now blazing and we estimate that we can scale over 20 times the traffic we have now on existing
hardware. The app is completely stable and consistent from the customer perspective and the cpu load and memory footprint are
stable as well.
Best of all we can continue to develop new services in Rubinius knowing that our future apps can scale seamlessly on servers
with ever greater numbers of cpu cores. Rubinius is truly a strategic part of Monmouth Telecom’s business future.
Ken Leland, CEO, Monmouth Telecom
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment