How about its running speed?
On Dec 18, 12:58 am, tenxian [email protected] wrote:
How about its running speed?
I don’t want to sounds harsh, but if you research a bit (I mean,
google) you will find pretty much all the answers to your questions.
Ruby speed, Rails as possible framework. Concurrency, hardware or VPS
to deploy into (specialized rails/ruby hosting companies).
Also look at RubyCorner and read most posts from Ruby blogs.
Don’t forget to actually try something in ruby before choosing it as
platform, in that way, you can know the pros and cons of it
beforehand.
HTH,
Luis L.
tenxian wrote:
How about its running speed
well, there are sites talking about speeding it up.
and there is MERB, that speeds up the actionpak.
there is a whole google wanna-be site on ruby/rails,
and they say the apple mini and mongrel just rock.
then some say cache the whole freaking thing.
google, and there is stuff, and good stuff, and bad stuff,
and old stuff, more old stuff. lol
Hi,
Am Dienstag, 18. Dez 2007, 13:00:17 +0900 schrieb tenxian:
How about its running speed?
I never did measure it in any way but at least I can say that
FastCGI is worth being considered as it is very easy to
implement. I even wrote my own one. You may have a look at it if
you like.
Bertram
On Tue, 18 Dec 2007, tenxian wrote:
How about its running speed?
The short answer to the question in the subject is: Absolutely.
The overall execution speed is less likely to be a bottleneck on a site
with heavy db usage because the db, in that scenario, often becomes the
bottleneck.
However, to address the basic issue of running speed, I have sites
running
on Ruby 1.8.x that are completely dynamically rendered, with all content
coming out of the database, and everything, including the navigation,
constucted dynamically based on the db content.
These sites are running on a 100% ruby based stack (no Apache, lighttpd,
nginx, etc… involved), and can do on the order of 1100 dynamically
created page views per second through a single backend process. A
cluster
of three backend processes does around 2700-2800 r/s. I get those
speeds
because I don’t go back into the database itself on every request, so
they
serve to illustrate what kind of performance a person can get when the
bottleneck is NOT the database. Ruby speed shouldn’t be a problem when
addressing the scalability of a large dynamic web site.
Kirk H.