High performance queries - RoR, PHP or something else?

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

Hi !

2005/12/30, Carl-Johan K. [email protected]:

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 !

Carl-Johan K. 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).

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 K. wrote:

have different parameters.
Failed requests: 0
Concurrency Level: 100

[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails


M. Edward (Ed) Borasky

On Friday 30 December 2005 14:43, Carl-Johan K. 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 S. Those people who smile a lot
mailto:[email protected] Watch the eyes
Michael Schürig | Sentenced to making sense --Ani DiFranco, Outta Me, Onto You