Posted by Nick Sieger
Wed, 23 May 2007 05:51:36 GMT
I was fortunate to be in town right after RailsConf and attended the inaugural geekSessions event on Rails scalibility. The event went off without a hitch: it was well attended, City Club is a classy place, and there was decent food and an open bar. I don’t know the SF geek/startup scene, but pretty much all of the few guys I know were there along with a ton of other folks. My only complaint would have been to let it run at least 30 minutes longer. Socializing was good too, but it seemed like the conversation was just getting started.
Here are some notes for you in my typical rapid-fire style -- hope they’re useful to you.
Case study: divine caroline
- Load balancer
- Apache + mongrel
Ruby is slow. Rails is slow. Unoptimized app was slow -- 7 pages/sec with
ab. So how can Rails possibly be? 150 pv/s with a simple text render. This formed a sort of upper-bound, that ruled out fragment/action/partial caching, etc. This brought the throughput to 3500 pv/s. Except for page caching limitations:
- Cache coherency
- Writes are more expensive
- Page caching is not applicable to as many pages as you think
But measure first. Pivotal built a drop-in page caching extension to deal with cache coherency issues (soon to be at http://rubyforge.org/projects/pivotalrb)
Jason somehow has the distinction of the first four commits in the Rails repository. Joyent/TextDrive/Strongspace.
If your application is successful, you’re going to have a lot of machines. What happens when you have 1000s of machines, 100s of TB, 4 locations, etc. Is this really a Rails issue? In a typical Joyent setup, Rails is only one of 26+ processes on the server stack. So scaling it really doesn’t mean much more than scaling any application. Object creation in Ruby is fast, sockets and threads are slow. So forget sockets and threads.
Instead, use DNS, load balancers, evented mongrels, JRuby/Java, DBMSes (not just RDBMS; LDAP, filesystem, etc.), Rails process doing Rails only, static assets going through a static server, federate and separate as much as you can.
Jeremy’s job is about safety nets; about knowing the underlying infrastructure. Is the hardware/OS/stack important? Can you build safety nets around those so that you can spare cycles when you need to intrude into the system to troubleshoot?
Twitter is in a unique position with the volume of traffic to be able to find some pretty tough bugs, like the recent backtrace issue.
Measure first! Like Ian said. Is software information? Or a machine? It’s both. Nothing else in human existence can claim this. 3 weeks after Bryan joined Sun, he was working with Jeff (ZFS architect) debugging an issue when Jeff retorted, “Does it bother you that none of this exists? It’s just a representation of some plastic and metal morass in a backroom” (slightly paraphrased).
We’ve been living with bifurcated code -- “if DEBUG; print something” ad nauseum. But this has a cost. So dev code deviates from production code. But we can’t get the data we want, where it matters, in production. Bryan goes on to describe the aforementioned backtrace issue and how it saved Twitter 33% CPU. So don’t pre-optimize, but you’ve got to be prepared to go get the data. In production.
Q & A
What’s the best way to move from one database to two databases (MySQL), when you scale past the volume of reads that overwhelms one?
Jason doesn’t like the replication approach, it’s not fault tolerant. Reference to Dr Nic’s magic multi-connections gem. Reference to acts_as_readonly. Don’t rely on things that are out of your control, start reading/writing to multiple locations, at the application level. Jeremy: So do you want to be in the business of writing SQL or C extensions to Rails? What about MySQL proxy? Seems ok, but I might not trust it in production. MyTop/InnoTop will tell you about your query volume.
Virtualization: 4 virtual servers w/ web servers on top of a single physical server? Why?
Jason: Free BSD 4.9 on early pentium was the perfect balance of utilization. 18 CPUs by 64G RAM with virtual servers gets us back to that level of utilization. Bryan: Not all virtualization solutions are equivalent! (Solaris containers/zones plug.)
RDBMSes are not good for web applications? Why? Can you give some examples?
Jason: It depends on when you want to join. When people are clicking, or pre-assembled. Look at your application and put the data together before people request it. Why does YouTube need an RDBMS? It serves a file that people can comment on.
Mention of Dabble DB, ZFS, Jabber, Atom, Atom over Jabber, etc. as ways of innovative ways of storing objects, data, etc. GData/GCal most certainly does not store its Atom files in an RDBMS.
Sell Rails apps and have the customer deploy it? What options are available?
Ian: JRuby on Rails with a .war file is an interesting approach. What operational issues/ways to help with scaling remote deployments? Jeremy: Log files are the first line of defense. Jason: Corporate IT are comfortable with Java.
The pessimist in me says that my servers are going to fall over after 5 users. How can I be prepared/not be optimistic about a traffic spike?
Ian: Load test the crap out of the app. Find out the horizontal scaling point. Use solutions like S3 for images. Make sure you can scale by throwing hardware at it. Eventually single points of failure will overcome you (such as a single database), but you can wait until you get to that point before doing something about it.
Jason: You can benchmark your processes, and get an idea of what they can do. Most people that want to do something will be look at your stuff, and maybe signup. So front-load and optimize your signup process, possibly by taking it out of Rails.
Jeremy: Conversations with Zed, DHH, etc. have pointed out that sometimes “Rails isn’t good at that, take it out of Rails.” Same thing for the database. Split those things out into a different application.
Bryan: Do your dry land work, know your toolchain, so that when the moment comes, you can dive in and find the problem.
We have a migration that takes a week to run because of text processing. GC was running after every 10th DB statement. Used Rails bench GC patch to overcome the issue with the migration. Any issue running these?
Jason: We run those GC modifications and a few more in production, and they’re fine.
Most comversations revolve around items like database is slow, or Ruby is slow. How can we use DTrace to streamline the process?
Jeremy: We spent 20 minutes over lunch (plus some preparation) to find a Memcache issue. It’s worth it to spend a little time to learn the tool.
Bryan: “Awk is God’s gift to all of us.” When DTrace was being reviewed inside of Sun, folks commented “This reminds us of awk.” “Thanks!”
Jason: We’re putting a tracing plugin in Rails as a remote process to collect data from a running app. Apple has shown a commitment to get this in Leopard. Textual and graphical output are possible. I believe in DTrace a lot, and the tooling and documentation will go beyond its current state of an experts tool.
Lastly, what one closing thing would you like to say about Rails scalability?
Jason: Don’t use relational databases.
Jeremy: I thought it was a Joyent sales pitch.
Bryan: Use DTrace (with Joyent accelerators of course).
Tags rails, ruby | 2 comments | no trackbacks
Posted by Nick Sieger
Thu, 17 May 2007 17:35:00 GMT
Just a quick update. Firstly, I just released ci_reporter 1.3; it should be available in the gem index shortly. Thanks to Bret Pettichord, Jeremy Beheler, and Charlie Kunz for reporting issues and prodding me to fix a couple of bugs. The two new items in this release are:
- RSpec 0.9/trunk-compatible. You can now
describe/it all you want with ci_reporter.
- Errors and failure stack traces now include the full error message and exception type.
Secondly, JRuby 1.0RC2 has been released. Although there is no official release announcement at the moment, it is available for download and has been propagated to the central Maven repository also. Please do check it out and let us know on the mailing lists or in JIRA if you come across any blocker issues or regressions. Just a couple more weeks of stabilization; expect a rockin’ 1.0 release in June!
Lastly, expect an ActiveRecord-JDBC 0.3.2 release Real Soon Now.
Tags continuousintegration, jruby, railsconf, railsconf2007, ruby | no comments | no trackbacks
Posted by Nick Sieger
Fri, 20 Apr 2007 15:01:08 GMT
So, on somewhat late notice due to a miscommunication, I’ve been asked to step in and give a talk on JRuby at the SDForum Silicon Valley Ruby Conference this Sunday the 22nd. This, in addition to my already-scheduled talk at GoRuCo! JRuby makes an appearance on both coasts in a single busy weekend!
Due to schedule shuffling, I’ll be sharing a 75-minute time slot in the morning with Tor Norbye, who will be giving a talk on Ruby tooling featuring NetBeans.
Tags goruco, jruby, ruby, sdforum, svrc | 1 comment | no trackbacks
Posted by Nick Sieger
Sat, 24 Mar 2007 04:41:00 GMT
Hey! I’ve been so excited and busy at the same time I forgot to mention I’ll be speaking at the Gotham Ruby Conference on April 21st in NYC located at the Googleplex in Chelsea. Hopefully you’ve got your ticket by now, as last I heard there were only a couple of tickets left. You’ll hear me giving the JRuby pitch: Ruby on the best VM on the planet, performance updates, deploying Rails by dropping a file in a Java webserver, and more. Looking forward to carousing with the fine Rubyists in the Tri-State Metro area! Manhattan was my provenance in 1997-1999, where I had my first programming gig out of college, so I feel like I’m coming back to where I got started, in a way.
Only downer -- I’ll miss the second incarnation of Minnebar, which was a blast last year. If you’re near the Twin Cities that weekend you owe it to yourself to attend.
Tags goruco, jruby, minnebar, ruby | 1 comment | no trackbacks
Posted by Nick Sieger
Tue, 06 Mar 2007 03:58:00 GMT
ActiveRecord-JDBC version 0.2.3 has been released!
Use JRuby to install the gem into your JRuby installation as follows. Currently, Rails is not a dependency of ActiveRecord-JDBC; it is assumed you’re going to have Rails installed already.
$ jruby --command gem install ActiveRecord-JDBC
Successfully installed ActiveRecord-JDBC-0.2.3
Installing ri documentation for ActiveRecord-JDBC-0.2.3...
Installing RDoc documentation for ActiveRecord-JDBC-0.2.3...
See the new RDoc documentation on Rubyforge for more information on how to use ActiveRecord-JDBC. If you’re grabbing the new JRuby 0.9.8 release, be sure you get this one as well if you plan to try out JRuby on Rails.
- Release coincides (and compatible) with JRuby 0.9.8 release
- 8 bugs fixed
- Improvements and compatibility fixes for Rails 1.2.x
Comments, questions, test cases, patches and all that are welcome over on the jruby-extras mailing list.
Tags jruby, ruby, rubygems | 6 comments | no trackbacks
Posted by Nick Sieger
Tue, 06 Mar 2007 02:51:35 GMT
JRuby 0.9.8 is hot! With the release of JRuby 0.9.8, the countdown begins. The reason we jumped from 0.9.2 up to 0.9.8 are several:
- Now there are only two more releases to 1.0, with 1.0 landing in May.
- This release fixes more issues, has more changesets, improves performance, etc. etc. etc., more than all the other 0.9.x releases combined.
- Rails support is something to feel good about, more than a single point release for sure
Stay tuned for details on the new release in the coming days. Be sure to download JRuby 0.9.8 today (source) and let us know how it goes!
Tags jruby, ruby | no comments | no trackbacks
Posted by Nick Sieger
Thu, 15 Feb 2007 05:04:40 GMT
As requested, CI::Reporter has been released as a gem version of my Rails plugin version. Follow these instructions for installing the new gem version.
For the uninitiated, CI::Reporter is an add-on to Test::Unit and RSpec that allows you to generate XML reports of your test and/or spec runs. The resulting files can be read by a continuous integration system that understands Ant’s JUnit report XML format, thus allowing your CI system to track test/spec successes and failures.
The old Rails plugin code is still in the previous location, but I don’t plan to do anything else with it so I encourage you to install the gem and use the new lean-and-mean plugin that depends on it.
At the time of the post, the gem is hot off the presses, so it may take a little bit for it to hit the gem index and mirrors. Let me know if it works for you!
Tags continuousintegration, ruby | 7 comments | no trackbacks
Posted by Nick Sieger
Tue, 30 Jan 2007 02:16:00 GMT
I know there has been some demand out there for a version of my RSpec Autotest Rails plugin that works with standalone (non-Rails) projects, so I finally caved and coded it up. I really hope this does finally get accepted as a patch to ZenTest (nudge, nudge), but until it gets a more standard release, do try it out:
- Ensure you have ZenTest installed (
gem install ZenTest).
- Download the rspec_autotest.rb file here and put it in the
spec directory of your project.
- Add this snippet of code into your
rake spec:autotest as usual.
namespace :spec do
task :autotest do
Once again, happy spec’ing, and let me know of any issues you have with it.
Tags autotest, rspec, ruby | 1 comment | no trackbacks
Posted by Nick Sieger
Tue, 30 Jan 2007 01:52:04 GMT
This is part 5 in our ongoing conversation tracking the development of JRuby.
As part of the Worldwide Groovy 1.0 Release Party Day, we at the JRuby team tip our hats in celebration and give our thoughts on our sibling JVM dynlang.
Another recent announcement is that of Groovy finally hitting the 1.0 milestone. What do you make of this -- what goals do you have in common with the Groovy effort, but also, where do you diverge?
Thomas Enebo: I think it is great that Groovy released their 1.0. That number is an important mystical number that affects people in various ways and probably most importantly tells the world that you think it is ready for production work. I am sure Groovy has been at this point for quite a while so it is good to see the project endorse themselves like this.
Groovy, like JRuby, is about providing another choice on the JVM for solving problems. I think the ramifications of this statement yield most of what we have in common.
We differ largely by the fact that we are making an alternative implementation of a language while they started their language from scratch. The fact that we need to bridge two languages that were designed in isolation from each other generally reflects our differences. We get a set of libraries and applications from this other community while they need to create their own community and value-adds. They had the freedom to make integration with Java jive better while we need to cope with the various differences between Ruby and Java. Both directions yield postives and negatives.
Ola Bini: Well, it’s very nice to see JVM-languages mature. I’m not sure exactly what this 1.0-release actually entails, but we in the JVM language league are in this together, and the progress of one language is good for everyone. The goals that we have in common is first and foremost to improve the Java integration aspect in such ways that it will be easy for both Ruby and Java developers to use it intuitively, preferably in a more succinct and readable way than corresponding Java-code. But we diverge in what we’re willing to do to achieve that. JRuby is a Ruby implementation first and foremost, which means the only things we add are things that can be implemented in Ruby (except for those base Java primitives needed to get it up and running).
Charles Nutter: I think one are we hold in common is that neither of us believe Java is enough of a language to solve all problems. Groovy offers a different perspective on language design, adding many dynamic-style language features on top of a syntax that’s mostly just Java. You can use types or not, use semicolons or not. They have similar literal syntax for lists and maps, similar closure semantics, and in some ways a similar feel to other dynamic languages. For folks that fear moving away from Java or need to know their code compiles down to Java classes and integrates intimately with Java class hierarchies, Groovy is a great way to go. It’s excellent that they finally got their 1.0 release out, and as Ola mentioned it shows that dynamic languages are making their presence known in a big way.
We diverge in that Groovy is certainly not Ruby.
In our work on JRuby, we’ve taken an alternative approach from Groovy, in that we believe Ruby is a better language than we could design ourselves (or design based on Java with dynlang features) and so we aim to support pure Ruby as closely as possible. This limits us somewhat in our ability to tightly integrate with Java classes and Java’s type hierarchies, but it also frees us to do all the amazing things you can do with open classes, metaprogramming, DSLs, and the like.
Another area we differ from Groovy is in the size of the greater Ruby community. There are many thousands of people worldwide using Ruby right now, dozens of conferences devoted to Ruby and Ruby on Rails, and a growing library of books on the same. The Groovy guys have a challenge ahead of them to build a community around a very young language; I hope we can help them get there!
Tags groovy, jruby, jrubyserialinterview, ruby | no comments | no trackbacks
Posted by Nick Sieger
Thu, 25 Jan 2007 04:23:00 GMT
This is part 4 in our ongoing conversation tracking the development of JRuby.
This episode we’re pleased to have Tor Norbye and Martin Krauskopf from Sun with us to discuss NetBeans.
If you’re a Rubyist, why should you care about NetBeans? Isn’t that one of those big honkin’ Java IDEs? Well, due to the hard work of Tor and Martin, NetBeans will soon be a world-class Ruby and Rails editor and development environment. All made possible by JRuby underneath the hood. Don’t believe me? Then read on...
So, what are you hoping to accomplish with NetBeans Ruby support? Any lofty goals? Is your target audience Ruby hackers, or Java programmers looking to try something new?
Tor Norbye: Anybody writing code using Ruby. That would include both experienced Ruby developers as well as newbies trying out the language.
The lofty goal is to provide First Class Support for Ruby such that where possible, the Ruby support is as good as the Java support. There are obviously areas where Ruby’s dynamic nature makes it hard to provide the same features as those available for Java, such as the various refactoring operations and quickfix features that rely on static typing. But that doesn’t mean we won’t try. I think a Rename refactoring operation that has some limitations is still better than just Search/Replace.
That’s the area I’m most excited about getting into. Until now I’ve been working on getting all the basic IDE infrastructure in place such that the vital parts are there and we can start building more smarts on top.
Martin Krauskopf: Simply the target is the full debugging support in NetBeans like it is in RDT. I contacted Chris (Williams), Markus (Barchfeld) and murphee (Werner Schuster) from RDT regarding cooperation on the backends. Realize that actually backends are currently their effort on which they’ve spent a lot of time. I’ve started with some mini-fixes and would like to continue on the cooperation more and more so they will also get something back. But the cooperation is very young so I’ll have more to say later, I think. So however there are still a lot of work on NetBeans frontend I want to get as much as possible also in the backends works.
Thomas Enebo: Martin just sent an interesting email to the RDT list on a debugging specification and a cross IDE debugger project on Rubyforge....Fun times.
NetBeans Ruby support (click through the image for a full-screen shot). There is
test/unit output, and you can see completion of class names with an RDoc popup.
When will we see a public release of NetBeans Ruby support? What are some of the features we can expect to see? Will there be Rails support?
Tor Norbye: I wish I could answer when it’s going to be released, but that’s not in my hands. I started the work in closed source, as part of the Project Semplice work. And when code doesn’t start in open source in the first place, there’s a Sun process to be followed to release it, such as a legal review, etc. etc. It’s going through that process now - and has been for quite a while, so I’m hoping it will be released soon, very soon. Without promising anything obviously, think weeks.
As I said earlier, the goal for the feature list is to offer the same features that are available for Java: good editing, projects support, debugging, web application support, etc. Yes, there will be Rails support.
The current feature set, which is what you’d see if I got the green light to commit into NetBeans CVS today, is heavy on editing support. There is semantic highlighting, code completion, various other editing features such as pair-matching, smart indent, etc. There is also some basic projects support and Rails support. My coworker Martin Krauskopf is working on a debugger and that work is coming along nicely.
NetBeans Rails support (click through the image for a full-screen shot). RHTML editing, project tree and generator access are shown.
I’ve got this killer feature idea for a Ruby editor. How can I get it into NetBeans?
Tor Norbye: Well, it will all be open source, so the easiest way to do it would be to join the NetBeans open source project and enhance the Ruby editor directly. NetBeans itself obviously has lots of extensibility APIs, and the Ruby editor may offer its own to register additional quickfixes etc. At this point that has not been my focus.
Thanks to Tor and Martin for joining us! For up-to-date progress on Ruby support in NetBeans, follow along on Tor’s blog. And if you have further questions, please leave a comment. What would you like to see in NetBeans Ruby support?
Tags jruby, jrubyserialinterview, netbeans, ruby | no comments | no trackbacks