Mysql on mongrel vs apache

Does mysql performance with mongrel and Snow Leopard differ from its
performance with Apache and Ubuntu? I am experiencing the issue of
slow performance in Ubuntu production environment compared to my
Leopard development environment. For the exact same code, after
pushing to Ubuntu server, the same action/view takes much longer to
complete and many more DB queries on the Ubuntu server:

On my Leopard, I get: Completed in 643ms (DB: 322) | 302 Found
For Ubuntu, I get: Completed in 8803ms (DB: 517) | 302 Found

The number after DB: is the number of SQL queries for that action I
assume.

Is there anything I should watch out for when pushing code from
Leopard to Ubuntu?

Thanks much.

On Mar 13, 1:42 am, Ease B. [email protected] wrote:

The number after DB: is the number of SQL queries for that action I assume.

It’s not - it’s the amount of time spent querying the database. There
are a lot of things which could affect performance - ruby version,
mysql version, mysql configuration, physical resources available on
the server etc. Rails does behave slightly different when the
environment is set to production (as opposed to development), but that
should make things faster, not slower.

Fred

On Fri, 2010-03-12 at 17:42 -0800, Ease B. wrote:

The number after DB: is the number of SQL queries for that action I assume.

Is there anything I should watch out for when pushing code from
Leopard to Ubuntu?

Thanks much.


in the realm of expectations, I think traditionally, Macintosh OS X and
FreeBSD in general have had some performance issues with MySQL and
threading and I don’t know that those issues have been resolved but my
expectations are that generally, you should get much better performance
out of Linux.

Of course there are so many factors that could easily influence the
comparison including, RAM (sufficient? swapping?), MySQL indexes, SQL
using sockets or TCP/IP, etc.

Just for fun, I looked at my current project (in production mode) and
the ‘main’ page is what I would consider a heavy load, several joined
tables and calculations that require Geokit, distances from a specific
point, many partials, a very large css, a ton of javascript, etc. and it
says…
Completed in 364ms (View: 200, DB: 117)
(Fedora on Linode VPS with 384 RAM)

so I gather you have some major issues going on.

Craig


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Quoting Ease B. [email protected]:

The number after DB: is the number of SQL queries for that action I assume.

Do you have the same amounts of data in the DB in production and
development
environments? The number after ‘DB:’ is the number of milliseconds the
DB
access required. The difference in DB access times are not nearly as
big as
the the controller and rendering times (Completed time minus DB time).
I’m
guessing production has more data in the DB and more data found and
rendered,
hence increased run times. But the development laptop may be a lot
faster
than the server (higher clock speeds, faster rotating disks, faster disk
busses, e.g., SATA and USB 2.0 can be much faster than PATA).

You might try disk and other benchmarks on both machines.

HTH,
Jeffrey

It looks like you are running out of memory (RAM) and disk-swapping is
accounting for the difference in times.

Thanks all. The amount of data on the Ubuntu staging server is a little
bit
more than the data on my Leopard laptop. So the slight difference in DB
access time seems reasonable. What worries me is the intolerably long
time
the Ubuntu machine takes to produce the views. I also notice that the
ruby1.8 process on Ubuntu briefly shots up close 100% of the CPU during
that
time. Below are the specs of the computers

  1. Snow Leopard Laptop : MacBook Pro 2.53 GHz Intel Core 2 Duo, 4GB
    1067
    MHz DDR3, 250.06 GB SATA hard drive

    • ruby 1.8.7 (2008-08-11 patchlevel 72) [universal-darwin10.0]
    • Rails 2.3.5
    • mysql Ver 14.14 Distrib 5.1.43, for apple-darwin10.2.0 (i386)
      using
      readline 5.1
    • Mongrel
    1. Ubuntu 9.10 Server (old former custom built Windows xp
      computer):
      Intel Pentium 4 3.00 Ghz, 1G RAM, 18 (eighteen) GB hard drive.
      (IDE), 855
      MB is swap partition.
  • ruby 1.8.7 (2009-06-12 patchlevel 174) [i486-linux]
  • Rails 2.3.5
  • mysql Ver 14.14 Distrib 5.1.37, for debian-linux-gnu (i486) using
    EditLine wrapper
  • apache2

Could the difference in hardware configuration explain the slowness in
the
Ubuntu box?

Could the way I install ruby, or mysql on the Ubuntu box be of
consequence?
I just ran:

sudo apt-get install ruby-full build-essential

sudo apt-get install mysql-server mysql-client

I read that some people download the ruby and mysql source code and
actually
run make to compile them on Ubuntu instead of using apt-get. Would that
have affected later performance?

Besides creating a virtual site in apache2, I did not configure ruby,
rails,
mysql, or apache2 on either box in any particular manner. I just stuck
with
the default configuration that came with the software. So the software
configuration in these software is not different between the two boxes.

Thanks.

On Fri, Mar 12, 2010 at 7:39 PM, Jeffrey L. Taylor
[email protected]
wrote:

The number after DB: is the number of SQL queries for that action I
assume.

Do you have the same amounts of data in the DB in production and
development
environments? The number after ‘DB:’ is the number of milliseconds the DB
access required. The difference in DB access times are not nearly as big
as
the the controller and rendering times (Completed time minus DB time).
I’m
guessing production has more data in the DB and more data found and
rendered,
You received this message because you are subscribed to the Google G.
“Ruby on Rails: Talk” group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected][email protected]
.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs