Out of curiousity-- how many servers do you have (and what’s the
level of hardware)?
bill
Philip H. wrote:
Yep, none of what you mention I consider more than a minor issue either.
For various reasons, I still have to sprinkle set_table_name,
:foreign_key, :association_key, :class_name, etc. in my non-legacy Rails
apps.
Joe
Joe R. wrote:
I’m not sure – legacy=poorly designed (e.g. not conforming to the three
normal forms) database(s) perhaps. I have some non-legacy databases I
created from scratch for Rails apps and creating associations between
tables wasn’t the easiest (had to result to :finder_sql).
thanks a lot. 3NF-compliant or not-3NF-compliant is better way to refer
to database design, I think.
–
Rodrigo.
- you don’t write any tests
If you know what you are doing, you don’t have to write any tests. First
before creating an application, you have to diagram everything using
your favorite methodology: for me, the best is UML, some E/R Diagrams,
and a sitemap.
Aaaaaarrhg. That’s very wrong.
While I don’t wholly subscribe to the full TDD mentality (write tests
first, code later), automated unit, functional and integration tests
are essential for any moderately complex software project. Automated
tests, in particular unit tests, are not primarily there to ensure
your software is bug free. There are better ways of doing this, such
as code and design inspections. Automated tests are great for ensuring
that your software stays bug free - that is, by making changes at a
later date, you can be (within reason) sure that you have not broken
existing code by running the test suite again. Combined with a
continuous integration approach, this reduces integration problems
tremendously. While this is more important for software that is
written by more than one person, even single-programmer projects will
benefit from decent test coverage.
Max
Philip H. wrote:
Cons of Rails:
- lack of really big Rails applications in the market, which is an
issue because many customers think their app will potentially need to
scale to 1M hits/second so want to be convinced that it’s possible
before you startOur site (not pjkh.com, heh
recently did just under 9 million pages
in a day. For August we’ve averaged 4.5 mil pages/day (and about 40 mil
hits/day).Rails scaled just fine, it’s the database you have to worry about (and
in
that regard, memcache helps a lotNot that Alexa is the be-all-end-all, but just to give you some
comparision’s on what is considers “page views” during August compared
to
penny-arcade and basecamphq which are the two sites that always seem to
crop up when scaling is mentioned…http://img312.imageshack.us/img312/3569/alexavd9.png
So, yeah, Rails can scale… at least this high… which is more than
most
websites are going to see…Anyway, when things settle down for us a bit we’re going to write up
something that will hopefully help folks convince their PHB that Rails
scales just fine…-philip
Guys, I really appreciate your responses! Especially yours, philip - I
have been very dubious about Rails’ performance when huge number of hits
start rolling in.
Thanks,
Ben L.
Out of curiousity-- how many servers do you have (and what’s the
level of hardware)?
Not counting database servers or ad servers or dedicated media servers,
we
have twenty. Three of them act as memcache servers as well.
I don’t have the models with me, but they are 4GB, dual CPU, SATA boxes.
And they didn’t get pushed that hard either… but better safe than
sorry
Bottom line you’ll hit database issues loooong before you hit Rails
issues.
On Tue, Aug 15, 2006 at 04:26:09PM -0400, Rodrigo F. wrote:
If you know what you are doing, you don’t have to write any tests. First
Please stay well away from any code I will ever maintain, use, or have
interact with my affairs in any way whatsoever.
- Matt
Matthew P. wrote:
On Tue, Aug 15, 2006 at 04:26:09PM -0400, Rodrigo F. wrote:
If you know what you are doing, you don’t have to write any tests. First
Please stay well away from any code I will ever maintain, use, or have
interact with my affairs in any way whatsoever.
of course if you know what you are doing and you know people will use
your code, you have to write tests.
Calm down…!!! it’s just an opinion!! 
for the same webserver, i know that ruby on rails is always slower than
a
php application, even if you use mongrel, fcgi or any accelerators.
also slower than java or .net applications
Brian H. wrote:
stuff
I pretty much agree with everything said here.
heri rakotomalala wrote:
for the same webserver, i know that ruby on rails is always slower than
a php application, even if you use mongrel, fcgi or any accelerators.also slower than java or .net applications
Just saying something is “slow” in an apples and oranges comparison is
useless.
Speed matters in some contexts, not at all in others, and overall system
performance will depend a lot more on your actual application then on
the implementation platform.
Someone did (an admittedly flawed) comparison of a single simple sample
application implemented on Symfony(PHP), Rails(Ruby), and
Django(Python). Their results are here:
http://wiki.rubyonrails.org/rails/pages/Framework%20Performance For
the sample app, under high synthetic stress load, Django > Rails >
Symfony. Symfony actually fell down under load, failing to serve >60%
of the requests. All three platforms managed on the order of 100
requests/sec +/- 20% on the dual 3.2GHz Xeon box they used.
Most web apps can be built to scale out by adding more app servers when
properly architected. The cost of deploying an extra app server is
roughly equivalent to a week, maybe two, of skilled developer salary.
The hardest limits usually tend to end up in the database server,
requiring expensive DB clustering solutions and/or clever tiered data
caching strategies when you exceed the capacity of the best single SMP
box you can afford for your DB server.
If a single web server can sustain 60 pages/sec, that translates to a
peak capacity of ~200K page views/hour. That’s the kind of traffic one
sees on a site getting >1M unique visitors/day. In other words, you
need to have a damn popular web site to make the speed of your web
framework be the critical issue.
–
Devin Ben-Hur 503/860-4114 mailto:[email protected]
You may not have noticed, but we live in one of the safest,
most peaceful, times in human history. In the US, the three
leading causes of death are: killing yourself, killing yourself,
and killing yourself http://tinyurl.com/msxhq.
–
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.1/421 - Release Date:
8/16/2006
Joe R. wrote:
heri rakotomalala wrote:
for the same webserver, i know that ruby on rails is always slower than
a
php application, even if you use mongrel, fcgi or any accelerators.also slower than java or .net applications
Unless you link to some tests, I’ll conclude you know nothing.
Joe
Aren’t there like a bazillion benchmarks showing that Ruby is one of the
slowest, if not THE slowest language out there? And if Ruby is slow,
isn’t it fairly logical to assume Rails is just as slow if not slower?
Obviously Rails could out-perform PHP if the PHP code were crap, but I
think it’s safe to assume the most generally a Rails app is slower than
a PHP app doing the same thing.
heri rakotomalala wrote:
for the same webserver, i know that ruby on rails is always slower than
a
php application, even if you use mongrel, fcgi or any accelerators.also slower than java or .net applications
Unless you link to some tests, I’ll conclude you know nothing.
Joe
Eleo wrote:
Joe R. wrote:
heri rakotomalala wrote:
for the same webserver, i know that ruby on rails is always slower than
a
php application, even if you use mongrel, fcgi or any accelerators.also slower than java or .net applications
Unless you link to some tests, I’ll conclude you know nothing.
Joe
Aren’t there like a bazillion benchmarks showing that Ruby is one of the
slowest, if not THE slowest language out there? And if Ruby is slow,
isn’t it fairly logical to assume Rails is just as slow if not slower?
Obviously Rails could out-perform PHP if the PHP code were crap, but I
think it’s safe to assume the most generally a Rails app is slower than
a PHP app doing the same thing.
Tests I’ve seen show about a 3-5% performance penalty. But then Ruby
does better on memory. At any rate – BIG DEAL (except for trolls).
Joe
hi there,
ok devin, you might be right, i am comparing apples to oranges, i also
know
that rails app can be scaled up, you can add webservers and database
servers
and the like, that you can use fcgi, mongrel or memcache (if you have
the
ressources, that is)
But i still think that speed is the crucial problem for rails.but a lot
of
un-technical people i have talked to think that rails websites are slow.
i
have asked questions about what they think about backpack or 43things
and
they reckon it could be faster. they don’t know about database or RAM
problems or processing power. and you agree with me that users have the
ultimate word.
i just know that rails talks a lot. for example, it needs at least a
‘show
fields’ commands for each request. sessions slows the website down
unless
you have memcache, which needs lots of RAM, so people cannot use
sessions
for personal websites. i don’t know also where the speed is lost, maybe
in
routes.rb, in dispatch …i don’t know.
heri
Con: You get spoiled and then frustrated when your boss or a client
requires
you to go back to PHP or J2EE for whatever reason. Better not to taste
butter on your sweet potatoes.
2006/8/17, zer0halo [email protected]:
Con: You get spoiled and then frustrated when your boss or a client
requires you to go back to PHP or J2EE for whatever reason. Better not to
taste butter on your sweet potatoes.
Good point, but you can use mod_rewrite to make your boss believe you
wrote
it in PHP :angel…
Con: most girls I know don’t know what the hell is Rails, so it’s not
impressive for them. And don’t try to explain. It will be worse…!!!
Rodrigo F. wrote:
Con: most girls I know don’t know what the hell is Rails, so it’s not
impressiv3 for them. And don’t try to explain. It will be worse…!!!
Just tell them you’re a Railer, and you’re good at it. 
Joe
Con: You get spoiled and then frustrated when your boss or a client
requires you to go back to PHP or J2EE for whatever reason. Better not to
taste butter on your sweet potatoes.Good point, but you can use mod_rewrite to make your boss believe you wrote
it in PHP :angel…Con: most girls I know don’t know what the hell is Rails, so it’s not
impressive for them. And don’t try to explain. It will be worse…!!!
Pro: Most girls know what ruby’s are however…
But i still think that speed is the crucial problem for rails.but a lot of
un-technical people i have talked to think that rails websites are slow. i
Not that you’re wrong, but how many of these sites use
rounded-corner-css
pages? We did for awhile, and when we dropped it noticed a huge (user
perspective) speed improvement. In our case we had so many buckets that
it just took the browser longer to render them… Seems most of the
rounded-corner-css sites out there (at least that i’ve seen) are
rails…
anyway, might be osmething, might not.
have asked questions about what they think about backpack or 43things and
they reckon it could be faster. they don’t know about database or RAM
problems or processing power. and you agree with me that users have the
ultimate word.i just know that rails talks a lot. for example, it needs at least a ‘show
fields’ commands for each request.
Really? I thought that was only in development mode? In production it
did it once, then saved it, no?
sessions slows the website down unless you have memcache, which needs
lots of RAM, so people cannot use sessions for personal websites. i
Why can’t people use file based sessions? That’s what PHP uses by
default? Can’t believe that Ruby’s file IO is that much slower than
PHP’s…
don’t know also where the speed is lost, maybe in routes.rb, in dispatch
…i don’t know.
There’s more to ruby/rails… I imagine if you picked an active-record
like framework for PHP you’d find the same slowdowns… it just takes
more
work to do it that way than to do everythign with custom sql queries…
at least that’s my 2 cents