I imagine they might be using interfaces such as PerfServlet
(http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/tprf_devprfservlet.html)
to monitor the internals of running apps.
I''m using that at the moment to try to finetune a fairly large Java
app. My feeling is that such a solution would simply be overkill for
Rails apps - we''re talking 100k+ lines of code in the Java app, and
I''ve never seen or heard of a Rails app that''s even 10% of
that size.
Additionally, J2EE apps have a habit of producing difficult to isolate
performance issues, whereas I''ve generally found it quite simple to
isolate Rails app bottlenecks down to a method call pretty quickly.
While I''ve only ever tried to tune my own Rails apps (vs. tuning many
large-scale J2EE apps), I really can''t see that such tools would be
required for Rails.
Rails'' scalability is based largely on scaling horizontally simply and
easily, and it works because of the underlying simply architecture,
and infrastructure components such as Mongrel which are simple to use
and give just the right amount of flexibility to get the job done well
without trying to be infinitely tunable. Rather than trying to
squeeze the last 2% of performance out of your Rails app, you''re
generally better off either moving to slightly bigger hardware or
splitting your app so that it has dedicated DB/Web/app layers on
separate systems - it''s that simple.
I use Postgres as a DB layer for both Rails and non-Rails apps fairly
often, and in my experience there''s FAR more to gain by tuning
Postgres than anything else. Same with Oracle, DB2 etc. - often the
bottlenecks lie in the DB itself, or how the app is using the DB.
J2EE/WebSphere apps tend to need lots of tuning to get the
infrastructure working well for each individual app, and I''m not at
all sure that WebSphere''s infinitely deep/complex tuning possibilities
are a net help or hindrance in this respect. It''s often difficult to
split a J2EE app out onto multiple systems, and the incremental
licencing cost of components such as WebSphere also tends to cloud the
equation.
All that said, I''ve been pondering the pros and cons of developing
Rails apps under (virtual) Solaris hosts, which would let me use
dtrace to dig inside the app and see how it''s working under load. My
thinking is that, once I''ve gotten it working quickly and efficiently
under Solaris, I could then move the app across to Linux and have it
work at a near optimum level straight away. dtrace strikes me as an
appropriate level of monitoring/management capability for Rails apps,
but something like PerfServlet would be overkill.
Hope that helps
Regards
Dave M.
On 08/08/06, Mat Schaffer <schapht@gmail.com>
wrote:>
> On Aug 7, 2006, at 6:11 PM, subimage interactive wrote:
>
> > Mat,
> >
> > Try to find out what those sysadmin tools can actually do and I bet
> > you''ll get better responses.
> >
> > Off top, I can''t think of anything Rails-specific to monitor
your
> > app. The majority of J2EE houses that I''ve worked in as a
> > consultant have written their own custom monitoring apps to manage
> > different things. Are they perhaps talking about custom solutions
> > they''ve written?
>
> It sounded like packaged stuff. But I''ll investigate more and see
if
> people know of analogues to what they''re using.
> Thanks,
> Mat
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>