[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

mission critical Ruby?

Mark VanOrman

11/19/2004 8:49:00 AM

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
12 Answers

Robert Klemme

11/19/2004 2:23:00 PM

0


"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%40sa...

Kind regards

robert

Curt Hibbs

11/19/2004 2:50:00 PM

0

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://rubyon...), 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

James Britt

11/19/2004 3:26:00 PM

0

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://rubyon...), 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

11/19/2004 4:53:00 PM

0

Last night we released our preview site, which was built using Ruby on
Rails (http://twinkler.43...). 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://rubyon...), 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 Luetke

11/19/2004 7:12:00 PM

0

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://rubyon...), 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.le...

gabriele renzi

11/19/2004 7:20:00 PM

0

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 :)

khaines

11/19/2004 7:20:00 PM

0

On Fri, 19 Nov 2004 17:53:18 +0900, 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.

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/pro...) for my web development framework.


Thanks,

Kirk Haines

David Garamond

11/20/2004 4:04:00 AM

0

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

David Heinemeier Hansson

11/20/2004 2:44:00 PM

0

> 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.basec... -- Web-based Project Management
http://www.rubyon... -- Web-application framework for Ruby
http://macro... -- TextMate: Code and markup editor (OS X)
http://www.loudthi... -- Broadcasting Brain

David Heinemeier Hansson

11/20/2004 2:59:00 PM

0

> 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
http://www.rubyon...show/Pigg...

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.basec... -- Web-based Project Management
http://www.rubyon... -- Web-application framework for Ruby
http://macro... -- TextMate: Code and markup editor (OS X)
http://www.loudthi... -- Broadcasting Brain