Rails - Aug 2006 - What are the cons of using rails?

Performace hits?  Integration with existing applications?  Security? 
Bugs?  Memory use?

-Ben Lisbakken

-- 
Posted via http://www.ruby-forum.com/.

On 8/15/06, Ben Lisbakken <lisbakke@gmail.com>
wrote:
> Performace hits?  Integration with existing applications?  Security?
> Bugs?  Memory use?
The biggest con for me is defending Rails against all the (perceived)
hype among non- Ruby programmers.

Most all the programmers I''ve discussed Rails with over the past year
or so think learning Ruby and Rails is high risk as it may very well
fizzle out at some point in the future.  Many languages come and go,
even more so with MVC frameworks the past few years.  I believe in
Rails but conveying my reasons for that leap of faith into learning it
to someone else is no simple task.

For me it''s like 1997-98 all over again.  I woke up one morning (back
then) and realized if I learned PHP that I could stop coding in Perl.
I worked at it and it became a reality and I haven''t touched any Perl
in my daily job in a long, long time.  (I absolutely despise timtowtdi
with my mortal soul.)  But lately I''ve been waking up thinking if I
master Ruby and Rails, at some point I can pretty much stop writing
PHP for a living.

Some might consider another major con to be all the books you might
need to buy..  and how quickly they become outdated.


-- 
Greg Donald
http://destiney.com/

+1 on that.

I spend a lot of time spreading the word on Ruby on Rails. Here''s the
thing
though: If you''re in IT, you are expected to learn new skills to get
things
done.  Rails will eventually lose momentum to something better.  Right now,
it makes me more productive and helps me stay creative. (Less busy work
means more cool features and more time solving the real problems.)

Here''s my list of cons though:

1. Rails productivity takes a huge dive if you are forced to work with a
legacy schema. It''s designed to make you productive if you can do
things
using the conventions. If you can''t, you''ll spend much more
time.

2. Rails is only 100x more productive than PHP if
   * you scaffold everything and leave it alone (simple blogs or cookbooks)
   * you don''t write any tests

3. Learning Rails is difficult, especially if you come from a Java world.
You expect things to be harder. It''s also harder to learn by example
because
the really good programmers use a lot of tricks that are unique to Ruby
itself.   You don''t HAVE to do things the Ruby way, but if you
don''t learn
Ruby well, you''ll be at a disadvantage.

4. Documentation is lacking. This is being worked on, but there is an
emphasis on "free framework, pay for training" in this community.
Personally, I have no problem with that as I make some decent money from
training and it''s something that I really enjoy. However, some people
think
that free projects should make everything free.

5. Rails is new. It''s a little rough in a few areas. However,
I''ve never
seen a 1.x version run this smoothly.

6. Deployment is unfriendly. Don''t believe the hype... it takes work
and
understanding to do it right. Guess what? There will be a book on this
shortly.

There isn''t a single thing here that would deter me from using Rails or
recommending it to anyone else. The productivity gain is worth it.

Less time coding means more time with the kids, the wife, the girlfriend,
the bar, the race track, or just more projects.

:)

-bph



On 8/15/06, Greg Donald <gdonald@gmail.com> wrote:
>
> On 8/15/06, Ben Lisbakken <lisbakke@gmail.com> wrote:
> > Performace hits?  Integration with existing applications?  Security?
> > Bugs?  Memory use?
>
> The biggest con for me is defending Rails against all the (perceived)
> hype among non- Ruby programmers.
>
> Most all the programmers I''ve discussed Rails with over the past
year
> or so think learning Ruby and Rails is high risk as it may very well
> fizzle out at some point in the future.  Many languages come and go,
> even more so with MVC frameworks the past few years.  I believe in
> Rails but conveying my reasons for that leap of faith into learning it
> to someone else is no simple task.
>
> For me it''s like 1997-98 all over again.  I woke up one morning
(back
> then) and realized if I learned PHP that I could stop coding in Perl.
> I worked at it and it became a reality and I haven''t touched any
Perl
> in my daily job in a long, long time.  (I absolutely despise timtowtdi
> with my mortal soul.)  But lately I''ve been waking up thinking if
I
> master Ruby and Rails, at some point I can pretty much stop writing
> PHP for a living.
>
> Some might consider another major con to be all the books you might
> need to buy..  and how quickly they become outdated.
>
>
> --
> Greg Donald
> http://destiney.com/
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060815/7af82f04/attachment.html

it''s not "corporate", not "enterprise",
it''s driven by good sense. You
will have lots of difficulties to sell the idea in these environments 
(believe me)...

Jean-Etienne

-- 
Posted via http://www.ruby-forum.com/.

Memory use is good. At least it''s a few times better than
Java''s.

Almost all cons regarding Ruby on Rails relate to it''s youth. The
documentation is not good enough but mostly it''s the fact that there
isn''t enough code floating around. If you are developing in
Java/PHP/Perl you can always do a quick krugle.com search and see at
least 10 different solutions to what you are trying to accomplish.
Search for the word "session" in PHP and you see 72.595 different PHP
files. Do the same for Ruby and you get 387.



On 8/15/06, Ben Lisbakken <lisbakke@gmail.com>
wrote:
> Performace hits?  Integration with existing applications?  Security?
> Bugs?  Memory use?
>
> -Ben Lisbakken
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

-- 
--------------
Jon Gretar Borgthorsson
http://www.jongretar.net/

Brian Hogan wrote:
> [...]
> Right now, it makes me more productive and helps me stay 
> creative. (Less busy work means more cool features and more time solving 
> the real problems.)
yeah, that''s surely a pro.
> Here''s my list of cons though:
> 
> 1. Rails productivity takes a huge dive if you are forced to work with a 
> legacy schema. It''s designed to make you productive if you can do
things
> using the conventions. If you can''t, you''ll spend much
more time.
I don''t know what do you mean about a legacy schema. If I check my 
manual, surely Rails accepts well the normal forms required to ensure 
your database-driven applications run properly, so if you can''t, you 
will spend more time but who''s guilty? you, not Rails.
> 2. Rails is only 100x more productive than PHP if
>    * you scaffold everything and leave it alone (simple blogs or cookbooks)
If you scaffold anything with script/generate scaffold, and edit the 
code by copying and pasting to get the result you want, Rails isn''t
100x
productive as PHP is, but it surely is 90x... still more!

In fact, I didn''t see Rails (or Ruby as a sole language) changing
naming
conventions, something that helps developers. Think: If we compare, PHP 
has many brain-storming naming conventions like:

strreplace (object then verb)
move_uploaded_file (verb then object)
rewind (just the verb)

or:

move_uploaded_file (with underscores)
strreplace (without underscores).
>    * 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.
> 3. Learning Rails is difficult, especially if you come from a Java 
> world. You expect things to be harder.
Not harder: different.
> It''s also harder to learn by 
> example because the really good programmers use a lot of tricks that are 
> unique to Ruby itself.   You don''t HAVE to do things the Ruby way,
but
> if you don''t learn Ruby well, you''ll be at a
disadvantage.
Sounds like learning Ruby is the same as learning Assembler, and it 
surely is not.
> 4. Documentation is lacking. This is being worked on, but there is an 
> emphasis on "free framework, pay for training" in this community.
In my point of view, yes, but it''s because Rails is relatively new.
> Personally, I have no problem with that as I make some decent money from 
> training and it''s something that I really enjoy. However, some
people
> think that free projects should make everything free.
Opensource has to be financed in some ways. Surely Rails kids hadn''t to
pay for Ruby, and Ruby hadn''t to pay for GCC, and GCC hadn''t
to pay for
Linux... But programmers are human, not programmers. As humans, they 
have to eat, too.
> 5. Rails is new. It''s a little rough in a few areas. However,
I''ve never
> seen a 1.x version run this smoothly.
Being new doesn''t mean immature. Bad point of view. If you look to 
Windows Vista, it''s new and some corporate guys are using it just 
because it''s "a new technology". Being new is not a
reference. Something
new could be worked in the darkness for years (as .NET did since 1999).
> 6. Deployment is unfriendly. Don''t believe the hype... it takes
work and
> understanding to do it right. Guess what? There will be a book on this 
> shortly.
ok, this is very true.
> There isn''t a single thing here that would deter me from using
Rails or
> recommending it to anyone else. The productivity gain is worth it.
I don''t want to make a holy war, I just want to give an
"optimistic"
point of view. As a database administrator and systems architect, i 
found rails is enough for many industry-related works.
> Less time coding means more time with the kids, the wife, the 
> girlfriend, the bar, the race track, or just more projects.
...or more beer!

:D

--
Rodrigo Fuentealba Cartes
Software Developer / Systems Architect
Par?s & Alvarez Ingenieros Asociados
Concepcion, Chile.

On 8/15/06, Ben Lisbakken <lisbakke@gmail.com>
wrote:
> Performace hits?  Integration with existing applications?  Security?
> Bugs?  Memory use?
Cons of using Rails for *what*?  That''s like asking "what are the
cons
of using a shovel?"

Joe

I"ll condense what Brian Hogan said in points 3-5. Learning Rails is a 
huge amount to swallow (likely less so if you''re coming from Java or 
.Net), made even more difficult by the sparse documentation. I''ve also 
encountered several rough edges, banged my head against them, then found 
a solution by googling and finding somebody else who encountered the 
same problem and figured out a solution -- oftentimes all of this being 
a result of incomplete documentation. I''ve submitted many tickets to
dev
when it was working. In the meantime, I just add to the wiki.

But since switching to Rails, I do have a lot more free time and have 
been getting a LOT more things done.

Joe

-- 
Posted via http://www.ruby-forum.com/.

Joe Van Dyk wrote:
> On 8/15/06, Ben Lisbakken <lisbakke@gmail.com> wrote:
>> Performace hits?  Integration with existing applications?  Security?
>> Bugs?  Memory use?
> 
> Cons of using Rails for *what*?  That''s like asking "what are
the cons
> of using a shovel?"
> 
> Joe
I think he''s asking what are the cons of using a *pickaxe* ;P

Joe

-- 
Posted via http://www.ruby-forum.com/.

On 8/15/06, Rodrigo Fuentealba <darkprox@gmail.com>
wrote:
> If I check my
> manual, surely Rails accepts well the normal forms required to ensure
> your database-driven applications run properly, so if you can''t,
you
> will spend more time but who''s guilty? you, not Rails.
Not all Rails apps will use a new database schema, some will use an
old schema with established field names that are unchangable for
whatever reason.  It does take additional time to deal with this sort
of setup.
> If you know what you are doing, you don''t have to write any tests.
I''m quite happy the Rails developers write tests in spite of their
knowledge level.  Being smart is terrible reason to not write tests.
I''d rather just admit the truth, I''m lazy sometimes.
> Opensource has to be financed in some ways. Surely Rails kids
hadn''t to
> pay for Ruby, and Ruby hadn''t to pay for GCC, and GCC
hadn''t to pay for
> Linux... But programmers are human, not programmers. As humans, they
> have to eat, too.
Some people code because they like to code, not because they need to
make money from their works.
> > 5. Rails is new. It''s a little rough in a few areas. However,
I''ve never
> > seen a 1.x version run this smoothly.
>
> Being new doesn''t mean immature. Bad point of view. If you look to
> Windows Vista, it''s new and some corporate guys are using it just
> because it''s "a new technology".
Corporate guys are idiots.
> Being new is not a reference. Something
> new could be worked in the darkness for years (as .NET did since 1999).
Darkness is the best place for .net and M$.  Bottom of the ocean,
rocket ship to another planet, whatever.
> ...or more beer!
Or more Ruby and Rails books.


-- 
Greg Donald
http://destiney.com/

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 start
- Rails is a particularly good fit for a defined problem space (e.g.
non-legacy database, single-app database, Ajax interfaces, MVC
architecture).  Once you go outside that problem space, for whatever
reason, most of the productivity improvements in Rails disappear very
quickly
- lack of a big pool of Rails developers.  It''s improving, but
compared to Java and C# there''s a long way to go

Regards

Dave M.

On 16/08/06, Greg Donald <gdonald@gmail.com>
wrote:
> On 8/15/06, Rodrigo Fuentealba <darkprox@gmail.com> wrote:
> > If I check my
> > manual, surely Rails accepts well the normal forms required to ensure
> > your database-driven applications run properly, so if you
can''t, you
> > will spend more time but who''s guilty? you, not Rails.
>
> Not all Rails apps will use a new database schema, some will use an
> old schema with established field names that are unchangable for
> whatever reason.  It does take additional time to deal with this sort
> of setup.
>
> > If you know what you are doing, you don''t have to write any
tests.
>
> I''m quite happy the Rails developers write tests in spite of their
> knowledge level.  Being smart is terrible reason to not write tests.
> I''d rather just admit the truth, I''m lazy sometimes.
>
> > Opensource has to be financed in some ways. Surely Rails kids
hadn''t to
> > pay for Ruby, and Ruby hadn''t to pay for GCC, and GCC
hadn''t to pay for
> > Linux... But programmers are human, not programmers. As humans, they
> > have to eat, too.
>
> Some people code because they like to code, not because they need to
> make money from their works.
>
> > > 5. Rails is new. It''s a little rough in a few areas.
However, I''ve never
> > > seen a 1.x version run this smoothly.
> >
> > Being new doesn''t mean immature. Bad point of view. If you
look to
> > Windows Vista, it''s new and some corporate guys are using it
just
> > because it''s "a new technology".
>
> Corporate guys are idiots.
>
> > Being new is not a reference. Something
> > new could be worked in the darkness for years (as .NET did since
1999).
>
> Darkness is the best place for .net and M$.  Bottom of the ocean,
> rocket ship to another planet, whatever.
>
> > ...or more beer!
>
> Or more Ruby and Rails books.
>
>
> --
> Greg Donald
> http://destiney.com/
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

What are the problems with Rails and "legacy" databases? AFAIK, 
composite keys, but I think Dr. Nic has a plugin that addresses that. 
Anything else?

Joe

-- 
Posted via http://www.ruby-forum.com/.

> What are the problems with Rails and "legacy" databases? AFAIK,
> composite keys, but I think Dr. Nic has a plugin that addresses that.
> Anything else?
You lose all the conventions... so you have to sprinkle a lot of 
set_table_name() and friends in your models...

not that big of a deal if you ask me...

-p

Greg Donald wrote:
> Not all Rails apps will use a new database schema, some will use an
> old schema with established field names that are unchangable for
> whatever reason.  It does take additional time to deal with this sort
> of setup.
but it''s *still* less code, since 3NF helps a lot here. I
haven''t had
problems even by using OIDs in PostgreSQL... So, why coding more than 
needed?

Clean code, less tricks, more extensibility. I found, at least in my 
project, that Rails has everything I need for my own development, and 
offers more than PHP itself.
>> If you know what you are doing, you don''t have to write any
tests.
> 
> I''m quite happy the Rails developers write tests in spite of their
> knowledge level.  Being smart is terrible reason to not write tests.
> I''d rather just admit the truth, I''m lazy sometimes.
I didn''t say "I''m smart, I don''t write
tests", I usually write tests
when the code isn''t clear for *my* way of attacking a problem. But
it''s
not completely needed, that''s what I mean.
>> Opensource has to be financed in some ways. Surely Rails kids
hadn''t to
>> pay for Ruby, and Ruby hadn''t to pay for GCC, and GCC
hadn''t to pay for
>> Linux... But programmers are human, not programmers. As humans, they
>> have to eat, too.
> 
> Some people code because they like to code, not because they need to
> make money from their works.
You said: "some". And I know what are you pointing to, and I will 
support your idea with my experience: I am working at my job, not 
because I had a "Microsoft Certified Professional" diplomma, nor an 
"Oracle Certified DBA" one. It''s because I had supported open
source
projects in the past (mostly academic implementations here in Chile). I 
didn''t get money for them, but I got a good job because of them.

Programming open source requires good skills, and being successful in a 
project means you have good skills, and there are some places (mainly 
academic ones) in where if you programmed PHP/Perl for 3 years means 
more than programming Visual Basic for 3 years.
>> Being new doesn''t mean immature. Bad point of view. If you
look to
>> Windows Vista, it''s new and some corporate guys are using it
just
>> because it''s "a new technology".
> 
> Corporate guys are idiots.
I agree. But they have a point of view, that should be considered, not 
in a specific way but in the general way. Never say something is bad 
because it''s new.
> Darkness is the best place for .net and M$.  Bottom of the ocean,
> rocket ship to another planet, whatever.
I don''t find .NET to be bad. It was built in a bad platform,
that''s
*another* story. But the way it interacts with another programs is not a 
point to discuss. Why then Miguel de Icaza wrote Mono? Because .NET as 
an architecture is bad?

Holy wars don''t make anyone happy.
>> ...or more beer!
> 
> Or more Ruby and Rails books.
...I will write one and I will sell it: 2.5 beers the unit.! :D ok ok 
bad joke.

Philip Hallstrom wrote:
>> What are the problems with Rails and "legacy" databases?
AFAIK,
>> composite keys, but I think Dr. Nic has a plugin that addresses that.
>> Anything else?
what do you understand as "legacy" or "not legacy"
db''s? I''m not english
speaker so I missed the point.

Rodrigo Fuentealba wrote:
>>> If you know what you are doing, you don''t have to write
any tests.
>> 
>> I''m quite happy the Rails developers write tests in spite of
their
>> knowledge level.  Being smart is terrible reason to not write tests.
>> I''d rather just admit the truth, I''m lazy sometimes.
> 
> I didn''t say "I''m smart, I don''t write
tests", I usually write tests
> when the code isn''t clear for *my* way of attacking a problem. But
it''s
> not completely needed, that''s what I mean.
To me, test are more insurance than anything else. I don''t want to get 
scatter-brained trying to remember everything that might break by 
changing code, and don''t want to get caught with my pants down when it 
does.

Joe

-- 
Posted via http://www.ruby-forum.com/.

Rodrigo Fuentealba wrote:
> Philip Hallstrom wrote:
>>> What are the problems with Rails and "legacy" databases?
AFAIK,
>>> composite keys, but I think Dr. Nic has a plugin that addresses
that.
>>> Anything else?
> 
> what do you understand as "legacy" or "not legacy"
db''s? I''m not english
> speaker so I missed the point.
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).

Joe

-- 
Posted via http://www.ruby-forum.com/.

> 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 start
Our 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 lot :)

Not 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

> Rodrigo Fuentealba wrote:
>> Philip Hallstrom wrote:
>>>> What are the problems with Rails and "legacy"
databases? AFAIK,
>>>> composite keys, but I think Dr. Nic has a plugin that addresses
that.
>>>> Anything else?
>>
>> what do you understand as "legacy" or "not legacy"
db''s? I''m not english
>> speaker so I missed the point.
>
> 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).
Not necessarily... legacy just means "existed before I started my rails 
app".  For instance you might have a table:

employee
----------
employee_id
fname
lname
address   <--- foreign key to ''address'' table.


Nothing wrong with this table, except that Rails would prefer by 
convention:

employees
---------
id
fname
lname
address_id


So you have to tell Rails (through your models) what to look for since 
you''re not going to be able to follow it''s convention.

-philip

Out of curiousity-- how many servers do you have (and what''s the
level of hardware)?


bill


Philip Hallstrom 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 start
> 
> Our 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 lot :)
> 
> Not 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
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

> To me, test are more insurance than anything else. I don''t want to
get
> scatter-brained trying to remember everything that might break by 
> changing code, and don''t want to get caught with my pants down
when it
> does.
Good answer, when it is a big project. That''s surely a very good pro
for
Rails over PHP. (even using a framework -not-sf-or-cakephp- ).

Philip Hallstrom wrote:
> <snip>
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

-- 
Posted via http://www.ruby-forum.com/.

Joe Ruby 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 Hallstrom 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 start
> 
> Our 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 lot :)
> 
> Not 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 Lisbakken

-- 
Posted via http://www.ruby-forum.com/.

> 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.
>
>
> bill
>
>
> Philip Hallstrom 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 start
>> 
>> Our 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 lot :)
>> 
>> Not 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
>> _______________________________________________
>> Rails mailing list
>> Rails@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>> 
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On Tue, Aug 15, 2006 at 04:26:09PM -0400, Rodrigo Fuentealba
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

Brian Hogan wrote:
> stuff
I pretty much agree with everything said here.

-- 
Posted via http://www.ruby-forum.com/.

Matthew Palmer wrote:
> On Tue, Aug 15, 2006 at 04:26:09PM -0400, Rodrigo Fuentealba 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!! :P
> 
> - Matt
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

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

-- 
______________
Heri R.
http://sprinj.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060816/8ad18e90/attachment.html

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:devin@ben-hur.net

  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

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


On 8/16/06, Devin Ben-Hur <devin@ben-hur.net>
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
>
> 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:devin@ben-hur.net
>
>   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
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


-- 
______________
Heri R.
http://sprinj.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060817/1484a6e7/attachment.html

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.

-- 
"Impossible is nothing."
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060817/3aff9afc/attachment.html

2006/8/17, zer0halo <zerohalo@gmail.com>:
>
> 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...!!!

--
RFC
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060817/e25298c3/attachment.html

Rodrigo Fuentealba 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. ;P

Joe

-- 
Posted via http://www.ruby-forum.com/.

>> 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 :)
>
> heri
>
>
> On 8/16/06, Devin Ben-Hur <devin@ben-hur.net> 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
>> 
>> 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:devin@ben-hur.net
>>
>>   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
>> 
>> _______________________________________________
>> Rails mailing list
>> Rails@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
>> 
>
>
>
> -- 
> ______________
> Heri R.
> http://sprinj.com
>

On Thu, 2006-08-17 at 18:41 -0400, heri rakotomalala
wrote:
> 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.
There''s this concept I have called "tuning density". 
It''s basically the
point at which changing the implementation of the design doesn''t buy
you
any more performance, and the only thing left is to redesign.  Even this
hits a certain tuning density when no design makes the application
faster, and the only thing left is to change to a faster platform.  This
continues until you just cannot make it faster without a change in how
the universe works.

You can usually spot when you''re at the tuning density of a system when
the effort to increase it''s speed is greater than the performance gain
you get.  At this point you have to look for alternative ways to make
the system faster or get deeper in the rabbit hole and do a complete
redesign.

I also say that tuning density is different from a bottleneck as it''s
not a single identifiable performance killer, but just a factor of how
the system is implemented.  Changing it involves a complete rethinking
of the application so you''re stuck finding an alternative solution if
you can''t make the change.

My opinion is that Rails is at it''s tuning density.  Folks like Stefan
Kaes and myself (indirectly) have been pounding on it in an attempt to
make it faster, but the effort just doesn''t match the gains.  I think
this is a combination of two factors:

1)  Biggest limiting factor is that Rails isn''t thread safe, so it has
to be locked.  Changing this though would involve a major redesign
(thus, it''s the current tuning density cause I think).
2)  Ruby itself has such poor IO facilities and other processing limits
that only a magical complete rewrite or getting rails to run on
something else will improve things.  I know most people yell and scream
that I''m an idiot when I point out the emperor has no clothes, but
remember I''m writing a web server AND client.  The people yelling
aren''t
even nearly as close to this as I am.

My suggestion right now is that you can''t do anything about the above
two short of getting in there and fixing the problem yourself or trying
your app on something like jruby or the latest ruby 1.9 vm.

What you *must* focus on--especially if your performance problem is
based on user perception--is how to make your application *seem* faster
to the users.  This involves less mucking with code and more observation
and measurement of what users think.  People are visually pretty dumb,
so you''d be amazed at what little stupid tricks you can do to simply
make them believe your stuff is quick.

Just remember, humans don''t have a stop watch embedded in the side of
their skull with nanosecond accuracy.  For them, it''s how they think
about their experience that makes the difference.

Finally, I''d say that the most annoying thing I get from rails coders
is
"potpourri turd syndrome" when it comes to performance.  This is where
they assume whatever crap they slapped into their actions is golden and
smells like flowers, and therefore it must be [mongrel, ruby, rails,
etc.].  Before you go screaming at the performance of rails, do what I
did and quadruple check that it''s not your code messing things up or
running slow.

You wouldn''t believe how many times I''ve talked to someone
with a
problem, and then upon looking at their code find out that they''re
doing
something stupid.  Not to mention, how many times I''ve had the same
person argue with me that their code is fine before finally having to
admit it''s crap.

Anyway, hope that gives some food for thought.


-- 
Zed A. Shaw
http://www.zedshaw.com/
http://mongrel.rubyforge.org/
http://www.railsmachine.com/ -- Need Mongrel support?

Joe Ruby wrote:
> Eleo wrote:
>> 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).
Ruby might do better on memory than PHP, but Ruby on Rails definitely 
doesn''t. My FastCGI PHP processes each use about 5-6 MB RAM (+10 MB 
shared), with eAccelerator and big applications like Mediawiki. My Rails 
LSAPI/FastCGI processes are between 20 and 30 MB, with Mongrel 30-40 
(almost no shared memory used). And don''t forget that you need multiple
processes for each Rails appication, whereas you can host any number of 
applications with just one set of PHP processes.

-- 
Posted via http://www.ruby-forum.com/.

Andreas Schwarz wrote:
> Joe Ruby wrote:
>> Eleo wrote:
>>> 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).
> 
> Ruby might do better on memory than PHP, but Ruby on Rails definitely 
> doesn''t. My FastCGI PHP processes each use about 5-6 MB RAM (+10
MB
> shared), with eAccelerator and big applications like Mediawiki. My Rails 
> LSAPI/FastCGI processes are between 20 and 30 MB, with Mongrel 30-40 
> (almost no shared memory used). And don''t forget that you need
multiple
> processes for each Rails appication, whereas you can host any number of 
> applications with just one set of PHP processes.
Shrug. Memory''s cheap. And it probably equals out with Apache being a 
big memory hog compared to Lighty and Mongrel.

Joe

-- 
Posted via http://www.ruby-forum.com/.

Joe Ruby wrote:
> Andreas Schwarz wrote:
>> Joe Ruby wrote:
>>> Eleo wrote:
>>>> 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).
>> 
>> Ruby might do better on memory than PHP, but Ruby on Rails definitely 
>> doesn''t. My FastCGI PHP processes each use about 5-6 MB RAM
(+10 MB
>> shared), with eAccelerator and big applications like Mediawiki. My
Rails
>> LSAPI/FastCGI processes are between 20 and 30 MB, with Mongrel 30-40 
>> (almost no shared memory used). And don''t forget that you need
multiple
>> processes for each Rails appication, whereas you can host any number of
>> applications with just one set of PHP processes.
> 
> Shrug. Memory''s cheap.
Think of shared hosting. With PHP you can put any number of websites on 
one server, the only thing that matters is the total number of hits the 
sites get. With Rails you need at least one process per site constantly 
running, or the startup time will make the response unacceptably slow.
> And it probably equals out with Apache being a 
> big memory hog compared to Lighty and Mongrel.
Apache a memory hog compared to Mongrel? Absolutely not. Anyway, nobody 
forces you to use PHP with Apache, it works just as well with Lighttpd, 
Litespeed etc.

-- 
Posted via http://www.ruby-forum.com/.

Using more or less memory isn''t a good measure. PHP shares memory
across
many sessions, since Ruby doesn''t. PHP also has a lot of things Ruby
doesn''t
have itself... (also not a good measure: lots of things that the 3% of the
developers use but still in our memory)

Don''t test Ruby with PHP on CentOS, Fedora or another ones. The more
modules
has PHP, more memory uses. I compiled it just with PostgreSQL extension
(leaving XML and a lot of stuff I won''t use), and it is very fast.

About Rails, yeah, but... how much work does it take to have a website with
the same interactivity as a Rails generated one? Rails runs on top of Ruby,
but there are another frameworks written in PHP which run on top of their
functions that are finally the functions that run on top of PHP. The more
layers you add (supposing that those don''t discriminate between
model-view-controller like Rails do) the more complex is to debug the entire
Rails site. Let''s take any CMS. The bug appears one day and a week
after it
has been patched and no one noticed it. Let''s take Rails 1.1.4, how
much
time did it take to be patched?

I am not in conditions to run a fine-tuned Rails site, because I know I
still have very much to learn about it. But if someone wants to do it, I
offer my time and knowledge about PHP to fine-tune an application on top of
it and lets see which one is better, measuring:

1.- usability
2.- accesibility
3.- resources utilized

any other items?

Right now I am building an Intranet with it, while the clients platform is
in PHP and the documentation interface is in .NET... Nothing hard, but Rails
give me the enough time to implement more and more things.

BTW, nice ideas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060818/5aa9f5b6/attachment.html

Andreas Schwarz wrote:
> Joe Ruby wrote:
>> Andreas Schwarz wrote:
>>> Joe Ruby wrote:
>>>> Eleo wrote:
>>>>> 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).
>>> 
>>> Ruby might do better on memory than PHP, but Ruby on Rails
definitely
>>> doesn''t. My FastCGI PHP processes each use about 5-6 MB
RAM (+10 MB
>>> shared), with eAccelerator and big applications like Mediawiki. My
Rails
>>> LSAPI/FastCGI processes are between 20 and 30 MB, with Mongrel
30-40
>>> (almost no shared memory used). And don''t forget that you
need multiple
>>> processes for each Rails appication, whereas you can host any
number of
>>> applications with just one set of PHP processes.
>> 
>> Shrug. Memory''s cheap.
> 
> Think of shared hosting. With PHP you can put any number of websites on 
> one server, the only thing that matters is the total number of hits the 
> sites get. With Rails you need at least one process per site constantly 
> running, or the startup time will make the response unacceptably slow.
Well, yeah, processes are segmented according to site (which is probably 
a good thing), but still with Apache and PHP, each connection needs an 
Apache process, which has a PostgreSQL/MySQL connection.

Joe

-- 
Posted via http://www.ruby-forum.com/.

> Think of shared hosting. With PHP you can put any number of websites on
> one server, the only thing that matters is the total number of hits the
> sites get. With Rails you need at least one process per site constantly
> running, or the startup time will make the response unacceptably slow.
Php is a particular case.  Compare rails to other frameworks written
in interpreted/byte compiled languages and it compares about the same.
  rails/mod perl/mod python/jboss are all frameworks built on top of a
general purpose programming language.   Most of the functionality of
the frameworks use modules/libraries that are coded in the language
the framework is built on , plus the memory footprint of the language
itself, whatever that is.  Comparing php to these other frameworks
isn''t really fair.  The similarities are only skin deep.

Joe Ruby wrote:
> Andreas Schwarz wrote:
>> Think of shared hosting. With PHP you can put any number of websites on
>> one server, the only thing that matters is the total number of hits the
>> sites get. With Rails you need at least one process per site constantly
>> running, or the startup time will make the response unacceptably slow.
> 
> Well, yeah, processes are segmented according to site (which is probably 
> a good thing), but still with Apache and PHP, each connection needs an 
> Apache process, which has a PostgreSQL/MySQL connection.
That''s the worst case setup. But it''s not really that
expensive to fork
a new Apache/mod_php process. After the fork most of the memory is 
shared, and a lot of it stays shared for the lifetime of the process. An 
interesting effect with Rails is that after a fork (LSAPI uses fork to 
create Rails listeners) the shared memory drops to almost zero after a 
few requests are handled.

-- 
Posted via http://www.ruby-forum.com/.

snacktime wrote:
>> Think of shared hosting. With PHP you can put any number of websites on
>> one server, the only thing that matters is the total number of hits the
>> sites get. With Rails you need at least one process per site constantly
>> running, or the startup time will make the response unacceptably slow.
> 
> Php is a particular case. 
Yes, but it can be compared.
> Compare rails to other frameworks written
> in interpreted/byte compiled languages and it compares about the same.
The only other thing I''ve got here to compare with is tracd, it uses 
9MB.

I''m often wondering: what is all this RAM actually used for, e.g. the 
30-40 MB of Mongrel+Rails? Is it object data, is it code, ...? Can 
anyone of the Ruby experts (Zed?) give me some insight?

-- 
Posted via http://www.ruby-forum.com/.

On Fri, 2006-08-18 at 01:49 +0200, Andreas Schwarz
wrote:
> Joe Ruby wrote:
> > Eleo wrote:
> >> 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).
> 
> Ruby might do better on memory than PHP, but Ruby on Rails definitely 
> doesn''t. My FastCGI PHP processes each use about 5-6 MB RAM (+10
MB
> shared), with eAccelerator and big applications like Mediawiki. My Rails 
> LSAPI/FastCGI processes are between 20 and 30 MB, with Mongrel 30-40 
> (almost no shared memory used). And don''t forget that you need
multiple
> processes for each Rails appication, whereas you can host any number of 
> applications with just one set of PHP processes.
> 
Wow, is that all?  Try Java sometime.  I''ve got a very simple little
app
running on Tomcat and IBM JDK that''s just translating SOAP calls to
XML.
The thing uses about  306m virt, 71m res, 2304 shr memory, and it can
spike to 150m res before I have to kill it.  Worst part is all this
thing does is run 10 jsps.  And this was after trying the Sun JDK which
is *much* worse.  It was so bad I couldn''t run the app on our VPS.

When it comes to RAM usage Java is king of all destruction.

-- 
Zed A. Shaw
http://www.zedshaw.com/
http://mongrel.rubyforge.org/
http://www.railsmachine.com/ -- Need Mongrel support?

On Fri, 2006-08-18 at 03:20 +0200, Andreas Schwarz
wrote:
> snacktime wrote:
> I''m often wondering: what is all this RAM actually used for, e.g.
the
> 30-40 MB of Mongrel+Rails? Is it object data, is it code, ...? Can 
> anyone of the Ruby experts (Zed?) give me some insight?
> 
Not sure at all as I haven''t looked into it.  For me 40M is a dream
compared to the monstrosity systems Java inspires.


-- 
Zed A. Shaw
http://www.zedshaw.com/
http://mongrel.rubyforge.org/
http://www.railsmachine.com/ -- Need Mongrel support?

Zed Shaw wrote:
> 2)  Ruby itself has such poor IO facilities and other processing limits
Can you elaborate on these limits? I''m not at all familiar with them.

Thanks,
Joe

-- 
Posted via http://www.ruby-forum.com/.

> 1)  Biggest limiting factor is that Rails isn''t thread safe, so it
has
> to be locked.  Changing this though would involve a major redesign
> (thus, it''s the current tuning density cause I think).
Is it unsafe all over or just in particular parts like AR?

Chris

On Thu Aug 17, 2006 at 11:04:39PM -0700, snacktime
wrote:
> >1)  Biggest limiting factor is that Rails isn''t thread safe,
so it has
> >to be locked.  Changing this though would involve a major redesign
> >(thus, it''s the current tuning density cause I think).
> 
> Is it unsafe all over or just in particular parts like AR?
http://permalink.gmane.org/gmane.comp.lang.ruby.mongrel.general/245
> 
> Chris
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

>
> http://permalink.gmane.org/gmane.comp.lang.ruby.mongrel.general/245
That''s scary.

Other problems ruby/rails has, and the reasons I honestly cannot 
recommend rails to be used for anything but personal projects.

a)	The rails code-base is not stable. Version 1.2 might very well break 
existing applications and require a newer version of ruby. Of course the 
solution would be to stick with the original version of rails.. However 
this is not always practical.

b)	In connection with a), I cannot even remotely guess where rails will 
be in a year from now. For example there has been talk of removing the 
webservices api from the rails codebase. (Yes it is then said to be 
further developed as a plugin, but for how long? There are already great 
rails 1.0 plugins which ceased to be compatible with 1.1)

c)	 Not enough ruby-programmers. It is simply too risky for a company to 
depend on one or two experienced ruby/rails programmer to take care of 
their website, which most often is there primary source of income. What 
if their web guru ceased to exist for some reason? A new php/java/.net 
and even python developer is easier to find than one experienced with 
ruby/rails.

d)	 Ruby. Not so much because its notorious slowness but because its 
lack of more advanced libraries or c-bindings. However this seems to be 
slowly improving, yet most ruby libraries have the tendency not to be 
maintained once its author is satisfied. This, again, does not bode well 
for future use. (For example an opensrs library, lucene API (but 
admittedly, ruby now has ferret) and ta-lib api would be welcome). 
However ruby is rather easy to extend. But having to code these 
library-bindings myself kind of mitigates rails largest advantage, fast 
to develop with. (It?s still fast, but you need to develop more)

a) and b) are imho the more serious issues. I imagine it is the result 
of this so called ?opinionated software?, but a lead developer that 
tells its software?s users that have certain, legitimate, issues to 
?shove it?.. Well.. imho it doesn?t bode well for ?stable? future 
versions of that software. (stable as in (backwards) compatible, 
smoothing issues users have)

-- 
Posted via http://www.ruby-forum.com/.

2006/8/18, Colin Cc <colin@3x.to>:
>
> Other problems ruby/rails has, and the reasons I honestly cannot
> recommend rails to be used for anything but personal projects.
>
> a)      The rails code-base is not stable. Version 1.2 might very well
> break existing applications and require a newer version of ruby. Of course
> the solution would be to stick with the original version of rails.. However
> this is not always practical.

read changelogs of PHP, Python, Perl and TODO''s. The only entirely
stable
language is Java, which sucks a lot in particular environments, apart of
being very hard to write something in there.

b)      In connection with a), I cannot even remotely guess where rails
will
> be in a year from now. For example there has been talk of removing the
> webservices api from the rails codebase. (Yes it is then said to be further
> developed as a plugin, but for how long? There are already great rails
1.0plugins which ceased to be compatible with
> 1.1)

having a small core is not a bad idea. faster, loads modules in execution
time instead of loading in startup like PHP does. But, as I say, read
changelogs.

c)       Not enough ruby-programmers. It is simply too risky for a
company
> to depend on one or two experienced ruby/rails programmer to take care of
> their website, which most often is there primary source of income. What if
> their web guru ceased to exist for some reason? A new php/java/.net and
even
> python developer is easier to find than one experienced with ruby/rails.

here in my country, .NET and Java are very popular... but PHP gurus... and
Python gurus... and Rails!!!

d)       Ruby. Not so much because its notorious slowness but because
its
> lack of more advanced libraries or c-bindings. However this seems to be
> slowly improving, yet most ruby libraries have the tendency not to be
> maintained once its author is satisfied. This, again, does not bode well
for
> future use. (For example an opensrs library, lucene API (but admittedly,
> ruby now has ferret) and ta-lib api would be welcome). However ruby is
> rather easy to extend. But having to code these library-bindings myself
kind
> of mitigates rails largest advantage, fast to develop with. (It''s
still
> fast, but you need to develop more)

can''t say anything about Ruby.

a) and b) are imho the more serious issues. I imagine it is the
result
> of this so called "opinionated software", but a lead developer
that
> tells its software''s users that have certain, legitimate, issues
to
> "shove it".. Well.. imho it doesn''t bode well for
"stable" future
> versions of that software. (stable as in (backwards) compatible,
> smoothing issues users have)

the most serious you have aren''t particular from Ruby, even .NET has
those
things.

Nice catch, try again.

-- 
Rodrigo Fuentealba Cartes
Registered User 387639 - http://counter.li.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060818/aff9e85c/attachment-0001.html

Rodrigo Fuentealba wrote:
> 
> read changelogs of PHP, Python, Perl and TODO''s. The only entirely
> stable
> language is Java, which sucks a lot in particular environments, apart of
> being very hard to write something in there.
> 
> b)      In connection with a), I cannot even remotely guess where rails 
> will
>> be in a year from now. For example there has been talk of removing the
>> webservices api from the rails codebase. (Yes it is then said to be
further
>> developed as a plugin, but for how long? There are already great rails
1.0plugins which ceased to be compatible with
>> 1.1)
All good points Rodrigo, but I think that Java is far from stable.

Each of the last three clients I worked at were migrating from 1.2x to 
1.4x, even though 1.5 has been out for more than a year.

The large banks and insurance companies I contract at do this to ensure 
stability. They won''t support multiple versions, so they stay way
behind
the curve on their upgrade path. They won''t even start completely new 
projects with 1.5, until they start their migration to 1.5.

So it seems that businesses interested in stability of  language treat 
Java the same way they would treat Ruby. We''ll upgrade when we are 
convinced none of our systems will break. That goes for Java, Ruby, or 
even COBOL. (yes they treated the upgrade from IBM COBOL II to IBM COBOL 
390 on the mainframe just like they treat upgrading Java).

So it seems the original poster''s complaints come down to "Ruby on
Rails
has the same exact problems as every other language and framwork have."

Thanks Rodrigo

-- 
Posted via http://www.ruby-forum.com/.

2006/8/18, sean lynch <sean.seanlynch@gmail.com>:
>
> Rodrigo Fuentealba wrote:
> >
> > read changelogs of PHP, Python, Perl and TODO''s. The only
entirely
> > stable
> > language is Java, which sucks a lot in particular environments, apart
of
> > being very hard to write something in there.
> >
> > b)      In connection with a), I cannot even remotely guess where
rails
> > will
> >> be in a year from now. For example there has been talk of removing
the
> >> webservices api from the rails codebase. (Yes it is then said to
be
> further
> >> developed as a plugin, but for how long? There are already great
rails
> 1.0plugins which ceased to be compatible with
> >> 1.1)
>
> All good points Rodrigo, but I think that Java is far from stable.

in its programming conventions? I am not an expert in Java, *cough*, but I
never knew that. Maybe the platform. I have a friend who programs Java
usually and he doesn''t complain about versioning and incompatibilities.

Each of the last three clients I worked at were migrating from 1.2x
to
> 1.4x, even though 1.5 has been out for more than a year.

I started with PHP 5.2RC2 for my devel, to avoid this problem at least for
the next 3 to 6 years.

The large banks and insurance companies I contract at do this to
ensure
> stability. They won''t support multiple versions, so they stay way
behind
> the curve on their upgrade path. They won''t even start completely
new
> projects with 1.5, until they start their migration to 1.5.

 Yup.

So it seems that businesses interested in stability of  language
treat
> Java the same way they would treat Ruby.

it helps developers to have more disposable jobs :P

We''ll upgrade when we are convinced none of our systems will break.


Hard but more money :P


That goes for Java, Ruby, or
> even COBOL. (yes they treated the upgrade from IBM COBOL II to IBM COBOL
> 390 on the mainframe just like they treat upgrading Java).

COBOL was a painful language, since it had little standards.

So it seems the original poster''s complaints come down to "Ruby on
Rails
> has the same exact problems as every other language and framwork
have."
>
> Thanks Rodrigo
>
It''s such code, even C has those problems (I treat C++ as an
object-oriented
extension of C, rather than a language itself). It now complains with
#include <iostream.h>, requiring just <iostream>...!!! Maybe the
framework
developers need to consider this on Rails, since this was a large thread.

-- 
Rodrigo Fuentealba Cartes
Registered User 387639 - http://counter.li.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060818/ddac90bb/attachment.html

sean lynch wrote:
> Rodrigo Fuentealba wrote:
>> read changelogs of PHP, Python, Perl and TODO''s. The only
entirely
>> stable
>> language is Java, which sucks a lot in particular environments, apart
of
>> being very hard to write something in there.
>>
>> b)      In connection with a), I cannot even remotely guess where rails
>> will
>>> be in a year from now. For example there has been talk of removing
the
>>> webservices api from the rails codebase. (Yes it is then said to be
further
>>> developed as a plugin, but for how long? There are already great
rails 1.0plugins which ceased to be compatible with
>>> 1.1)
> 
> All good points Rodrigo, but I think that Java is far from stable.
> 
> Each of the last three clients I worked at were migrating from 1.2x to 
> 1.4x, even though 1.5 has been out for more than a year.
> 
> The large banks and insurance companies I contract at do this to ensure 
> stability. They won''t support multiple versions, so they stay way
behind
> the curve on their upgrade path. They won''t even start completely
new
> projects with 1.5, until they start their migration to 1.5.
The large banks and insurance companies I work for use WebSphere, and 
until version 6.1 and its associated toolset arrives and they fully 
understand the implications of moving to it, they *can''t* start moving 
to Java 1.5. (WebSphere 6.1 is out, but the corresponding version of the 
Rational Application Developer toolset is not out yet.)
> So it seems that businesses interested in stability of  language treat 
> Java the same way they would treat Ruby. We''ll upgrade when we are
> convinced none of our systems will break. That goes for Java, Ruby, or 
> even COBOL. (yes they treated the upgrade from IBM COBOL II to IBM COBOL 
> 390 on the mainframe just like they treat upgrading Java).
And so Sun, IBM, and BEA support multiple versions of their application 
servers, JVMs, Java class libraries and tools concurrently. If a fix is 
needed, it will be made available for all affected versions that are 
still under support. The same is true for DBMSs, whether commercial or 
open-source.
> So it seems the original poster''s complaints come down to
"Ruby on Rails
> has the same exact problems as every other language and framwork
have."
No, in that fixes (with the possible exception of source patches) are 
only being provided for the latest version of Rails.

I just took a look to check on the PHP situation, and found:

"[17-Aug-2006]  The PHP development team would like to announce the 
immediate availability of PHP 5.1.5 and 4.4.4. These two releases 
address a series of security problems that were discovered since the 
release of PHP 5.1.4 and 4.4.3."

Given that AWDR version 1 is still selling, and must be approaching the 
50,000 copy mark, it would have been great if a version of Rails existed 
that was fully in line with the book and was actively being supported 
with bug fixes. (Of course, since Rails is open source, anybody who 
cares enough could do this, but installing the "book version" would 
require information on where to get it that is currently not in the book.)

So far as Ruby is concerned, is anyone else bothered that Ruby is 
written in pre-ANSI (K&R) C?

I think that Ruby and Rails are truly great, but there are always things 
that could be improved.

regards

   Justin

It''s all OK with everything we said here, different points of view and
everything.

About performance stuff, there''s nothing to do with it.
(Mis)configurations
have a special role here, security and webserver configuration also have
important roles. Code being managed or unmanaged have important roles such
when it''s about multiplatform. .NET is managed and Ruby too, but .NET
is
platform-specific so it has many tweaks to work as expected. .NET
hasn''t
many changes in their frameworks and difficultly something breaks between
Visual Basic 2003 and 2005 / ASP.NET 1.1 and 2.0.

After that, there''s one thing calling my attention:

I work in many languages, as you could notice in my responses to the list,
and none of these have good backwards compatibility. I programmed a
framework in PHP months ago (for the enterprise I am developing) and i found
out that there aren''t very much difficulties in maintaining a framework
and
stuff like a language should be also easy to make planning on syntax and
function reference, object-orientation and so on.

Why, then, people breaks backwards compatibility? Is it a way to keep
computer developers in the way of new migrations? Or it''s simply
because
making stuff compatible is bothering->boring? Or it''s bad
planification for
a language?

I go for bad planifications. I don''t know very much computer developers
who
can do good plannings on paper before programming... and the ones who did
planning (standard and personally applied diagrams), had more control over
their source codes. But, I would love to hear some other responses.

-- 
RFC
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060818/51deb139/attachment.html

On 8/17/06, Zed Shaw <zedshaw@zedshaw.com> wrote:
> 1)  Biggest limiting factor is that Rails isn''t thread safe, so it
has
> to be locked.  Changing this though would involve a major redesign
> (thus, it''s the current tuning density cause I think).
> 2)  Ruby itself has such poor IO facilities and other processing limits
> that only a magical complete rewrite or getting rails to run on
> something else will improve things.  I know most people yell and scream
> that I''m an idiot when I point out the emperor has no clothes, but
> remember I''m writing a web server AND client.  The people yelling
aren''t
> even nearly as close to this as I am.
>
> My suggestion right now is that you can''t do anything about the
above
> two short of getting in there and fixing the problem yourself or trying
> your app on something like jruby or the latest ruby 1.9 vm.

Zed,

Thanks very, very much for such an honest assessment of the situation.

It''s a disheartening read, but something I needed to read nontheless. I
have
a few questions for you if you have time:

- Given your comments above, do you feel that Rails is not the best choice
for production web applications if you intend to serve up a large number of
hits? By coding with Rails in its current state, it sounds like a programmer
may be painting themselves into a corner without a clear idea of how much
paint thinner is in supply (or, for that matter, if paint thinner will
*ever* be supplied).
- Do you feel the 1.9 vm resolves most of these issuse? I could imagine it
might resolve the IO slowness, but I presume it does nothing to solve the
thread safety issue.

I appreciate your input.

Jake
-
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060818/b07a6bbf/attachment.html

Yes, Ruby VM is slow, but I played with YARV and it beats the ass even 
to Parrot VM.

On some Fibonacci and Ackerman tests it was 40 times faster then current 
Ruby VM and
30-40%% faster then Parrot VM. I was really surprized and pleased with 
results.

PS: I just did this test yesterday. I used YARV-current.


All the Best!
Sergey.


Jake Cutter wrote:
> On 8/17/06, *Zed Shaw* <zedshaw@zedshaw.com 
> <mailto:zedshaw@zedshaw.com>> wrote:
>
>     1)  Biggest limiting factor is that Rails isn''t thread safe,
so it has
>     to be locked.  Changing this though would involve a major redesign
>     (thus, it''s the current tuning density cause I think).
>     2)  Ruby itself has such poor IO facilities and other processing
>     limits
>     that only a magical complete rewrite or getting rails to run on
>     something else will improve things.  I know most people yell and
>     scream
>     that I''m an idiot when I point out the emperor has no clothes,
but
>     remember I''m writing a web server AND client.  The people
yelling
>     aren''t
>     even nearly as close to this as I am.
>
>     My suggestion right now is that you can''t do anything about
the above
>     two short of getting in there and fixing the problem yourself or
>     trying
>     your app on something like jruby or the latest ruby 1.9 vm.
>
>
> Zed,
>
> Thanks very, very much for such an honest assessment of the situation.
>
> It''s a disheartening read, but something I needed to read
nontheless.
> I have a few questions for you if you have time:
>
> - Given your comments above, do you feel that Rails is not the best 
> choice for production web applications if you intend to serve up a 
> large number of hits? By coding with Rails in its current state, it 
> sounds like a programmer may be painting themselves into a corner 
> without a clear idea of how much paint thinner is in supply (or, for 
> that matter, if paint thinner will *ever* be supplied).
> - Do you feel the 1.9 vm resolves most of these issuse? I could 
> imagine it might resolve the IO slowness, but I presume it does 
> nothing to solve the thread safety issue.
>
> I appreciate your input.
>
> Jake
> -
>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Sorry for the jumping in, but, Ruby has slow I/O ? Compared to C with 
sysread perhaps, or pure assembler, then yes, but, do you have example 
timings and code that I could read as ''proof'' ? Hopefully your
not
basing this -purely- of a file.open and you -have- tried with file.read 
.. in much the same way as perl, python and java do ''behind the
scenes''
.. yes ?

Statements without sufficient evidence are merely personal conclusions ;)

Regards
Stef
(ps. I am not a language zealot by any means and have zero intention of 
starting/joining a flamefest ;)

Jake Cutter wrote:
> On 8/17/06, *Zed Shaw* <zedshaw@zedshaw.com 
> <mailto:zedshaw@zedshaw.com>> wrote:
>
>     1)  Biggest limiting factor is that Rails isn''t thread safe,
so it has
>     to be locked.  Changing this though would involve a major redesign
>     (thus, it''s the current tuning density cause I think).
>     2)  Ruby itself has such poor IO facilities and other processing
>     limits
>     that only a magical complete rewrite or getting rails to run on
>     something else will improve things.  I know most people yell and
>     scream
>     that I''m an idiot when I point out the emperor has no clothes,
but
>     remember I''m writing a web server AND client.  The people
yelling
>     aren''t
>     even nearly as close to this as I am.
>
>     My suggestion right now is that you can''t do anything about
the above
>     two short of getting in there and fixing the problem yourself or
>     trying
>     your app on something like jruby or the latest ruby 1.9 vm.
>
>
> Zed,
>
> Thanks very, very much for such an honest assessment of the situation.
>
> It''s a disheartening read, but something I needed to read
nontheless.
> I have a few questions for you if you have time:
>
> - Given your comments above, do you feel that Rails is not the best 
> choice for production web applications if you intend to serve up a 
> large number of hits? By coding with Rails in its current state, it 
> sounds like a programmer may be painting themselves into a corner 
> without a clear idea of how much paint thinner is in supply (or, for 
> that matter, if paint thinner will *ever* be supplied).
> - Do you feel the 1.9 vm resolves most of these issuse? I could 
> imagine it might resolve the IO slowness, but I presume it does 
> nothing to solve the thread safety issue.
>
> I appreciate your input.
>
> Jake
> -
>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Let me try to explain why stability / backwards-compatibility is an 
issue for me with rails.

Maybe I?m just unlucky, but in my 2 pet projects for which I use RoR I 
definitely suffered from backwards incompatibility. The first issue I 
had to deal with was scoping in active record. Nested scoping has been 
added, and as a result my plugin that kind of mimicked this behavior was 
broken. Not a serious obstacle, and fixable, but certainly annoying.
Then we have memcached activerecord. Worked great, less great when 1.1 
was introduced.
For rails 1.2 the routing part of framework will be redone. Again, bad 
luck for me, as I altered the behavior a bit.

Compared to other frameworks (for example symfony, django, webwork), 
rails is, again in my opinion, more vulnerable to source-code changes. 
Ever since I started with rails it has been advertised as a framework 
which is easy to extend (or break open).  And indeed, with the ruby 
language is extremely easy to alter objects during runtime. Of course, 
this only works as long as the internals of rails do not change. And the 
fact is, they do.. not only the internals of function calls change, but 
the behaviors of them as well. In a ?normal? framework, this is not an 
issue (it is why one has protected methods). However, with rails, in 
which custom configuration/behavior is to be implemented by (simple) 
plugins that indeed do either alter or extend such internal functions 
changes to the code can easily wreck damage to custom plugins. (This is 
the reason I mention symfony as php-framework and not something like 
cakephp.. pure rails in php doesn?t work for me.. because customizing it 
is hardly possible in an elegant way)

If rails didn?t depend so much on ?hacking: into the framework I?d 
probably be more forgiving to a little ?instability? in its codebase. 
Though they way rails works makes such instability difficult to accept.

-- 
Posted via http://www.ruby-forum.com/.

@Colin:

Your issues are a direct result of your choice to modify the framework to
suit your needs. When you do that  in ANY open-source project, the
responsibility shifts to you to make things work when new versions come out.
The Rails core makes no guarantees to anyone about plugins working after
upgrades; that''s why they allow for plugins instead of taking those
patches
into the core.

There''s usually a way to achieve what you want without modifying how
Rails
works... and you might want to explore ways to extend the framework rather
than modifying its behaviours directly.Make your own class that extends
ActiveRecord and extend your models from that for example or invesitage
using modules to apply behaviours as needed. Now, I don''t understand
your
specific situation but I bet there''s a solution that would work well
for
you.

I don''t see these as the fault of Rails. Rails doesn''t
"depend on hacking
into the framework". Just because Rails allows you to modify the core
doesn''t mean you have to, or should.

I''ve seen Java projects stuck at Hibernate 1.0 because upgrade paths
are not
an option due to customization. I''ve had to support running PHP 3, PHP
4,
and PHP 5 in order to keep apps running because developers can''t modify
the
apps to work in the later versions of PHP.

I don''t consider this a problem with Rails because it seems universal
to me.

Just my .02 and I want to say you have brought up some very good arguments.

Cheers!


On 8/18/06, Colin Cc <colin@3x.to> wrote:
>
> Let me try to explain why stability / backwards-compatibility is an
> issue for me with rails.
>
> Maybe I''m just unlucky, but in my 2 pet projects for which I use
RoR I
> definitely suffered from backwards incompatibility. The first issue I
> had to deal with was scoping in active record. Nested scoping has been
> added, and as a result my plugin that kind of mimicked this behavior was
> broken. Not a serious obstacle, and fixable, but certainly annoying.
> Then we have memcached activerecord. Worked great, less great when 1.1
> was introduced.
> For rails 1.2 the routing part of framework will be redone. Again, bad
> luck for me, as I altered the behavior a bit.
>
> Compared to other frameworks (for example symfony, django, webwork),
> rails is, again in my opinion, more vulnerable to source-code changes.
> Ever since I started with rails it has been advertised as a framework
> which is easy to extend (or break open).  And indeed, with the ruby
> language is extremely easy to alter objects during runtime. Of course,
> this only works as long as the internals of rails do not change. And the
> fact is, they do.. not only the internals of function calls change, but
> the behaviors of them as well. In a "normal" framework, this is
not an
> issue (it is why one has protected methods). However, with rails, in
> which custom configuration/behavior is to be implemented by (simple)
> plugins that indeed do either alter or extend such internal functions
> changes to the code can easily wreck damage to custom plugins. (This is
> the reason I mention symfony as php-framework and not something like
> cakephp.. pure rails in php doesn''t work for me.. because
customizing it
> is hardly possible in an elegant way)
>
> If rails didn''t depend so much on "hacking: into the
framework I''d
> probably be more forgiving to a little "instability" in its
codebase.
> Though they way rails works makes such instability difficult to accept.
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060818/0ed1e0d7/attachment.html

@Brian Hogan,

As you said, you noticed the same problem with other frameworks. However 
as I understand from your examples it where the developers of the final 
application that made the "hacks" into the framework.

Rails, atleast for me, is more or less all about modifying the 
framework. The whole ?DRY? principle is more or less about making rails 
behave to suit your needs. See for example all the plugins that use this 
way of customizing rails. Moreover, where in another framework I can 
configure most behaviour in rails getting the same behaviour inevitably 
means both extending/customizing classes, and using the new custom 
class. (But due to the magic going on this is not always as transparent 
as one would expect, for example telling rails to use RoutingExtend is 
going to be a lot more troublesome than simply customizing Routings 
behaviour to get that ".html" extension to work)

To me this situation simply spells out "trouble soon to be expected".
As
long as I''m in control, not much trouble. That''s why I?m
perfectly happy
with using rails on my own apps. But apps I develop for another, and 
that eventually might have to be maintained by another, might, in due 
time, surely somehow/somewhere result in something hard to fix. (Unless 
you choose not to use all those rails goodies ;))

While php5 (though it might not be fair to compare a language with a 
framework) indeed broke most php4 apps, at least php4 is still being 
maintained. With rails as soon as a new version arrives the old version 
is not. Django is being kept beta 0.x until their api is stable. And 
even webwork 2.2 only needed a few minor adjustments. I?ve never noticed 
such a rapid accession of backwards incompatible changes as I noticed 
while using rails. Maybe I?m just unlucky or rails makes is too easy to 
do the ?advanced? stuff that is breakable ;)

-- 
Posted via http://www.ruby-forum.com/.

On 8/18/06, Colin Cc <colin@3x.to> wrote:
> Compared to other frameworks (for example symfony, django, webwork),
> rails is, again in my opinion, more vulnerable to source-code changes.
> Ever since I started with rails it has been advertised as a framework
> which is easy to extend (or break open). .....
Don''t put your trust in symfony. The framework may not want to change
but instead the whole programming language is. PHP5 broke a lot of BC
and a lot of code didn''t port well. But now PHP6 is getting closer and
EVERY PHP application will break because they will introduce
namespaces. Yes thats right. Thay are finally putting in
namespaces.... IN RELEASE 6!!!?!?!?
django is now pretty stable NOW but it has not been. And it will
remain stable only until the first major bug is found. Actually the
only framework I really trust to remain stable right now is Catalyst.
Pretty ironic since it''s the youngest of all these. But of course
since it''s written in Perl you better get it right in the first
attempt because in a month you will be unable to understand your own
code. ;)




-- 
--------------
Jon Gretar Borgthorsson
http://www.jongretar.net/

Zed Shaw wrote:
> On Fri, 2006-08-18 at 03:20 +0200, Andreas Schwarz wrote:
>> snacktime wrote:
>> I''m often wondering: what is all this RAM actually used for,
e.g. the
>> 30-40 MB of Mongrel+Rails? Is it object data, is it code, ...? Can 
>> anyone of the Ruby experts (Zed?) give me some insight?
>> 
> 
> Not sure at all as I haven''t looked into it.  For me 40M is a
dream
> compared to the monstrosity systems Java inspires.
Yes. But we shouldn''t only compare Ruby to the worst alternatives.

-- 
Posted via http://www.ruby-forum.com/.

On 8/18/06, Zed Shaw <zedshaw@zedshaw.com> wrote:
>
> What you *must* focus on--especially if your performance problem is
> based on user perception--is how to make your application *seem* faster
> to the users.  This involves less mucking with code and more observation
> and measurement of what users think.  People are visually pretty dumb,
> so you''d be amazed at what little stupid tricks you can do to
simply
> make them believe your stuff is quick.
>
I''m just starting out with Rails and this comment  piqued my interest.
Could you please offer some examples?

-- 
Alex Polite