# Fast drives vs. more memory/disk space **URL:** \ **Category:** Deployment\ **Created:** [April 30, 2007, 3:12am UTC](https://www.ruby-forum.com/t/fast-drives-vs-more-memory-disk-space/93253 "2007-04-30T03:12:06Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![thetawaverider](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90db22/32.png) [@thetawaverider](https://www.ruby-forum.com/u/thetawaverider)\ **Post date:** [April 30, 2007, 3:12am UTC](https://www.ruby-forum.com/t/fast-drives-vs-more-memory-disk-space/93253/1 "2007-04-30T03:12:06Z")
Hello, 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 8GB RAM, 2x 250GB SATA II RAID 1 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. However… 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 failure. The question then, is this - Is the added benefit of faster SCSI drives worth compromising available RAM and disk space in a Rails production environment? Thanks for your opinion ---
**Author:** ![thetawaverider](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90db22/32.png) [@thetawaverider](https://www.ruby-forum.com/u/thetawaverider)\ **Post date:** [April 30, 2007, 3:28am UTC](https://www.ruby-forum.com/t/fast-drives-vs-more-memory-disk-space/93253/2 "2007-04-30T03:28:56Z")
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 P. Blue Box Group, LLC p. +1.800.613.4305 x801 e. removed\_email\_address@domain.invalid ---
**Author:** ![thetawaverider](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90db22/32.png) [@thetawaverider](https://www.ruby-forum.com/u/thetawaverider)\ **Post date:** [April 30, 2007, 11:44am UTC](https://www.ruby-forum.com/t/fast-drives-vs-more-memory-disk-space/93253/3 "2007-04-30T11:44:04Z")
Hi, 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. Thanks ---
**Author:** ![thetawaverider](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90db22/32.png) [@thetawaverider](https://www.ruby-forum.com/u/thetawaverider)\ **Post date:** [April 30, 2007, 2:01pm UTC](https://www.ruby-forum.com/t/fast-drives-vs-more-memory-disk-space/93253/4 "2007-04-30T14:01:41Z")
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 dependent on disk speed, and RAID10 will speed that up for sure. The correct answer though is to get more information. Find out how your 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 hand, 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 second, 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 myself. ## John. [http://johnleach.co.uk](http://johnleach.co.uk) On Apr 30, 10:44 am, “Aaron C.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![thetawaverider](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/90db22/32.png) [@thetawaverider](https://www.ruby-forum.com/u/thetawaverider)\ **Post date:** [May 1, 2007, 10:42pm UTC](https://www.ruby-forum.com/t/fast-drives-vs-more-memory-disk-space/93253/5 "2007-05-01T22:42:54Z")
Form mine experience it is the cache that you should look to gain some performance. If you application talks to RDBMS too much than RDBMS become the main bottleneck. 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 vendor. 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.