I’m in the position of being given the job to design and build a
mission-critical web facing application for a small but growing
enterprise. It is to be used by customers as needed, numbering in
the tens up to the hundreds. It will collect operational data,
particularly in a table around 50 columns wide, and potentially
millions of rows deep, most fields being numerical.
The customers will be reporting on this, and the system will be
looking for exceptional values.
I am a reasonably experienced developer with over 10 years
experience, including C, C# and Access. The Access project was
really too big for Access, and included lots of VBA. I know HTML
and XML, though not much of other web technologies.
So technically, I’m reasonably competent, though not so much in
web sites or multi-tier databases. For the foreseeable future,
I am the sole developer on this project.
I’ve been following Ruby and Rails for 6 months or so, and excited
that I (almost) have the opportunity to work with it. My boss at
first approved that I do it in Rails, and also that I use Adobe
Flash/Flex for the front end. Now he is uncertain with typical
concerns regarding enterprise-level use of and commitment to an
unknown platform. He is a competent developer, though now mostly
concerned with the business.
So, I have some questions :
Rails it seems intentionally ignores database optimisation
techniques, such as indexes, stored procedures etc. Beyond the
average web app, and below big enterprise apps, are these things
necessary, or would rails do the job, just perhaps with double the
hardware ?
We are currently a Windows shop. Is it foolish to run a high-level
Rails app on Windows servers today ? We have agreed to use SQL Server -
just to ease the discomfort of going non-MS in other areas, no
technical reason.
If we begin with Rails, does it require anything that would limit
the design for future migration to ASP.NET at a later stage ?
For a compromise solution is it possible/sensible to run C#/ADO.NET
for the core business logic, and Rails for the basic data entry
interfaces
and reporting simultaneously on the same database. This would placate
some of the concerns re enterprise readiness.
Thanks for listening, and many thanks for any responses.
looking for exceptional values.
that I (almost) have the opportunity to work with it. My boss at
average web app, and below big enterprise apps, are these things
necessary, or would rails do the job, just perhaps with double the
hardware ?
Rails it seems intentionally ignores database optimisation
Thats true for any wrapper be it ActiveRecord or Hibernate (ORM), both
in
Hibernate and ActiveRecord you have the option to use find_by_sql in
which
you can execute whatever database specific SQL you want. So in short
Rails
doesn’t use indexing automagically. You can even override the
ActiveRecord
finders to use indexes or stored procedure (though I haven’t used SP in
AR
finders)
We are currently a Windows shop. Is it foolish to run a high-level
Rails app on Windows servers today ? We have agreed to use SQL Server -
just to ease the discomfort of going non-MS in other areas, no
technical reason.
I don’t think its foolish run Rails app on windows until and unless you
come
across some non-portable or bad performing mongrel/lighty library only
for
Windows.
If we begin with Rails, does it require anything that would limit
the design for future migration to ASP.NET at a later stage ?
For a compromise solution is it possible/sensible to run C#/ADO.NET
for the core business logic, and Rails for the basic data entry
interfaces
and reporting simultaneously on the same database. This would placate
some of the concerns re enterprise readiness.
You can reference .NET assemblies by assembly name or by filename if you
use
RubyCLR. But I would recommend trying ActiveRecord before jumping onto ADO.NET Ruby combo
Thanks for listening, and many thanks for any responses.
You can even override the
ActiveRecord finders to use indexes or stored procedure (though I haven’t
used SP in AR finders)
Thats encouraging.
We are currently a Windows shop. Is it foolish to run a high-level
Rails app on Windows servers today ? We have agreed to use SQL Server -
just to ease the discomfort of going non-MS in other areas, no
technical reason.
I don’t think its foolish run Rails app on windows until and unless you
come across some non-portable or bad performing mongrel/lighty library only
for Windows.
yes, thats my concern. It seems IIS is hardly used with Rails, at least
without customisation that I don’t want to get involved with. The web
servers mentioned are primarily used on Linux, and aren’t necessarily as
solid on Windows. (not speaking from actual knowledge here - please
correct me if I’m wrong)
If we begin with Rails, does it require anything that would limit
the design for future migration to ASP.NET at a later stage ?
I’m not sure what you are saying here. My Q was relating to the database
design. If designed for rails, would the database be sub-optimal to use
with ASP.NET | Open-source web framework for .NET ?
For a compromise solution is it possible/sensible to run C#/ADO.NET
for the core business logic, and Rails for the basic data entry
interfaces
and reporting simultaneously on the same database. This would placate
some of the concerns re enterprise readiness.
You can reference .NET assemblies by assembly name or by filename if you
use RubyCLR. But I would recommend trying ActiveRecord before jumping onto ADO.NET Ruby combo.
I understand I could access business logic in .Net from Ruby, but could
I have the following ?
The Rails side would provide simple data entry and reporting and get us
going now. The .Net side would contain the more complex rules and
processing. The hope is to make the simple things simple on the Ruby
side, and the difficult things possible on the .Net side. Perhaps this
is crazy, would breed duplication of logic, leading to inconsistencies
and bugs. Any thoughts or other scenarios ?
You could do a setup with .Net and Rails. However, I just don’t see
the advantage. I think you would be building a headache.
At our consulting business, we do sometimes do (Access -> Mysql <-
Rails) to allow for client-driven reporting and etc. That makes sense
for easy reporting with low development costs, but doing parts in .Net
specifically for “logic” would be a nightmare.
Do it all in one or in the other. Tell him you can do it in .Net, but
it will take twice as long. Business people just care about the cost
of something. And, rightly so. If I wasn’t confident of that fact it
would be hard to bet our reputation and tell our clients that we can
do it faster and cheaper, then I have no right calling myself a good
consultant. And the fact is, that you can deliver even on your first
application.
We have been directly involved in business migrating for MS products
to cheaper and more efficient open source solutions and they cut
their costs dramatically.
To answer one of your first questions, yes Rails can handle fairly
intense business logic without much sweat. I create “enterprise”
applications in rails on a daily basis and they can easily handle it.
I’d ballpark that one windows server of decent spec with the db and
the app with pretty intense business-logic might be able to handle up
to 80 simultanious users. That’s simultanious which is far different
than total customer usage.
The fact is in these situations that Rails just makes good business
sense. Not only will your developers be more productive and more
happy, but they will be faster and cheaper.
I’ve yet to see conversions not save money. Not once yet.
Deployment on Windows is pretty simple, just not as performant as other
platforms. I’ve posted on this before. There is a deployment book coming
up
that will contain a chapter that I wrote which covers this issue in
great
detail. If you need to talk about this, just drop me a line.
If we begin with Rails, does it require anything that would limit
the design for future migration to ASP.NET at a later stage ?
For a compromise solution is it possible/sensible to run C#/ADO.NET
for the core business logic, and Rails for the basic data entry
interfaces
and reporting simultaneously on the same database. This would placate
some of the concerns re enterprise readiness.
This is a recipe for disaster IMO. For legacy apps sometimes you have
to do stuff like that, but going that direction for a new application
is asking for trouble.
As for running on windows, that’s a choice dictated by the experience
and preferences of the people who will be running things. My own
experience tells me that for most applications, you get the least
headaches by running it in the same environment that the core
developers use, and what the community is biased towards and uses the
most.
Sure… but it all depends on your setup.
For example, I have a 2 ghz dual Xeon Windows machine that handles
requests
at a whopping 11 requests per second using one instance of Mongrel.
Similar
hardware yeilds 50 to 75 requests per second using Ubuntu and Mongrel
(again, single instance).
You need to know what your ceiling is for your applications. How many
requests per second do you need to handle, and what is the current
threshold. If you only need to handle 5 to 8 req/second now, then
running on
Windows with a single Mongrel instance will work great for a long long
time. Don’t forget that page caching and action caching where possible
will
REALLY help you push a Windows deployment much much farther than you
thought
possible.
We put Rails on a brand new 64-bit 2k3 server with dual 3ghz processors
and
got 35 requests per second with a single dispatche.
Here’s what you have to do:
Measure an existing (non-Rails) application using httperf (free linux
program) and get your baseline.
Get the new app installed on Windows using Mongrel in production mode
Run httperf against this one and see how you compare.
Ruby is much slower on Windows for some reason. It’s been discussed
before. I have seen much imporved performance on AMD chips though for
some
reason and I don’t understand that. (My AMD machines have much better
response times… go figure.) Adding more Mongrel instances helps a lot
on
Windows but it’s harder to manage multiple apps because Mongrel_cluster
does
not work on Windows. I also don’t see as big a gain as I do on Linux.
But Linux is the way to go for long term high volume stuff. If you need
to
handle millions of requests per day (10+ req/s) and you’re not seeing it
with Windows, then you have to move your apps.
I’ve got a few in production .They work just fine. See above
regarding
loads.
Pen works on Windows if you can find it. Apache 2.2 with
mod_proxy_balance works wonderful as well. This will be covered in the
book
The method outlined in my articles and in the book will make moving
to
Linux seamless to your organization and your users.
Deployment on Windows is pretty simple, just not as performant as other
platforms. I’ve posted on this before. There is a deployment book coming
up that will contain a chapter that I wrote which covers this issue in
great detail. If you need to talk about this, just drop me a line.
Of course, that goes for anyone else too.
Thanks Brian - I’ve printed out your Mongrel & IIS article for my
collection.
“not as performant” - any idea of numbers ?
Also I’m more concerned about reliability. Are you running production
apps
on Windows ? Is it a realistic thing to do, or just “experimental” at
this
stage ?
Also, what Windows program could I use “in front” of a pack of mongrels
? Will anything in Win2003 Server do this ? If so, will RoR’s page
caching still work optimally ?
If I get to the stage of a working RoRoWindows system, I may be able to
introduce Linux servers, but I’d like to avoid that initially.
I’ve got the go-ahead to use Rails ! He said he wavered between
“against” to only slightly “for”, but is willing to go with my
recommendation.
I’ll be starting this week. It is a distributed app which collects daily
maintenance data and security video from fleets of public transport
vehicles. Maybe I’ll be able to share my experiences one day…
Brian H. wrote:
Sure… but it all depends on your setup.
For example, I have a 2 ghz dual Xeon Windows machine that handles
requests
at a whopping 11 requests per second using one instance of Mongrel.
Similar
hardware yeilds 50 to 75 requests per second using Ubuntu and Mongrel
(again, single instance).
Wow - that is significant. We’ve got similar hardware and can live with
that sort of performance under Windows, but once running we could
convert.
Thanks so much Brian for your advice here. I’ll keep a look out for your
book.
Regards
Magpie
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.