Saying Hi
Galtenberg
Kicking myself for not having joined earlier. Name is Chris, working
for Gaiam on the Gaia social network (formerly Zaadz), built entirely
on Rails. I'm one of the lead developers, on a team of 6 Rails devs
(four working in our Louisville office, two working remotely). We've
been around since '06, edging up now on 200,000 users. Feeling a bit
of pain as we grow, but my gut says it's mysql... we're not yet at the
Twitter level of hurt, and hope to never be. (If you're a performance
semi-guru and/or mysql stud, we have an opening.)
Have been living in the area since November (worked remotely before
that). Am based right now in the Golden Triangle area (tho prices are
making the drive untenable). Writing a book of philosophy off-
hours... when I can be pried off my Kindle :)
Would love to talk Rails shop and/or philosophy and/or politics, at
regular meetings, or any other time. Will see you then!
Cheers all,
Christopher Galtenberg
http://chris.gaia.com
Brittney Pusheck
Peter Jones
> Kicking myself for not having joined earlier. Name is Chris, working
> for Gaiam on the Gaia social network (formerly Zaadz), built entirely
> on Rails.
Welcome to DeRailed Chris.
> I'm one of the lead developers, on a team of 6 Rails devs (four
> working in our Louisville office, two working remotely).
Where is your office in Louisville? I have an office on Pine & Front
St. I'd love to stop in and talk shop sometime, there aren't a lot of
Ruby programmers in the area AFAIK.
--
Peter Jones, pmade inc.
http://pmade.com
Dan Mayer
Good to here from you. I just checked out Gaiam, that is pretty
interesting. I hadn't really heard of it before, but I think I have
stumbled onto it at least once before. That is a pretty large user
base that is slamming the rails/mysql setup. Welcome to the group,
hope to see you at a meeting sometime. I think it will be hard for me
to make it much anymore as I just moved to Boulder, but I am hoping to
visit once in awhile.
peace,
Dan
On Sun, Jun 1, 2008 at 11:51 AM, Galtenberg <galte...@gmail.com> wrote:
>
--
Dan Mayer
Co-founder, Devver
(http://devverlabs.com)
Co-creator, Seekler (http://seekler.com)
My Blog (http://mayerdan.com)
Marty Haught
We have a pretty healthy Ruby and Rails community here in the Front
Range area. I was actually talking with some others on the light rail
in Portland after RailsConf was over about local user groups.
Apparently L.A. and New York have weak/non existent Ruby/Rails
gatherings. We have two vibrant groups that meet monthly. I've
stopped mentioning anything about the Boulder Ruby group
(http://boulderruby.org) here figuring you all know about it but I
shouldn't assume that newer members would know. There are several of
us that attend both groups. Anyway, if you find yourself up near
Boulder, you're welcome to drop in on us.
As for your performance bottlenecks, there are a number of things you
can do. While there are some no-brainer steps you can take to make
your app 'scale', it's never that simple. You really need to figure
out where your pain points are. It could be just general load issues
or a couple trouble spots that are dragging the entire system down.
I'm not sure how skilled your team is but having your app reviewed by
an expert Rails guy wouldn't be a bad idea either. It comes down to
how much money you want to throw at it or if you want to do this
internally.
Cheers,
Marty
Kevin Weller
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "DeRailed - Denver Rails UG" group.
To post to this group, send email to dera...@googlegroups.com
To unsubscribe from this group, send email to derailed-u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/derailed?hl=en
-~----------~----~----~----~------~----~------~--~---
Tom Anderson
As for your performance issues with MySQL, 3 things come to mind. First, make sure you have indexes on the columns that are most often referenced in where clauses. Second, use eager loading of associated objects using the :include option to find. Third, avoid running queries that return the same results each time using caching.
Those 3 things are the easiest to do without getting into the database internals. You may have already done all of them but I thought it would be worth mentioning.
~Tom
Welcome Christopher,As for your performance issues with MySQL, 3 things come to mind. First, make sure you have indexes on the columns that are most often referenced in where clauses. Second, use eager loading of associated objects using the :include option to find. Third, avoid running queries that return the same results each time using caching.Those 3 things are the easiest to do without getting into the database internals. You may have already done all of them but I thought it would be worth mentioning.~Tom
On Jun 1, 2008, at 11:51 AM, Galtenberg wrote:
Peter Jones
> As for your performance issues with MySQL, 3 things come to mind. First,
> make sure you have indexes on the columns that are most often referenced in
> where clauses.
Of course, you should only index tables that have a high read to write
ratio. If you're doing a lot of inserts or updates to that table, the
indexes will actually slow things down.
In my experience, Rails applications are usually slow because
inefficient use of the database. Like Tom said, make sure that a
single page load isn't performing 6 million queries, and look into
caching data that doesn't change very often.
Marty Haught
> ratio. If you're doing a lot of inserts or updates to that table, the
> indexes will actually slow things down.
>
> In my experience, Rails applications are usually slow because
> inefficient use of the database. Like Tom said, make sure that a
> single page load isn't performing 6 million queries, and look into
> caching data that doesn't change very often.
Echoing Peter's comments, this is very true. While some of the things
mentioned are generally true, I'd say that before you start making any
changes to need to get benchmarks. You'll need these numbers to
measure your improvements. I've done several rounds of performance
tuning in our project now and each time things that I was sure were
the problem weren't while other things that I was unaware of were.
Having a test dataset, whether as a clone of production or something
you generate is vital. With a test environment and benchmark dataset
you can start to really look closely at each page and see where the
problem lies. You can then start to make changes here and there and
have confidence on which steps helped the most. Sometimes just
watching the debug log of DB activity can be so telling.
Cheers,
Marty
Paul Dix
vibrant Ruby community. The first match for nyc+ruby on google brings
up our site (http://www.google.com/search?q=nyc+ruby). The issue with
getting new people in NYC is that many of them only think of going to
Meetup.com, which is big here since it's local. We don't use it
because it's fee based and our group predates the site.
We meet twice a month with the first being a hackfest and the second
being a regular presentation meeting. The presentation meeting
usually gets between 20 - 40 attendees. We've also had the Gotham
Ruby Conference for the last two years, which some consider as being
one of the good regional conferences.
Given the size of New York we should probably have a larger group.
However, we do have a good group of people. Zed wrote Mongrel while
working here in NYC. Two of the contributing authors to The Rails Way
are regular attendees.
If any of you are ever in NYC you should drop us a line and meet up!
Best,
Paul
Marty Haught
> vibrant Ruby community. The first match for nyc+ruby on google brings
> up our site (http://www.google.com/search?q=nyc+ruby). The issue with
> getting new people in NYC is that many of them only think of going to
> Meetup.com, which is big here since it's local. We don't use it
> because it's fee based and our group predates the site.
Glad to hear it Paul. Yeah, those were the comments from two guys
from the East Coast on the train. Perhaps it is an issue with
perception and getting out the word.
> We meet twice a month with the first being a hackfest and the second
> being a regular presentation meeting. The presentation meeting
> usually gets between 20 - 40 attendees. We've also had the Gotham
> Ruby Conference for the last two years, which some consider as being
> one of the good regional conferences.
>
> Given the size of New York we should probably have a larger group.
> However, we do have a good group of people. Zed wrote Mongrel while
> working here in NYC. Two of the contributing authors to The Rails Way
> are regular attendees.
I've heard good things about GoRuCo. Matter of fact, there are many
regional Ruby conferences that are really good not even taking into
account the significantly lower cost to attend.
One interesting thing about this is the Denver Metro, which sports
around 2.5 million people has two local Ruby-based groups that have
monthly attendance in the 20-40 realm regularly. There are a many
much larger communities that can't say that. You would think NY with
over 18 million people we have larger meetings, or at least multiple
groups. Go figure. So maybe I should say that Denver has a
surprisingly active Ruby community for its size. :) Maybe it's a
cultural thing where more of the Colorado guys have networked together
and like to meet more so than people in the really large metro areas.
> If any of you are ever in NYC you should drop us a line and meet up!
Thanks for the invite. Vice versa, if you're ever in the Denver metro
there are two groups you can meet up with.
Cheers,
Marty
Galtenberg
Sorry to be late in reply.
The Louisville office of Gaiam is on S Boulder Rd close to McCaslin.
Next official meeting we can count heads and see who's in the area.
Count 3 more from my office. I'm sure we could paste something
together to chat and share more knowledge between meetings.
On performance stuff, much obliged. I think we did the basic perf
improvements post-release in 2007, and are now at the stage of needing
advanced improvements, really fine tuning the mysql engine and
continuing to knock down our slowest queries. If anyone has a
favorite blog or blog post on Rails performance, I'd def take a look.
Best wishes to everyone!
/c
PS. Here's my shared set of Ruby/Rails blogs, from Google Reader:
http://www.google.com/reader/shared/user/02622641982595535574/label/ruby
Bret Weinraub
You've gotten some good advice off of derailed ;) If you decide you want to go the next
level, or just want to set up a conference call with some of the principals re: your performance
issues, just let me know.
In general there are three main schools or "methods" of performance analysis:
* measurement - pick some metrics, baseline, alter some parameter, and re-test
* simulation - not that common industry wide; more common in mechanical and industrial engineering than in software
* analysis - kind of the stuff you are getting off of derailed; essentially (hopefully highly) educated guesswork.
Analysis is the most easy to perform, but is generally less successful than measurement. Managing
all the complexity that is introduced when people start "tweaking" things can be quite a chore, and it
pays not to loss a grip on it. In general I found over the years that anything that cuts down the complexity
of the problem is a win.
Your particular issue has some special quirks, to my mind:
* being on hosted hardware doesn't give you access to all the "knobs" (perf people call these parameters), even if
you wanted to start twiddling them
* constructing a meaningful performance testbed is going to be difficult, because it needs to as closely as possible
mimic your production environment.
* mongrel/rails doesn't seem to have a good load balancing solution (in my estimate). Ideally we want all sesssion
traffic to go to the same mongrel server, but because mongrel's single-threaded "blocking" nature this isn't feasible
and what you end up with is EVERY session loaded in EVERY server. Ouch. This might be what's driving your
database locking issue; or at least that's my hunch.
We're here if you need us ;)
take care,
bret
br...@ckuru.com
Peter Jones
> * mongrel/rails doesn't seem to have a good load balancing solution (in my
> estimate). Ideally we want all sesssion
> traffic to go to the same mongrel server, but because mongrel's
> single-threaded "blocking" nature this isn't feasible
> and what you end up with is EVERY session loaded in EVERY server. Ouch.
> This might be what's driving your
> database locking issue; or at least that's my hunch.
Bret, please elaborate on this. Specially, what are the performance
problems associated with a single user "session" being served by more
than one mongrel instance?