Mission critical Ruby?

[Mark_Van_Orman]

Hi all,

I'm about to embark on a large scale project. It's basically a rewrite of a
current application that processes e-commerce transactions. (sending cc
info to bank platforms, creating records in db, handling reporting and the
like. Average load is about 50,000 transactions/day). The current
application is written in PHP as a cgi script. Mod_php is installed on
apache for speed. The main reason for the rewrite is the code clutter and
really bad design.

I'm supposed to write the application in JAVA, but willing to give Ruby a
chance, because of nicer syntax and other neat features. My main concerns
are

1- can Ruby handle such a mission critical applications as far as
reliability and speed?

2- Are there any benchmarks out there that compare PHP to Ruby?

3- From your experiance, would you think it's better to develop an
application like this as a cgi(people would post transes to apache) or as a
standalone server(post directly to ruby)?

4- Anyone out there with a similar experiance?

Thanks a lot,

Mark

[Robert]

"Mark VanOrman" <mark@icsaccess.com> schrieb im Newsbeitrag
news:10prcqui8iu3a3d@corp.supernews.com...

Hi all,

I'm about to embark on a large scale project. It's basically a rewrite

of a

current application that processes e-commerce transactions. (sending cc
info to bank platforms, creating records in db, handling reporting and

the

like. Average load is about 50,000 transactions/day). The current
application is written in PHP as a cgi script. Mod_php is installed on
apache for speed. The main reason for the rewrite is the code clutter

and

really bad design.

I'm supposed to write the application in JAVA, but willing to give Ruby

a

chance, because of nicer syntax and other neat features. My main

concerns

are

1- can Ruby handle such a mission critical applications as far as
reliability and speed?

I think so although I haven't done anything in this category yet. But it
really depends on the requirements.

2- Are there any benchmarks out there that compare PHP to Ruby?

Yes. You should be able to find them via Google.

3- From your experiance, would you think it's better to develop an
application like this as a cgi(people would post transes to apache) or

as a

standalone server(post directly to ruby)?

I'd implement the business logic independent of the communication protocol
and container used. Then you can do a test with CGI (or better FastCGI,
ModRuby or such) and Webrick as alternative.

4- Anyone out there with a similar experiance?

Does this help?
http://groups.google.com/groups?hl=de&lr=&selm=20031201213101.GC18957%40saber.xen.dk

Kind regards

    robert

[Curt_Hibbs3 (Curt Hibbs)]

Mark VanOrman wrote:

Hi all,

I'm about to embark on a large scale project. It's basically a
rewrite of a
current application that processes e-commerce transactions. (sending cc
info to bank platforms, creating records in db, handling reporting and the
like. Average load is about 50,000 transactions/day). The current
application is written in PHP as a cgi script. Mod_php is installed on
apache for speed. The main reason for the rewrite is the code clutter and
really bad design.

I'm supposed to write the application in JAVA, but willing to give Ruby a
chance, because of nicer syntax and other neat features. My main concerns
are

1- can Ruby handle such a mission critical applications as far as
reliability and speed?

2- Are there any benchmarks out there that compare PHP to Ruby?

3- From your experiance, would you think it's better to develop an
application like this as a cgi(people would post transes to
apache) or as a
standalone server(post directly to ruby)?

If you use Ruby on Rails (http://rubyonrails.org/\), you can prototype the
critical pieces of your application *very* quickly. This would allow you to
measure the performance directly and quickly determine whether or not your
critical issues are going to be a problem. Its better to know than to guess
(especially when you can do so with very little investment of time).

Rails can be used on apache with CGI, FastCGI, or mod_ruby. So you have lots
of flexibility here.

Curt

[Kirk_Haines]

I'm about to embark on a large scale project. It's basically a
rewrite of a current application that processes e-commerce
transactions. (sending cc info to bank platforms, creating records
in db, handling reporting and the like. Average load is about 50,000
transactions/day). The current application is written in PHP as a
cgi script. Mod_php is installed on apache for speed. The main
reason for the rewrite is the code clutter and really bad design.

50k transactions per day is no problem. Even for large pages of dynamic
content, on older, slower hardware, this should be no problem.

1- can Ruby handle such a mission critical applications as far as
reliability and speed?

Sure. My livelyhood comes from Ruby web apps that just have to work, and it
has for more than 2.5 years, now.

2- Are there any benchmarks out there that compare PHP to Ruby?

I have no idea. That's like comparing hot dogs to apples, though. The
other variables -- what sort of database interactivity and how much, what
front end web server, using any specific frameworks, etc.... all will have
an effect on any such benchmark.

3- From your experiance, would you think it's better to develop an
application like this as a cgi(people would post transes to apache)
or as a standalone server(post directly to ruby)?

That is hard to say from that very brief description of the application. I
am biased toward solutions that involve a process running independently from
the web server, though.

4- Anyone out there with a similar experiance?

Some. I have a bunch of web stuff for mutual funds, some of which interacts
with data from the bank. All of it is done in Ruby. In my case, using IOWA
(http://enigo.com/projects/iowa\) for my web development framework.

Thanks,

Kirk Haines

···

On Fri, 19 Nov 2004 17:53:18 +0900, Mark VanOrman wrote

[David_Garamond2 (David Garamond)]

Mark VanOrman wrote:

I'm about to embark on a large scale project. It's basically a rewrite of a
current application that processes e-commerce transactions. (sending cc
info to bank platforms, creating records in db, handling reporting and the
like. Average load is about 50,000 transactions/day). The current
application is written in PHP as a cgi script. Mod_php is installed on
apache for speed. The main reason for the rewrite is the code clutter and
really bad design.

I'm supposed to write the application in JAVA, but willing to give Ruby a
chance, because of nicer syntax and other neat features. My main concerns
are

1- can Ruby handle such a mission critical applications as far as
reliability and speed?

well, if you trust php for "mission critical" application, then i don't see why you wouldn't trust ruby. i have given up php for things "mission critical" because the 4.x series change too much and introduce many bugs and/or incompatibilities between minor releases. i mean, on one release the default for something is on, on another it's off. the API is horrible, it's inconsistent and it changes a lot. it drives me crazy.

hm, bad design and php usually go along together a lot the language itself is badly designed, the paradigm is about mixing code & content, it's no wonder...

3- From your experiance, would you think it's better to develop an
application like this as a cgi(people would post transes to apache) or as a
standalone server(post directly to ruby)?

there are many alternatives if you want to go faster than CGI: fastcgi, Apache module, standalone daemon. all can and has be done with ruby.

Regards,
dave

[James_Britt6 (James Britt)]

Curt Hibbs wrote:

Mark VanOrman wrote:
...

1- can Ruby handle such a mission critical applications as far as
reliability and speed?

2- Are there any benchmarks out there that compare PHP to Ruby?

3- From your experiance, would you think it's better to develop an
application like this as a cgi(people would post transes to
apache) or as a
standalone server(post directly to ruby)?

If you use Ruby on Rails (http://rubyonrails.org/\), you can prototype the
critical pieces of your application *very* quickly. This would allow you to
measure the performance directly and quickly determine whether or not your
critical issues are going to be a problem. Its better to know than to guess
(especially when you can do so with very little investment of time).

How does Rails do on speed? I recall a thread here some months ago on this, with doubts on Rails response time. I've been trying out a small app using Rails, and I'm struck by how long to takes to do trivial searches (basically, my app is essentially the Friends/Phones example in the rubyonrails.org site tutorial).

Now, I've been largely following the tutorial, cutting and pasting code, and tweaking things around to get a better sense of how Rails works. There may be any number of parameters or settings I can change to improve things, and I've not written a non-Rails MySQL version for comparison, so all of my benchmarks are, um, vague and based largely on intuition. I've run the Rails code as both CGI and under WEBrick (the two options I have for production), and no have to starting looking how to speed things up. (Or go back to my initial Madeleine approach.)

If someone is heading off to write a speed-critical app on Rails, what are some things to do right off the top to avoid false impressions about speed?

Thanks,

James

[Robert_Cottrell]

Last night we released our preview site, which was built using Ruby on Rails (http://twinkler.43things.com). We are continuing to look into improving performance, but the site feels pretty responsive as it is. The time spent generating the home page is currently split about 60% on database queries and 40% on rendering.

The two most critical things we did to improve performance were:

1) Run as FastCGI with the C fcgi extension. The startup time for Rails isn't trivial, and the database introspection used by ActiveRecord requires an additional query to the database per table to get column metadata. With FastCGI you don't incur these costs on every page serve.

2) Use the C mysql extension. This doubled the speed of processing the database queries.

Developing in CGI mode using the default pure Ruby mysql driver will feel very sluggish. Don't let that fool you into believing that's how the production application will perform.

In the end, however, good design will be more important than the framework in determining how your application will perform. Think carefully about the database design and how the tables are indexed. Analyze the data access patterns and consider some strategic denormalization of data. Look for opportunities to cache preprocessed data.

Rails has a lot of powerful features to make it easy to quickly prototype and develop applications, which will leave more time to think about the application's feature set and how to tune it for performance.

-Bob.

···

On Nov 19, 2004, at 7:25 AM, James Britt wrote:

Curt Hibbs wrote:

Mark VanOrman wrote:
...

1- can Ruby handle such a mission critical applications as far as
reliability and speed?

2- Are there any benchmarks out there that compare PHP to Ruby?

3- From your experiance, would you think it's better to develop an
application like this as a cgi(people would post transes to
apache) or as a
standalone server(post directly to ruby)?

If you use Ruby on Rails (http://rubyonrails.org/\), you can prototype the
critical pieces of your application *very* quickly. This would allow you to
measure the performance directly and quickly determine whether or not your
critical issues are going to be a problem. Its better to know than to guess
(especially when you can do so with very little investment of time).

How does Rails do on speed? I recall a thread here some months ago on this, with doubts on Rails response time. I've been trying out a small app using Rails, and I'm struck by how long to takes to do trivial searches (basically, my app is essentially the Friends/Phones example in the rubyonrails.org site tutorial).

Now, I've been largely following the tutorial, cutting and pasting code, and tweaking things around to get a better sense of how Rails works. There may be any number of parameters or settings I can change to improve things, and I've not written a non-Rails MySQL version for comparison, so all of my benchmarks are, um, vague and based largely on intuition. I've run the Rails code as both CGI and under WEBrick (the two options I have for production), and no have to starting looking how to speed things up. (Or go back to my initial Madeleine approach.)

If someone is heading off to write a speed-critical app on Rails, what are some things to do right off the top to avoid false impressions about speed?

Thanks,

James

[Tobias_Luetke1 (Tobias Luetke)]

Ruby is much faster than PHP when objects are involved. FastCGI rails
outperforms mod_php in my tests by a bit.

Also it seems that there are several VM's being made for ruby which
could improve the performance even more in the near future.

With 50k transactions a day i doubt you will hit any performance
problems unless you use CGI.

···

On Sat, 20 Nov 2004 00:25:53 +0900, James Britt <jamesunderbarb@neurogami.com> wrote:

Curt Hibbs wrote:

> Mark VanOrman wrote:
> ...

>>1- can Ruby handle such a mission critical applications as far as
>>reliability and speed?
>>
>>2- Are there any benchmarks out there that compare PHP to Ruby?
>>
>>3- From your experiance, would you think it's better to develop an
>>application like this as a cgi(people would post transes to
>>apache) or as a
>>standalone server(post directly to ruby)?
>
>
> If you use Ruby on Rails (http://rubyonrails.org/\), you can prototype the
> critical pieces of your application *very* quickly. This would allow you to
> measure the performance directly and quickly determine whether or not your
> critical issues are going to be a problem. Its better to know than to guess
> (especially when you can do so with very little investment of time).

How does Rails do on speed? I recall a thread here some months ago on
this, with doubts on Rails response time. I've been trying out a small
app using Rails, and I'm struck by how long to takes to do trivial
searches (basically, my app is essentially the Friends/Phones example in
the rubyonrails.org site tutorial).

Now, I've been largely following the tutorial, cutting and pasting code,
and tweaking things around to get a better sense of how Rails works.
There may be any number of parameters or settings I can change to
improve things, and I've not written a non-Rails MySQL version for
comparison, so all of my benchmarks are, um, vague and based largely on
intuition. I've run the Rails code as both CGI and under WEBrick (the
two options I have for production), and no have to starting looking how
to speed things up. (Or go back to my initial Madeleine approach.)

If someone is heading off to write a speed-critical app on Rails, what
are some things to do right off the top to avoid false impressions about
speed?

Thanks,

James

--
Tobi
http://blog.leetsoft.com

[David_Heinemeier_Ha2 (David Heinemeier Hansson)]

How does Rails do on speed? I recall a thread here some months ago on this, with doubts on Rails response time.

This thread came about from a guy that had misconfigured his setup and where using CGI. It never represented the reality of performance with Rails.

I've been trying out a small app using Rails, and I'm struck by how long to takes to do trivial searches (basically, my app is essentially the Friends/Phones example in the rubyonrails.org site tutorial).

Look in your logs: tail -f log/production.log. It's very easy to spot where your bottleneck. Perhaps it's a bad SQL query operating on a table with two many rows and no indexes.

But as long as you're just on CGI or WEBrick with cached classes turned off, be prepared that getting 1 req/sec is par for course on a reasonable modern machine. On old crusty hardware, it'll be even worse.

Rails trade start-up time for productivity big time. The good news is that start-up time doesn't matter any where but in production, so it's a trade well worth making.

I've run the Rails code as both CGI and under WEBrick (the two options I have for production), and no have to starting looking how to speed things up. (Or go back to my initial Madeleine approach.)

WEBrick is pretty capable as a production server for small systems. All you need to do is turn on cached classes:

$ ruby public/dispatch.servlet --help
Usage: ruby dispatch.servlet [options]

  -p, --port=port Runs Rails on the specified port.
                                   Default: 3000
  -b, --binding=ip Binds Rails to the specified ip.
                                   Default: 127.0.0.1
  -i, --index=controller Specifies an index controller that requests for root will go to (instead of congratulations screen).
  -d, --daemon Make Rails run as a Daemon (only works if fork is available -- meaning on *nix).
  -c, --cache-classes Caches class compilation which will speed up the serving of requests, but require a server restart on source changes.

  -h, --help Show this help message.

So starting the WEBrick dispatcher with "ruby public/dispatch.servlet -c" should give you very comfortable performance. Of course, you'll then need to restart the WEBrick server on code changes. But you have to do that in any of the production environments anyway.

If someone is heading off to write a speed-critical app on Rails, what are some things to do right off the top to avoid false impressions about speed?

Any of the three production environments will give you plenty of performance to handle the majority of applications (at 30 req/sec, you can handle 2.6 million requests per day).

So in the production environments, it's unlike that the framework is holding you back. It's much more likely that you'll construct your application in ways that aren't very friendly to performance.

These concerns doesn't have much to do with Rails. They apply to all applications (especially ones interfacing with the database). One of the most common mistakes is to do n*m queries. Fetching 30 records that each need to fetch 3 of their own, so you get 30*3 = 90 SQL statements for a single request.

Active Record gives you a very convenient way of routing around that problem called "piggy-back queries". I discuss their usage in detail on Ruby on Rails — A web-app framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern.

At the end of the day, there's only one thing that's going to help you deal with performance problems: benchmarking and profiling! Rails give you a rough estimation at the first part with the automatically configured logs and Ruby makes the second part fairly easy as well.

Performance is one of those areas where intuition is most badly applied. I can't count the number of times I was sure that the bottleneck was in one part of the code and then benchmarking/profiling proved me silly wrong.

Never make decisions about optimizations based on intuition. It's considered harmful.

···

--
David Heinemeier Hansson,
http://www.basecamphq.com/ -- Web-based Project Management
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://macromates.com/ -- TextMate: Code and markup editor (OS X)
http://www.loudthinking.com/ -- Broadcasting Brain

[Ed_Hames]

It might be me, but I just see a blank page.

Regards,
Ed

···

On Sat, 20 Nov 2004 01:52:57 +0900, Robert Cottrell <rgcottrell@mac.com> wrote:

Last night we released our preview site, which was built using Ruby on
Rails (http://twinkler.43things.com). We are continuing to look into
improving performance, but the site feels pretty responsive as it is.
The time spent generating the home page is currently split about 60% on
database queries and 40% on rendering.

--
"Sex is like a game of bridge. If you don't have a good partner, you'd
better have a great hand."

[David_Heinemeier_Ha2 (David Heinemeier Hansson)]

Developing in CGI mode using the default pure Ruby mysql driver will feel very sluggish. Don't let that fool you into believing that's how the production application will perform.

Robert hit it spot on with all of these comments, but I'd just like to follow up with a small story about a Rails training/consulting session I had in Vancouver, Canada with Combustion Labs not too long ago.

We had been using straight CGI all week to get started on development and everyone were getting used to the fact that reloading was a little slow (about 1 request per second). This was indeed cause for a bit disgruntlement among the developers as they were used to PHP where reloading in development and production was equally fast.

So at the end of the week, I thought it was about time we tried out how it would perform in a production environment. We went straight to FastCGI (which is the recommended production environment for Rails, especially in scenarios with multiple apps per server). The performance increase totally silenced the team.

We went from 1.16 requests per second to 104 requests per second! Two orders of magnitude.

Mind you, this was on a simple page with just a few SQL calls. But still.

Rails is _plenty_ fast. Ruby does a fantastic job managing OO-heavy systems where PHP just becomes slower and slower.

Comparing the performance of a hello world page in PHP with a equivalent in Ruby (on Rails or not) is meaningless. PHP will likely be faster, but no system does "hello world" and shuts up. The differences appear once you have a "real" system with plenty of objects getting thrown around (which then again makes it hard to compare).

Oh, and 50K transactions is one every two seconds (on a even split). You could almost do that on CGI. And you could certainly do it on everything from mod_ruby to FastCGI to WEBrick (which cached classes turned on).

So now that you've asserted that every platform out there should be able to handle your processing needs, you should probably look at other factors. Like, how productive is the environment? I think you'll find that Java might not be what you want there (he said, trying to phrase it as PC as possible).

···

--
David Heinemeier Hansson,
http://www.basecamphq.com/ -- Web-based Project Management
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://macromates.com/ -- TextMate: Code and markup editor (OS X)
http://www.loudthinking.com/ -- Broadcasting Brain

[James_Britt6 (James Britt)]

David Heinemeier Hansson wrote:

How does Rails do on speed? I recall a thread here some months ago on this, with doubts on Rails response time.

This thread came about from a guy that had misconfigured his setup and where using CGI. It never represented the reality of performance with Rails.

I've been trying out a small app using Rails, and I'm struck by how long to takes to do trivial searches (basically, my app is essentially the Friends/Phones example in the rubyonrails.org site tutorial).

Look in your logs: tail -f log/production.log. It's very easy to spot where your bottleneck. Perhaps it's a bad SQL query operating on a table with two many rows and no indexes.

Well, I'm not writing any SQL, Rails is. Really; my app is the Friends/Phone tutorial. Different table and field names, but almost exactly the same number of tables and fields and simple relationship. One main table, where each record may refer to zero or more rows in a secondary tale, related by a single-column foreign key. It's about the simplest relational model there is.

I created my app by following the tutorial, then going back and changing table and field names.

Ruby on Rails

I've been testing things with about two rows of data in each indexed table.

But as long as you're just on CGI or WEBrick with cached classes turned off, be prepared that getting 1 req/sec is par for course on a reasonable modern machine. On old crusty hardware, it'll be even worse.

I switched from CGI to WEBrick, and the speed issue may be the lack of class caching, so I'll give that a whirl, then set up some benchmark tests.

Thanks,

James

[gabriele_renzi]

Edgardo Hames ha scritto:

It might be me, but I just see a blank page.

works for me, and it seem for other people as well I can see their signs

[David_Heinemeier_Ha2 (David Heinemeier Hansson)]

Well, I'm not writing any SQL, Rails is. Really; my app is the Friends/Phone tutorial. Different table and field names, but almost exactly the same number of tables and fields and simple relationship. One main table, where each record may refer to zero or more rows in a secondary tale, related by a single-column foreign key. It's about the simplest relational model there is.

The friends/phone tutorial is a work-in-progress by people trying to learn Rails. It's not a best practice implementation, so use it for inspiration on how to get started, but not as a definite guide.

An even though Rails is writing the SQL, it's doing so according to the methods you call. That's why it's a good idea to have an eye on the production.log, so you get an early warning if you're using the API in a way that'll lead to performance bottlenecks.

But as long as you're just on CGI or WEBrick with cached classes turned off, be prepared that getting 1 req/sec is par for course on a reasonable modern machine. On old crusty hardware, it'll be even worse.

I switched from CGI to WEBrick, and the speed issue may be the lack of class caching, so I'll give that a whirl, then set up some benchmark tests.

It's certain that the speed issue is due to lack of class caching. When not turned on, WEBrick will start a new Ruby interpreter for every request. Which causes you to incur the full start-up cost every time. Just like regular CGI.

···

--
David Heinemeier Hansson,
http://www.basecamphq.com/ -- Web-based Project Management
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://macromates.com/ -- TextMate: Code and markup editor (OS X)
http://www.loudthinking.com/ -- Broadcasting Brain