These forums are read-only!
Extreme performance hit when moving from Dreamhost to Slicehost
  • I'm in the process of moving Scrawlers.com from Dreamhost to Slicehost. When I finally got the site running on a Slice, I was prepared to be awed. Unfortunately I'm seeing performance about 50x's worse than Dreamhost.

    Stats: Ubuntu, Apache, Mongrel, Rails, 256m slice. At Dreamhost, I believe it's: Apache, FastCGI, Rails, shared server.

    My impression from Slicehost support is that this is unusual. Unfortunately they are unable to actually help me. It's been suggested that my app code is at fault. I've confirmed to a reasonable degree that the data I imported is intact, including indexes. I've confirmed that I have free memory on my slice and it doesn't appear that mySQL is running out of control. I've followed debug logs in the Rails app and no specific queries seem to be dragging. It's just a general slowness.

    An example, the following analogous pages:

    "http://scrawlers.beforeward.com/the_scrawl/faq":http://scrawlers.beforeward.com/the_scrawl/faq
    "http://scrawlers.com/the_scrawl/faq":http://scrawlers.beforeward.com/the_scrawl/faq

    The slicehost version averages:

    pre. 0.06714 s rendering
    1.75282 s db access

    The dreamhost version averages:

    pre. 0.07774 s rendering
    0.03300 s db access


    So for the same SQL calls against the same database, I'm seeing a response time 53 times worse than Dreamhost. When I run these same calls directly against the database on either host I'm seeing sub 1/100th of a second response time.

    And this is a simple example. Other pages are seeing 6-8 second response times rather than sub-second response times.

    I figure there is something configured poorly somewhere between the app and the DB. I guess it would surprise me that I'm the first person to run into such a thing (or to contact Slicehost about it in any case). And I'd be _really_ surprised if tweaking my application code itself is going to account for that disparity. Especially on such a very simple page.

    Are there any tips you folks can offer?
  • Did you compile the native MySQL adapter "MySQL/Ruby":http://tmtm.org/mysql/ruby/README.html ?

    If not, Rails is probably using the pure ruby MySQL adapter, which is a *lot* slower.
  • you might need to change some of the mysql global variables. for example, you could turn query caching on, increase heap allocation, etc.

    look into the mysql logs more, and mark slow queries. it could be something as simple as altering group_concat_max_len or something that makes mysql use the hdd.
  • My guess is that Dreamhost had the database optimized for multiple users and high performance, while you're probably just using mysql out of the box with no tweaking. I recommend checking out and learning the excellent mysqlreport to tweak your mysql server. Also, is the database at DH running on a separate physical machine, or the same one as your Rails account? Giving the database its own machine will invariably improve performance a lot compared to running it on the same machine as the application it's serving.

    If Dreamhost's mysql is running on the same physical machine, you might be able to steal a copy of their my.cnf to compare it with the one you're using at Slicehost. Just cp /etc/mysql/my.cnf to your home directory and compare it with the one on your slice.

  • I'm pretty sure the db runs on a separate machine at DH.
  • benmyles said:

    bq. Did you compile the native MySQL adapter MySQL/Ruby ?
    If not, Rails is probably using the pure ruby MySQL adapter, which is a lot slower.

    I used "deprec":http://wiki.slicehost.com/doku.php?id=automated_rails_install_and_deployment_with_deprec_capistrano. I would assume that compiles the appropriate MySQL adapter? Has anyone who used deprec to setup your Rails stack done some DB tweaking on top of that?

    I'll see if I can get some time to look in the MySQL logs and perhaps mysqlreport.

    I don't think the separate physical machine would account for this drastic difference. My slice has one user (me) hitting it, with no shortage of memory or CPU spikes. Dreamhost optimizing for high performance...that might explain the difference.

    I suspect if I deployed a brand new app to my slice I would have no major performance issues. If I _really_ get time, maybe I'll put something like that together.

    THANK YOU for the responses!
  • Something similar happened to me, when I moved my forum to Slicehost. What you have to realise is that a shared hosting company like Dreamhost will, if its any good, spend a lot of time optimising the different settings for Apache, MySQL etc. Your slice is only as optimised as YOU make it. The defaults for Ubuntu for example assume you have plenty of RAM. So when I first ran my forum, it was fast for a few minutes and then slow like treacle. Apache2 and MYSQL were spawning off LOADS of processes, eating all the RAM, and putting me deep in virtual memory.I had to edit apache and MySQL configuration files to use less RAM. Ever since then my forum has flown!

    The point? I guess, that you have to spend time getting your slice optimised. Use Top - whats your RAM usage like? Read some of the many MySQL for VPS optimisation articles.
  • I'm having similar issues, moving my rails app from DH to Slice...

    Can someone post an example apache2.conf and my.cnf configuration that works well with 256mb slice?

    I have qa, test, and prod rails apps on my slice. The prod app fails miserably, the largest table has 848 rows (statistics, mostly numbers)...not all that large, I wouldn't expect it to bring the app to a grinding halt.

    I have 2 mongrel servers per rails environment (test, qa, prod - 6 total).
  • Guys, stop trying to run your Rails apps on slices that leave you no room to move. If you run a rails app on a 256 Slice I hope its a simple low traffic app.
  • Posted By: chovyCan someone post an example apache2.conf and my.cnf configuration that works well with 256mb slice?

    http://chrisjohnston.org/2008/configuring-a-lightweight-apache-mysql-install-on-debian-ubuntu
  • edited: just realised the original post was from 2007 :)