Forum: Rails deployment Fast drives vs. more memory/disk space

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Ca9b6b510b9d4536c5f3b52cadae316a?d=identicon&s=25 twr -- (thetawaverider)
on 2007-04-30 03:12

I currently have two options for my upcoming dedicated server, which
will be running Xen w/ Apache/Mongrel in some instances and MySQL in
another, and will have SAN storage for the app itself:

4GB RAM, 4x 73GB SCSI 10K RAID 10

I expect the server to be high traffic (don't we all, but seriously :)

I do not have space set aside to back up the SAN, so the second seems
like the obvious choice there. Lots of extra RAM will come in handy for
those Mongrel instances.

If my CPU (dual-core 2.2GHz Opteron) is taxed to the limit, it really
doesn't matter if I have infinite memory, since the CPU will be the
bottleneck. Also, I'm going to be backing up remotely every night
anyway, so the only added benefit of backing up to the SATA drives is
that they are local, resulting in less down time in the event of a SAN

The question then, is this - Is the added benefit of faster SCSI drives
worth compromising available RAM and disk space in a Rails production

Thanks for your opinion
A7b8d5ddf540e5f465abd0fb3b7cdfcb?d=identicon&s=25 Jesse Proudman (Guest)
on 2007-04-30 03:28
(Received via mailing list)
What is your application doing?  If it's just serving files and
accessing MySQL content, then drive speed shouldn't have a huge
impact.  If you're moving a ton of files around (online backup
service, photo hosting, etc), drive speed will become a bit more
important.  Additionally, if the content is small and can be cached
in RAM, then drive speed will matter even less.

If I were in your shoes, I'd look at doing a 2 x Dual Core setup for
4 logical cores ( or 2 x Quad Core if you can afford it ).  The extra
cores will help you out at a ton, and if your site will be high
traffic, the cost shouldn't that out of reach ( or at-least I don't
think our rates are ).


Jesse Proudman
Blue Box Group, LLC

p. +1.800.613.4305 x801
Ca9b6b510b9d4536c5f3b52cadae316a?d=identicon&s=25 twr -- (thetawaverider)
on 2007-04-30 11:44

The application will be pretty much serving Rails-generated pages and
accessing MySQL content. Media is on CDN, so it won't matter at all. I
think I'm going to stick w/ the higher RAM and storage space.

30b3f6355fad8461e37de7891753d810?d=identicon&s=25 johnl (Guest)
on 2007-04-30 14:01
(Received via mailing list)
Hi Aaron,

then you'll probably just need to focus on MySQL performance.  If your
database size is less than the free RAM (after mongrel etc) then read
speed isn't so dependent on disk speed.  Write speed *is* more
on disk speed, and RAID10 will speed that up for sure.

The correct answer though is to get more information.  Find out how
app behaves under normal conditions - does it do a lot of reading from
the db?  long sustained writes? etc.etc.  Then you can make a better
decision about what you need.  If you can borrow equipment before
try both scenarios and benchmark.

Having said that, if you have 100 requests per second, and the higher
RAM (but lower redundancy disk) option gets you 125 requests per
think about how long your site needs to be down to cancel that benefit
out :)  A disk is usually the most likely hardware to fail, and often
the longest failure to recover from (restoring from backups etc).

With a one server setup like this, I'd usually go for disk redundancy


On Apr 30, 10:44 am, "Aaron C." <>
04952a6ee948f345e9c3727850d09a1b?d=identicon&s=25 dima (Guest)
on 2007-05-01 22:42
(Received via mailing list)
Form mine experience it is the cache that you should look to gain some

If you application talks to RDBMS too much than RDBMS become the main
You can add RAM and CPU power and faster disks but you won't get
around the performance issues.

The only solution that you should be focused on is DRY and to cache
every thing that could be cached.

DO NOT work the same job twice.

First start with a cheaper server. Do the profiling and find the
bottlenecks in your application.
Test the whole environment and the service that are getting from your
You can leather easily switch to powerful server if you have to.

Be Agile - make the decision at the last possible moment where you
have the most valid information to make that decision.
This topic is locked and can not be replied to.