Forum: Ruby on Rails High performance queries - RoR, PHP or something else?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
E24b2a1d71b7365186a934a09ee6f7c3?d=identicon&s=25 Carl-Johan Kihlbom (Guest)
on 2005-12-30 14:46
(Received via mailing list)
Hi everyone,

I'm building an app in RoR that apart from the normal web interface
has a web service. This web service takes a parameter and uses that in
a single database query, and returns the result in a simple XML
format.

This web service needs to be quite fast as it will be used on all
pages of a quite big site with thousands of visitors every hour. I
don't think caching is an option since most of the the requests will
have different parameters.

I'm wondering if it makes sense to do the web service in something
other than Rails. I did a quick comparison between RoR and PHP on the
same server:

Ruby on Rails

Concurrency Level:      100
Time taken for tests:   143.176 seconds
Complete requests:      10000
Failed requests:        0
Broken pipe errors:     0
Total transferred:      5534371 bytes
HTML transferred:       3340334 bytes
Requests per second:    69.84 [#/sec] (mean)
Time per request:       1431.76 [ms] (mean)
Time per request:       14.32 [ms] (mean, across all concurrent
requests)
Transfer rate:          38.65 [Kbytes/sec] received

PHP

Concurrency Level:      100
Time taken for tests:   47.542 seconds
Complete requests:      10000
Failed requests:        0
Broken pipe errors:     0
Total transferred:      5410000 bytes
HTML transferred:       3710000 bytes
Requests per second:    210.34 [#/sec] (mean)
Time per request:       475.42 [ms] (mean)
Time per request:       4.75 [ms] (mean, across all concurrent requests)
Transfer rate:          113.79 [Kbytes/sec] received

As you can see, in this particular case PHP is 3x faster than RoR.

What do you do when you have a specific part of your app that has high
performance requirements?

Best regards,

CJ Kihlbom
3dd4b52a0946bd698b1d1635a46ea3a3?d=identicon&s=25 Francois Beausoleil (Guest)
on 2005-12-30 15:02
(Received via mailing list)
Hi !

2005/12/30, Carl-Johan Kihlbom <kihlbom@gmail.com>:
> What do you do when you have a specific part of your app that has high
> performance requirements?

You do the simplest thing that could possibly work.  If in this
particular instance PHP is better for you, and you don't mind the
duplication of logic between Rails and PHP, then yes, PHP is a good
fit for you.

If on the other hand you need something simpler to maintain than hard
performance requirements, then you just throw more hardware at the
problem, until it goes away.

Also, you should tell us how you configured Rails, because there might
be some tweaks that would bring your runtime lower - closer to PHP's.

Hope that helps !
3a83969376c805ef5b6042191fdb0ff3?d=identicon&s=25 Andreas S. (andreas)
on 2005-12-30 15:06
Carl-Johan Kihlbom wrote:
> This web service needs to be quite fast as it will be used on all
> pages of a quite big site with thousands of visitors every hour. I
> don't think caching is an option since most of the the requests will
> have different parameters.

I wouldn't start optimizing based on assumptions. _Calculate_ how many
req/s you need, and compare to how many you can manage. And don't write
off caching, even if there are many different queries caching can be
effective when the database does not change often.

> I'm wondering if it makes sense to do the web service in something
> other than Rails. I did a quick comparison between RoR and PHP on the
> same server:

These results depend heavily on the configuration, like the number of
FastCGI processes and the session handler (disabling sessions can
improve performance a lot).
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2005-12-30 16:27
(Received via mailing list)
Have you profiled these tests on the server(s) to see

a) Where in the stack they are spending their time (Ruby or PHP,
database, web server, OS)
b) Where the hardware bottleneck is (processor, disk, network)?

There is no point in throwing hardware at a problem until you know what
kind of hardware and why. At first glance, I am assuming that all other
things (database, web server and OS) are equal and the difference is all
either in the Rails code or the underlying Ruby interpreter. If the
Rails code is inefficient for this test case, I'm sure the Rails team
(and this list) would be more than willing to help out.

Carl-Johan Kihlbom wrote:

>have different parameters.
>Failed requests:        0
>Concurrency Level:      100
>
>Rails@lists.rubyonrails.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>

--
M. Edward (Ed) Borasky

http://linuxcapacityplanning.com
Bce1d1b7c3ec7b577dcb42e254899e6b?d=identicon&s=25 Michael Schuerig (Guest)
on 2005-12-30 18:22
(Received via mailing list)
On Friday 30 December 2005 14:43, Carl-Johan Kihlbom wrote:
> I'm building an app in RoR that apart from the normal web interface
> has a web service. This web service takes a parameter and uses that
> in a single database query, and returns the result in a simple XML
> format.

What does that query look like? How many objects does it return? Does it
eagerly include associations?

When the query returns more than, say, 1000 rows, instantiating the
ActiveRecord objects for these may be the bottleneck. To be sure, you
have to measure the execution times of the various stages in your
setup.

If you find that database access indeed is the bottleneck, measure the
plain SQL query to find out how fast it could be in the limit. Then,
decide whether it is worthwhile to bypass the object instantiation of
ActiveRecord.

Michael

--
Michael Schuerig                         Those people who smile a lot
mailto:michael@schuerig.de                             Watch the eyes
http://www.schuerig.de/michael/    --Ani DiFranco, Outta Me, Onto You
This topic is locked and can not be replied to.