Rails - Sep 2006 - Need info on RoR for big e-commerce project...

Hey there :)

I''m about to start development on a project to build a new online book
store for a small retailer and publisher.

The system, feature-wise, is pretty much Amazon, and the data that''s
backing it is a catalog of more than 2½ million items.

To back the Amazon-like functionality (like "other users bought" etc.)
we''ll be tracking user behavior, offering customized news letters, etc.
etc. etc.

So, the data is immense, and data handling is quite significant, too.
The system will be running on an IIS server with an MS SQL Server.
That''s just how it is, as this is the setup the business is using, and
they''re not interested in migrating.

We actually already decided on TYPO3 as our base system, after a longer
research into different CMS''es, CMF''s and eCommerce systems.

Then, by chance, I stumbled across Ruby on Rails. My brother told me
about it once, how students at his design school were using it to build
applications in no time. Considering the programming skills of
designers at his school, and the way he talked about it, I got the
impression that it was more a toy than a serious development tool, so I
never really considered it for this project.

I then grabbed a book on the subject and read a few pages. I was
intrigued. We spoke about it as a possible last-minute candidate, and
decided that I should give it a few days of scrutiny to determine its
viability for our project. I''m currently playing around with RoR
tutorials, and I''m extremely excited. This thing is so intuitive and
easy, it''s amazing.

But then, I see the performance comparisons at
shootout.alioth.debian.org, and compared to PHP (which would be the
alternative), it''s not exactly impressive. But, on the other hand,
it''s
not like I''m going to be doing much of the stuff that these benchmarks
do, like create mandelbrots etc. Basically, we need to get and put
data, much like any other web site out there. Data processing in
scripts is probably minimal (?), as most of it can be handled by stored
procedures (or whatever it''s called in MSSQL terminology).

But still, I need to know about scalability. Can anyone with sufficient
insight help me out with this? Although this system should mimick
Amazon''s feature list, the userbase is significantly lower. In 2005,
there was an average of 760 visitors per day, so the odds of having
something like 100 hits at the same time are marginal. 2,5+ million
items plus all the candy, yes, but not an extreme amount of users.

So is RoR fast enough?

Someone mentioned problems with MSSQL with a lot of concurrent users
(amateur that I am, I forgot to bookmark it). Now, this guy may just
have made crappy code, his network was congested, his hardware crappy,
I don''t know... But are there any known problems with the MSSQL
"wrapper" in RoR? And how does it handle scaling in general?

So is RoR stable enough?

And how about eCommerce add-ons? A lot of other systems, like TYPO3 and
Drupal have eCommerce-functionality available as add-ons. Does
something like this exist for RoR?

Links to similar big sites, preferably eCommerce but any big site
really, would be great! So that I can show the big guys with the money
that RoR can do this, because subjectively speaking, it makes my belly
tinkle inside, it''s really really that sweet...

Thanks in advance for any help!

Daniel Buus, Denmark :)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hi Daniel, I''ve never taken a Rails system live (I''m still
learning it
myself) but the framework was born out of some real live projects built 
by its creators.

I think I''m right in saying (someone please correct me if I''m
wrong)
that one of these is Basecamp, an online project management tool with 
quite a large user base and a hefty number of queries going on.

The basecamp site is at:
http://www.basecamphq.com/

Someone else on this list may know what kind of transaction volumes 
basecamp is supporting and what kind of hardware is supporting it.

Good luck.

Jonathan.

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I would recommend building a sample app that pulls plenty of data from 
your MSSQL server and benchmarking it. From the tests I''ve done. RoR
can
run very quickly, especially if you implement action and fragment 
caching. I''m running on lighttpd, so I don''t know about
implementing
Rails with IIS (are you sure you can''t convince them to switch web 
servers?), but I''ve never seen any stability problems with a properly 
written app.

As far as ecommerce, you may want to check out Substruct 
<http://dev.subimage.com/projects/substruct>.

Jason

Daniel Smedegaard Buus wrote:
> Hey there :)
>
> I''m about to start development on a project to build a new online
book
> store for a small retailer and publisher.
>
> The system, feature-wise, is pretty much Amazon, and the data
that''s
> backing it is a catalog of more than 2½ million items.
>
> To back the Amazon-like functionality (like "other users bought"
etc.)
> we''ll be tracking user behavior, offering customized news letters,
etc.
> etc. etc.
>
> So, the data is immense, and data handling is quite significant, too.
> The system will be running on an IIS server with an MS SQL Server.
> That''s just how it is, as this is the setup the business is using,
and
> they''re not interested in migrating.
>
> We actually already decided on TYPO3 as our base system, after a longer
> research into different CMS''es, CMF''s and eCommerce
systems.
>
> Then, by chance, I stumbled across Ruby on Rails. My brother told me
> about it once, how students at his design school were using it to build
> applications in no time. Considering the programming skills of
> designers at his school, and the way he talked about it, I got the
> impression that it was more a toy than a serious development tool, so I
> never really considered it for this project.
>
> I then grabbed a book on the subject and read a few pages. I was
> intrigued. We spoke about it as a possible last-minute candidate, and
> decided that I should give it a few days of scrutiny to determine its
> viability for our project. I''m currently playing around with RoR
> tutorials, and I''m extremely excited. This thing is so intuitive
and
> easy, it''s amazing.
>
> But then, I see the performance comparisons at
> shootout.alioth.debian.org, and compared to PHP (which would be the
> alternative), it''s not exactly impressive. But, on the other hand,
it''s
> not like I''m going to be doing much of the stuff that these
benchmarks
> do, like create mandelbrots etc. Basically, we need to get and put
> data, much like any other web site out there. Data processing in
> scripts is probably minimal (?), as most of it can be handled by stored
> procedures (or whatever it''s called in MSSQL terminology).
>
> But still, I need to know about scalability. Can anyone with sufficient
> insight help me out with this? Although this system should mimick
> Amazon''s feature list, the userbase is significantly lower. In
2005,
> there was an average of 760 visitors per day, so the odds of having
> something like 100 hits at the same time are marginal. 2,5+ million
> items plus all the candy, yes, but not an extreme amount of users.
>
> So is RoR fast enough?
>
> Someone mentioned problems with MSSQL with a lot of concurrent users
> (amateur that I am, I forgot to bookmark it). Now, this guy may just
> have made crappy code, his network was congested, his hardware crappy,
> I don''t know... But are there any known problems with the MSSQL
> "wrapper" in RoR? And how does it handle scaling in general?
>
> So is RoR stable enough?
>
> And how about eCommerce add-ons? A lot of other systems, like TYPO3 and
> Drupal have eCommerce-functionality available as add-ons. Does
> something like this exist for RoR?
>
> Links to similar big sites, preferably eCommerce but any big site
> really, would be great! So that I can show the big guys with the money
> that RoR can do this, because subjectively speaking, it makes my belly
> tinkle inside, it''s really really that sweet...
>
> Thanks in advance for any help!
>
> Daniel Buus, Denmark :)
>
>
> >
>
>   

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

A)
> The system, feature-wise, is pretty much Amazon, and the data
that''s
> backing it is a catalog of more than 2½ million items.
> So, the data is immense, and data handling is quite significant, too.
+

B)
> The system will be running on an IIS server with an MS SQL Server.
> That''s just how it is, as this is the setup the business is using,
and
> they''re not interested in migrating.

IMHO, and with real experience with ROR+IIS in few words :

"Happy Russian Roulette!"

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 26/09/06, Daniel Smedegaard Buus
<danielbuus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> But still, I need to know about scalability. Can anyone with sufficient
> insight help me out with this? Although this system should mimick
> Amazon''s feature list, the userbase is significantly lower. In
2005,
> there was an average of 760 visitors per day, so the odds of having
> something like 100 hits at the same time are marginal. 2,5+ million
> items plus all the candy, yes, but not an extreme amount of users.
> So is RoR fast enough?
As most of your heavy lifting (dealing with the 2.5 million items,
creating ''Other users looked at'', etc) will be done on the db,
should
be able to handle the rest of the requirements (fetching, displaying
and putting data) as well as any web app framework.  It''s unlikely to
be the fastest possible solution, but should easily handle your needs.

In addition, rails provides very easy-to-use caching functionality
that can help reduce load on your db.
> Someone mentioned problems with MSSQL with a lot of concurrent users
> (amateur that I am, I forgot to bookmark it). Now, this guy may just
> have made crappy code, his network was congested, his hardware crappy,
> I don''t know... But are there any known problems with the MSSQL
> "wrapper" in RoR? And how does it handle scaling in general?
I maintain the SQL Server adapter, so if you find that link again I''d
be very keen to look at it.  In general we''ve had few issues using SQL
Server for long-running but low-volume internal applications.  I would
recommend you use ODBC and steer clear of the ADO mode though -  the
ADO dbi drivers are not nearly as mature as the ODBC ones.  Using
ODBC, I''ve never encountered any real stability issues.
> So is RoR stable enough?
The one ingredient in your setup I''m unfamiliar with is IIS, so I
can''t really tell you how it will all fit together.  I''d
suggest
setting up a test environment (iis, mongrel cluster, db, app that hits
the database in some trivial way) and hammering it with a testing tool
to see how many requests it can handle.  If you could take difficult
request from your existing app and try and trivially model that, it
should provide you with all the information you''d need.

Tom

PS Information on setting up IIS and mongrel can be found here - I''ve
never done it (we use Apache) but it looks fairly straightforward.

http://www.napcsweb.com/howto/rails/deployment/railsonIISWithMongrel.pdf

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 9/26/06, Daniel Smedegaard Buus
<danielbuus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Hey there :)
>
> I''m about to start development on a project to build a new online
book
> store for a small retailer and publisher.
>
> The system, feature-wise, is pretty much Amazon, and the data
that''s
> backing it is a catalog of more than 2½ million items.
Have a look at http://shopify.com, an e-commerce hosting provider, written in
Rails.

My gut feeling and the herd opinion too is that Rails is perfectly scalable
beyond your needs. As long as you dont burn CPU frivolously, your individual
web servers will never be CPU pegged - you will max out your database
first in a properly architected system.

To get to Amazon levels, no web framework will suit your really, you will have
to write your own architecture from scratch.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On Tue, 26 Sep 2006 09:54:47 -0000
"Daniel Smedegaard Buus"
<danielbuus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
<snip> 
> So, the data is immense, and data handling is quite significant, too.
> The system will be running on an IIS server with an MS SQL Server.
> That''s just how it is, as this is the setup the business is using,
and
> they''re not interested in migrating.
> 
> We actually already decided on TYPO3 as our base system, after a longer
> research into different CMS''es, CMF''s and eCommerce
systems.
> 
Stop right there.  You''ve got an immense amount of data in an existing
backend system and the customer has already constrained you to use IIS and MS
SQL server and you''re already going with TYPO3.

Adding rails to the mix would be an integration nightmare.  It doesn''t
run as well on windows, it doesn''t really like legacy databases, it is
limited behind IIS (but talk to Brian Hogan), and Ruby is just dog slow on
windows.  Throw in nastiness like trying to get IIS to properly bounce between
TYPO3, your app, and whatever legacy stuff they have now and you''re in
for some serious trouble.

If you go with Rails in your case it''ll take you much longer than if
you just went with straight up Microsoft tools.  Sorry to say it, but Rails is
totally the wrong tool for the job.

Take a look at the monorail project for .NET if you really want to be fancy: 
http://www.castleproject.org/index.php/MonoRail

-- 
Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
http://www.zedshaw.com/
http://mongrel.rubyforge.org/
http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 26/09/06, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org>
wrote:
>
> On Tue, 26 Sep 2006 09:54:47 -0000
> "Daniel Smedegaard Buus"
<danielbuus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> <snip>
> > So, the data is immense, and data handling is quite significant, too.
> > The system will be running on an IIS server with an MS SQL Server.
> > That''s just how it is, as this is the setup the business is
using, and
> > they''re not interested in migrating.
> >
> > We actually already decided on TYPO3 as our base system, after a
longer
> > research into different CMS''es, CMF''s and eCommerce
systems.
> >
>
> Stop right there.  You''ve got an immense amount of data in an
existing
> backend system and the customer has already constrained you to use IIS
> and MS SQL server and you''re already going with TYPO3.
I''d read it that he''d decided on TYPO3, then stumbled across
RoR, and
was considering using RoR *instead* of TYPO3.  If the plan is to
integrate the two together (alongside backend systems and what-not),
then everything Zed wrote is correct - don''t do it, just go with the
Microsoft flow.

If (as I''d originally assumed) the question was whether it''s
feasible
to run *just* RoR on an IIS/SQL Server setup (with no other
integration), I''d say it was worth looking into.  We''ve
successfully
integrated legacy SQL Server DBs into windows hosted RoR apps with few
major issues.  On the whole, the process has been very pleasant
(particularly now we have Mongrel - thanks Zed).

Tom

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

It seems to me like the foreign_key_associations plug-in (or  
something like it) should be folded into Active Record.  Then Rails  
could just stipulate (we like to be opinionated) that a foreign key  
constraint must be set to unique if there is a has_one relationship  
through that foreign key that is to be picked up auto-magically,  
otherwise it''s an auto_magic has_many.

This would take care of that point made in Agile_v1: "We have to give  
Active Record a little help when it comes to intertable  
relationships.  This isn''t really Active Record''s fault--it
isn''t
possible to deduce from the schema what kind of intertable  
relationships the developer intended" (p226).

O.k., there are a "few" issues (habtm, :through, etc.) but this seems
clean and on the right track.

My 2 cents for the day.

--Russ

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

I can help with regards to IIS...

Rails will not work with IIS. You need to get something else behind it.
There are ways to hack it, but you will find very quickly that it does not
hold up well, if at all.

The solution is simple. In the upcoming Rails Deployment book, I outline a
few possible solutions where you run a Rails app server behind IIS and use a
combination of a reverse-proxy plugin for IIS along with a custom plugin I
developed.

We use Mongrel for our smaller sites (only one instance) and it runs VERY
well for us. Our larger instances use an old Windows port of Pen which
proxies to several Mongrels. IIS forwards to Pen which forwards to Mongrel.
Static files are still served by Mongrel which isn''t fast but is *fast
enough* for our needs.

Need faster? Throw VMWare on your Windows machine, download one of the free
official Ubuntu 6.06 server images, fire that up, install Rails, mongrel,
etc and then use IIS to forward requests to that.  I want to include a
section on that in the book but I don''t know if we still have time to
cram
that in.

The best solution is to run your apps on a dedicated Linux machine and use
IIS to pass requests to that machine, or even better, use Linux only.

If you have to use SQL Server, that makes things a little more complicated
on the Linux side just because of the connection libraries you need to
install.   Wut we''ve had very few problems with SQL Server that we
can''t get
around, and those have been related to our databases themselves.



On 9/26/06, Zed A. Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org>
wrote:
>
>
>
> Adding rails to the mix would be an integration nightmare.  It
doesn''t run
> as well on windows, it doesn''t really like legacy databases, it is
limited
> behind IIS (but talk to Brian Hogan), and Ruby is just dog slow on windows.
>
> If you go with Rails in your case it''ll take you much longer than
if you
> just went with straight up Microsoft tools.  Sorry to say it, but Rails is
> totally the wrong tool for the job.
>
> Take a look at the monorail project for .NET if you really want to be
> fancy:  http://www.castleproject.org/index.php/MonoRail
>
> --
> Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu
> http://www.zedshaw.com/
> http://mongrel.rubyforge.org/
> http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Daniel Smedegaard Buus wrote:
> The system, feature-wise, is pretty much Amazon, and the data
that''s
> backing it is a catalog of more than 2½ million items.
[SNIP]
> So, the data is immense, and data handling is quite significant, too.
Assuming you''ll be able to push most of the heavy lifting data-wise to
the DBMS, and therefore won''t have to retrieve and process millions of
rows in the application layer, your amount of data shouldn''t be a big
problem.
> The system will be running on an IIS server with an MS SQL Server. 
> That''s just how it is, as this is the setup the business is using,
> and they''re not interested in migrating.
Sucks to be them - and you, for that matter. If Windows as a deployment
platform is an absolutely fixed requirement I doubt Ruby and Rails is
the right tool for the job (I''d also doubt that Amazon could be run on
Windows, but I digress). It''s not impossible, though.

Running Rails on IIS is generally a big no-go. However, as others have
pointed out, running Rails on Mongrel behind IIS might be feasible. You
might be able to do this until you start running into performance issues
and then you can start considering scaling to, say, a Linux based cluster.

SQL Server isn''t going to pose terribly many problems for you.
We''re
currently rewriting our legacy VBScript application in Rails and use SQL
Server as the DBMS and it''s working just fine. We''re
developing and
deploying the application to Linux servers, however.
> In 2005, there was an average of 760 visitors per day, so the odds of
> having something like 100 hits at the same time are marginal. 2,5+
> million items plus all the candy, yes, but not an extreme amount of
> users.
> 
> So is RoR fast enough?
Sure, for those kind of numbers Rails will treat you just fine. Clever
use of caching will cover growth for quite a while.
> Daniel Buus, Denmark :)
If you''re in the Copenhagen area, you should check out
http://copenhagenrb.dk/, subscribe to the mailing list and we can hook
up at the next meetup (in roughly a month, I reckon). We''d love to see
you there :)

-- 
Jakob Skjerning - http://mentalized.net

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Jason Norris wrote:
> I would recommend building a sample app that pulls plenty of data from
> your MSSQL server and benchmarking it. From the tests I''ve done.
RoR can
> run very quickly, especially if you implement action and fragment
> caching. I''m running on lighttpd, so I don''t know about
implementing
> Rails with IIS (are you sure you can''t convince them to switch web
> servers?), but I''ve never seen any stability problems with a
properly
> written app.
>
Good to know. I think the web server is possible to negotiate about,
but the DB is not. I used IIS and ASP once back in 2000 (I still get a
claustrophobic feeling reminiscing about it), and since then I''ve used
nothing but Apache and PHP on Linux or BSD servers. My personal
development and test server is a Debian Sarge installation, and using
it (did anyone say stability?) finally made my constant distro
switching on my laptop settle with the Debian-based Kubuntu distro. Up
untill then I had only used Red Hat-based distros (started with Red Hat
back in ''02, then Mandrake, SuSE, Fedora, etc.), but never really god
that "solid" feeling that Debian strains give you. But that''s
an
entirely different discussion, sorry! :D
> As far as ecommerce, you may want to check out Substruct
> <http://dev.subimage.com/projects/substruct>.
>
I found that earlier, made me happy :) Then I got a personal mail with
lots of goodies, among which an invitation to check out this new
RoR-based eCommerce site: www.gbposters.com. This made me even more
happy :)
> Jason
>  
Thanks, Jason, for your time :)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Mathieu Chappuis wrote:
> A)
> > The system, feature-wise, is pretty much Amazon, and the data
that''s
> > backing it is a catalog of more than 2½ million items.
> > So, the data is immense, and data handling is quite significant, too.
>
> +
>
What does that mean?
> B)
> > The system will be running on an IIS server with an MS SQL Server.
> > That''s just how it is, as this is the setup the business is
using, and
> > they''re not interested in migrating.
>
>
> IMHO, and with real experience with ROR+IIS in few words :
>
> "Happy Russian Roulette!"
This is - in other words - what I''m basically reading out of the posts
here. For my records - to use for argumentation about migrating the web
server if need be - could you elaborate about your experiences?

Thanks :)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Tom Ward wrote:
> On 26/09/06, Daniel Smedegaard Buus
<danielbuus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > But still, I need to know about scalability. Can anyone with
sufficient
> > insight help me out with this? Although this system should mimick
> > Amazon''s feature list, the userbase is significantly lower.
In 2005,
> > there was an average of 760 visitors per day, so the odds of having
> > something like 100 hits at the same time are marginal. 2,5+ million
> > items plus all the candy, yes, but not an extreme amount of users.
>
> > So is RoR fast enough?
>
> As most of your heavy lifting (dealing with the 2.5 million items,
> creating ''Other users looked at'', etc) will be done on
the db, should
> be able to handle the rest of the requirements (fetching, displaying
> and putting data) as well as any web app framework.  It''s unlikely
to
> be the fastest possible solution, but should easily handle your needs.
>
These are exactly my thoughts. If I had no one to answer to, I''d just
go ahead and do this thing in RoR and deal with whatever consequences.
It''s just that creepy feeling that you get when you know that if it
turns out otherwise, with terrible performance to show, every one will
be looking at you because you were the one originally advocating the
system. I basically just need to hear as many people say that
performance is not an issue, so that I''m not basing my advice on my own
gut feeling and conviction, but a lot of independent people''s
experiences and qualified advice.
> In addition, rails provides very easy-to-use caching functionality
> that can help reduce load on your db.
>
I''ve just looked a bit at this, and it looks good! Also, I hear from
another source that it might very well be needed, as performance
differences with and without caching are immense.
> > Someone mentioned problems with MSSQL with a lot of concurrent users
> > (amateur that I am, I forgot to bookmark it). Now, this guy may just
> > have made crappy code, his network was congested, his hardware crappy,
> > I don''t know... But are there any known problems with the
MSSQL
> > "wrapper" in RoR? And how does it handle scaling in general?
>
> I maintain the SQL Server adapter, so if you find that link again
I''d
> be very keen to look at it.  In general we''ve had few issues using
SQL
> Server for long-running but low-volume internal applications.  I would
> recommend you use ODBC and steer clear of the ADO mode though -  the
> ADO dbi drivers are not nearly as mature as the ODBC ones.  Using
> ODBC, I''ve never encountered any real stability issues.
>
Cool, so you''re the guy behind it! :) I''ve used the ADO
version, it
seems. Never used MS SQL before, so I kinda just followed the first
link on Google. Will try to find another one for the ODBC version now
then. Didn''t have any problems with the ADO driver while tutorialling,
though, but that''s not really production-grade behavior anyway ;) But I
should probably switch to ODBC when performance testing then.

I tried looking in my history, and I _think_ this might be the post I
was thinking about:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/211423

But this guy is also using ADO anyway. And I have no way near enough
knowledge about Ruby or this guy''s particular problem to know why his
code fails.
> > So is RoR stable enough?
>
> The one ingredient in your setup I''m unfamiliar with is IIS, so I
> can''t really tell you how it will all fit together.  I''d
suggest
> setting up a test environment (iis, mongrel cluster, db, app that hits
> the database in some trivial way) and hammering it with a testing tool
> to see how many requests it can handle.  If you could take difficult
> request from your existing app and try and trivially model that, it
> should provide you with all the information you''d need.
>
Okay, I gotta know now. Why exactly would one keep IIS instead of just
running the Webrick server? Does it scale badly, or...? Do I get any
kind of extra features by integrating with IIS that I''d otherwise miss
out on?
> Tom
>
> PS Information on setting up IIS and mongrel can be found here -
I''ve
> never done it (we use Apache) but it looks fairly straightforward.
>
> http://www.napcsweb.com/howto/rails/deployment/railsonIISWithMongrel.pdf
I''ll check it out, although I get the feeling I''d be silly to
go with
IIS :D

Thanks for your time and your help!

Daniel


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Richard Conroy wrote:
> On 9/26/06, Daniel Smedegaard Buus
<danielbuus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > Hey there :)
> >
> > I''m about to start development on a project to build a new
online book
> > store for a small retailer and publisher.
> >
> > The system, feature-wise, is pretty much Amazon, and the data
that''s
> > backing it is a catalog of more than 2½ million items.
>
> Have a look at http://shopify.com, an e-commerce hosting provider, written
in
> Rails.
>
Thanks for the link, I just skimmed it, will check it out properly in a
little while. Is it just me, though, or are RoR apps generally more
nicely designed than "regular" web apps?
> My gut feeling and the herd opinion too is that Rails is perfectly scalable
> beyond your needs. As long as you dont burn CPU frivolously, your
individual
> web servers will never be CPU pegged - you will max out your database
> first in a properly architected system.
>
Thanks for saying that. I need as many opinions like this as humanly
possible to put my mind at rest :)
> To get to Amazon levels, no web framework will suit your really, you will
have
> to write your own architecture from scratch.
I''ve heard this before. And I assume that when we talk about
"Amazon
levels" it''s in regards to user load, and not functionality,
right?

Thank you :)

Daniel


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Zed A. Shaw wrote:
> On Tue, 26 Sep 2006 09:54:47 -0000
> "Daniel Smedegaard Buus"
<danielbuus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> >
> <snip>
> > So, the data is immense, and data handling is quite significant, too.
> > The system will be running on an IIS server with an MS SQL Server.
> > That''s just how it is, as this is the setup the business is
using, and
> > they''re not interested in migrating.
> >
> > We actually already decided on TYPO3 as our base system, after a
longer
> > research into different CMS''es, CMF''s and eCommerce
systems.
> >
>
> Stop right there.  You''ve got an immense amount of data in an
existing backend
> system and the customer has already constrained you to use IIS and MS SQL
server
> and you''re already going with TYPO3.
>
> Adding rails to the mix would be an integration nightmare.  It
doesn''t run as well on
> windows, it doesn''t really like legacy databases, it is limited
behind IIS (but talk to
> Brian Hogan), and Ruby is just dog slow on windows.  Throw in nastiness
like trying
> to get IIS to properly bounce between TYPO3, your app, and whatever legacy
stuff
> they have now and you''re in for some serious trouble.
>
Oh, it''s not supposed to interoperate with TYPO3, it''s
supposed to be
used instead of it.

A couple of the other points would be really nice to have some
elaboration on, though, as they could either disqualify RoR as an
option, or have us migrate the entire platform. So, could you possible
elaborate on "It doesn''t run as well on Windows", "It
doesn''t really
like legacy databases", and "Ruby is just dog slow on Windows".
Thank
you :)
> If you go with Rails in your case it''ll take you much longer than
if you just went with
> straight up Microsoft tools.  Sorry to say it, but Rails is totally the
wrong tool for the
> job.
>
> Take a look at the monorail project for .NET if you really want to be
fancy:
> http://www.castleproject.org/index.php/MonoRail
>
I checked it out, but off-hand it''s disqualified for being beta.
There''s no way I could ever sell that to the big guys upstairs. Also,
personally, I''d prefer not to use anything Microsoft, as my experiences
with their languages are not so good, to put it kindly (except for C#
which is really really nice, so if some sweet framework à la RoR
exists in C#, that would be interesting, too).

Thanks for your time, Zed, and I hope you''ll elaborate on the points
above :)

Daniel


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Tom Ward wrote:
> On 26/09/06, Zed A. Shaw
<zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org> wrote:
> >
> > On Tue, 26 Sep 2006 09:54:47 -0000
> > "Daniel Smedegaard Buus"
<danielbuus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > >
> > <snip>
> > > So, the data is immense, and data handling is quite significant,
too.
> > > The system will be running on an IIS server with an MS SQL
Server.
> > > That''s just how it is, as this is the setup the business
is using, and
> > > they''re not interested in migrating.
> > >
> > > We actually already decided on TYPO3 as our base system, after a
longer
> > > research into different CMS''es, CMF''s and
eCommerce systems.
> > >
> >
> > Stop right there.  You''ve got an immense amount of data in an
existing
> > backend system and the customer has already constrained you to use IIS
> > and MS SQL server and you''re already going with TYPO3.
>
> I''d read it that he''d decided on TYPO3, then stumbled
across RoR, and
> was considering using RoR *instead* of TYPO3.  If the plan is to
> integrate the two together (alongside backend systems and what-not),
> then everything Zed wrote is correct - don''t do it, just go with
the
> Microsoft flow.
>
You were quite correct in your understanding :)
> If (as I''d originally assumed) the question was whether
it''s feasible
> to run *just* RoR on an IIS/SQL Server setup (with no other
> integration), I''d say it was worth looking into.  We''ve
successfully
> integrated legacy SQL Server DBs into windows hosted RoR apps with few
> major issues.  On the whole, the process has been very pleasant
> (particularly now we have Mongrel - thanks Zed).
>
Good to hear! Although, it would be fantastic if you would share one or
two of those "few major issues", so that I know what to expect.
> Tom
Thank you, Tom! :)

Daniel


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Brian Hogan wrote:
> I can help with regards to IIS...
>
> Rails will not work with IIS. You need to get something else behind it.
> There are ways to hack it, but you will find very quickly that it does not
> hold up well, if at all.
>
> The solution is simple. In the upcoming Rails Deployment book, I outline a
> few possible solutions where you run a Rails app server behind IIS and use
a
> combination of a reverse-proxy plugin for IIS along with a custom plugin I
> developed.
>
It definitely seems to be a no-brainer that I''ll have to do some
persuasion to ditch IIS if RoR turns out to be the way to go. I don''t
think it''ll be the biggest problem though.

I will have a look at Mongrel, maybe for the test session (really need
to get on that very soon! :)

Cheers,
Daniel


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 27/09/06, Daniel Smedegaard Buus
<danielbuus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I tried looking in my history, and I _think_ this might be the post I
> was thinking about:
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/211423
>
> But this guy is also using ADO anyway. And I have no way near enough
> knowledge about Ruby or this guy''s particular problem to know why
his
> code fails.
He''s opening a second statement against a connection while he already
has one open.  That''s not supported by dbi drivers, and not used
within rails.
> Okay, I gotta know now. Why exactly would one keep IIS instead of just
> running the Webrick server? Does it scale badly, or...? Do I get any
> kind of extra features by integrating with IIS that I''d otherwise
miss
> out on?
Webrick is really just a toy server.  It''s great for development, but
no way near stable/secure enough for production.

In place of Webrick many people use Mongrel, which is extremely easy
to set up and use and excels at serving rails applications (though not
great at static content).  It also comes with excellent documentation,
and a very helpful userbase.  However, Ruby on Rails is not thread
safe, so when running rails, only a single concurrent request can be
handled. This is a rails issue - Mongrel itself can handle concurrent
requests.

To get around this, most deployments run many mongrel processes on
each server, each on a different port.  To distribute requests between
each mongrel instance, some form of load-balancer or proxy is used
(there seem to be loads to choose from, though I don''t know what
exactly what your options are on windows).  One common solution is to
use Apache; it may be possible to use IIS but doesn''t seem exactly
recommended ;)

Tom

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Jakob Skjerning wrote:
> Daniel Smedegaard Buus wrote:
> > The system, feature-wise, is pretty much Amazon, and the data
that''s
> > backing it is a catalog of more than 2½ million items.
> [SNIP]
> > So, the data is immense, and data handling is quite significant, too.
>
> Assuming you''ll be able to push most of the heavy lifting
data-wise to
> the DBMS, and therefore won''t have to retrieve and process
millions of
> rows in the application layer, your amount of data shouldn''t be a
big
> problem.
>
Exactly my opinion and thoughts. Good to hear more collaboration on
that :)
> > The system will be running on an IIS server with an MS SQL Server.
> > That''s just how it is, as this is the setup the business is
using,
> > and they''re not interested in migrating.
>
> Sucks to be them - and you, for that matter. If Windows as a deployment
> platform is an absolutely fixed requirement I doubt Ruby and Rails is
> the right tool for the job (I''d also doubt that Amazon could be
run on
> Windows, but I digress). It''s not impossible, though.
>
Why exactly? (The former opinion about Windows as a deployment
platform) Please elaborate.
> Running Rails on IIS is generally a big no-go. However, as others have
> pointed out, running Rails on Mongrel behind IIS might be feasible. You
> might be able to do this until you start running into performance issues
> and then you can start considering scaling to, say, a Linux based cluster.
>
> SQL Server isn''t going to pose terribly many problems for you.
We''re
> currently rewriting our legacy VBScript application in Rails and use SQL
> Server as the DBMS and it''s working just fine. We''re
developing and
> deploying the application to Linux servers, however.
>
Good to hear. So far, it''s been almost exclusively positive feedback
about the MS SQL integration. Very important! :)
> > In 2005, there was an average of 760 visitors per day, so the odds of
> > having something like 100 hits at the same time are marginal. 2,5+
> > million items plus all the candy, yes, but not an extreme amount of
> > users.
> >
> > So is RoR fast enough?
>
> Sure, for those kind of numbers Rails will treat you just fine. Clever
> use of caching will cover growth for quite a while.
>
I''ll be caching away ;)
> > Daniel Buus, Denmark :)
>
> If you''re in the Copenhagen area, you should check out
> http://copenhagenrb.dk/, subscribe to the mailing list and we can hook
> up at the next meetup (in roughly a month, I reckon). We''d love to
see
> you there :)
>
Sounds great! I signed up earlier today. See you there, I guess :)

Cheers,
Daniel


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 27/09/06, Daniel Smedegaard Buus
<danielbuus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Good to hear! Although, it would be fantastic if you would share one or
> two of those "few major issues", so that I know what to expect.
We had a few problems when starting out ~18 months ago, mainly because
the deployment options were very flaky (Apache + fastcgi), and the sql
server adapter was unloved.  In the time since, the community has put
loads of work into both.  We wouldn''t have the same problems if we
started out now.

Tom

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Tom Ward wrote:
> On 27/09/06, Daniel Smedegaard Buus
<danielbuus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > I tried looking in my history, and I _think_ this might be the post I
> > was thinking about:
> > http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/211423
> >
> > But this guy is also using ADO anyway. And I have no way near enough
> > knowledge about Ruby or this guy''s particular problem to know
why his
> > code fails.
>
> He''s opening a second statement against a connection while he
already
> has one open.  That''s not supported by dbi drivers, and not used
> within rails.
>
Okay, that floors the one post I''ve found with serious problems with
MSSQL integration. Perfect :)
> > Okay, I gotta know now. Why exactly would one keep IIS instead of just
> > running the Webrick server? Does it scale badly, or...? Do I get any
> > kind of extra features by integrating with IIS that I''d
otherwise miss
> > out on?
>
> Webrick is really just a toy server.  It''s great for development,
but
> no way near stable/secure enough for production.
>
> In place of Webrick many people use Mongrel, which is extremely easy
> to set up and use and excels at serving rails applications (though not
> great at static content).  It also comes with excellent documentation,
> and a very helpful userbase.  However, Ruby on Rails is not thread
> safe, so when running rails, only a single concurrent request can be
> handled. This is a rails issue - Mongrel itself can handle concurrent
> requests.
>
> To get around this, most deployments run many mongrel processes on
> each server, each on a different port.  To distribute requests between
> each mongrel instance, some form of load-balancer or proxy is used
> (there seem to be loads to choose from, though I don''t know what
> exactly what your options are on windows).  One common solution is to
> use Apache; it may be possible to use IIS but doesn''t seem exactly
> recommended ;)
>
Okay, wait a minute... This seems like quite an ugly hack? I assume
you''d keep the many instances running to avoid the delay from having to
start an instance for each request? Is there no plan to fix this soon?
If not threaded, then at least Rails should be able to fork itself? Or
am I completely off here...?
It seems that having severel Rails running concurrently would be hard
to administer, use excessive memory, and what if one instance crashes -
would some users then just hang in a queue waiting for it to come back
up while others get in one of the good queues? Okay, I admit, I''m more
confused than anything about this. Does a site like gbposters.com
really run a lot of Rails instances to handle their 5000+ hits per day?
Maybe I should just ask them :)

Cheers,
Daniel
> Tom

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Tom Ward wrote:
> On 27/09/06, Daniel Smedegaard Buus
<danielbuus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > Good to hear! Although, it would be fantastic if you would share one
or
> > two of those "few major issues", so that I know what to
expect.
>
> We had a few problems when starting out ~18 months ago, mainly because
> the deployment options were very flaky (Apache + fastcgi), and the sql
> server adapter was unloved.  In the time since, the community has put
> loads of work into both.  We wouldn''t have the same problems if we
> started out now.
> 
Thank you for that. That''s comforting! :)
> Tom
Cheers,
Daniel


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

>
> Okay, wait a minute... This seems like quite an ugly hack? I assume
> you''d keep the many instances running to avoid the delay from
having to
> start an instance for each request? Is there no plan to fix this soon?
> If not threaded, then at least Rails should be able to fork itself? Or
> am I completely off here...?
> It seems that having severel Rails running concurrently would be hard
> to administer, use excessive memory, and what if one instance crashes -
> would some users then just hang in a queue waiting for it to come back
> up while others get in one of the good queues? Okay, I admit, I''m
more
> confused than anything about this. Does a site like gbposters.com
> really run a lot of Rails instances to handle their 5000+ hits per day?
> Maybe I should just ask them :)
>
Yes, basically.

Are you familiar with CGI?  The web server takes the requests, starts
up an interpreter, and gives back the output _every time_.  With
FastCGI and this mongrel setup, the web server (like IIS, Lighty, or
Apache) takes the request, talks to an already running instance of
mongrel or a Rails app on FastCGI through something like mod_proxy,
and then transmits the output.  It''s much faster and more efficient
because the interpreter doesnt'' have to start every time because
it''s
already running (I think I''m saying that right...I''m tired
right now
so someone please correct me).

--Jeremy

P.S. - I can''t believe no one referred you to this:
http://www.agilewebdevelopment.com/rails-ecommerce

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hello,
> This is - in other words - what I''m basically reading out of the
posts
> here. For my records - to use for argumentation about migrating the web
> server if need be - could you elaborate about your experiences?
Running IIS with ROR with FastCGI mean :

- Adding external util for rewriting request (ISAPIRewrite), luckully
this tools is well writen, but add some complexity in the setup.
- Patching some ROR Classes files with contributions
- Using FASTCGI delivered as a standalone DLL with no support at all
- Enjoy some registry editor
- Tracking bugs in the request process, when sometime urls params are
coming like  controller/action*params="foo" instead of ?, or
strangeness like that.
- And cherry, for handling more that one ROR site, you have to rename
your fcgi files for second site into .fcgi2 and setup IIS and FastCGI
for that.

After that, you still have 500 errors, try, stop, and so, and finally
it would work, but you dont know really what damned checkbox you''ve
activated in the setup screen of IIS. Or that''s because you give the
full control right to some internal account in the policies ?


AFIK, have this kind of setup running mean your Sysadmins are well
formed, such of knowledge you gain when you work daily and decently
with Apache (or else unix http server). So let me know somebody well
knowing Apache who wants use IIS.

Perhaps IIS is a nice httpd server, but it''s definitly not suited for
ROR because of lack of reverse_proxy, poor CGI support, fisherprice
logs, ...

Holly Zed, we have Mongrel, but mongrel is nothing else than another
good HTTP server.

So using an http server behind IIS, assisted also with a balancer and
a contributed plugin for sending static content and an url rewriter...

In such case :

What do IIS exactly ?
Are your sysadmin able to track down performances issues or crash.
If the checkbox in the deep IIS MMC is checked again, will you babel
setup still work ?

In a ROI point of view Put they in some Apache consultant hands for 3 days.

Or also ask here : "Who run a decent public site with Rails and IIS,
even with FastCGI or Mongrel ?"

in FP Brooks, The Mythical Man-Month, Addison-Wesley, Reading, MA, 1975.

as I remember "Let the developers also design the architecture." And
now architecture is also infrastructure..

Ciao''

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

> Okay, wait a minute... This seems like quite an ugly hack? I assume
> you''d keep the many instances running to avoid the delay from
having to
> start an instance for each request? Is there no plan to fix this soon?
> If not threaded, then at least Rails should be able to fork itself? Or
> am I completely off here...?
> It seems that having severel Rails running concurrently would be hard
> to administer,
I''ve found using mongrel_cluster makes administration a breeze.  Also,
as each instance is a fully-fledged http server it''s easy to monitor
their health as well as the health of the entire cluster, all with
standard monitoring tools.
> use excessive memory,
Yup, this is certainly a downside.  Rails/Mongrel isn''t really a
memory hog, but having several instances on a single server is
certaintly an inefficiency.  That said, memory is cheap; my mongrel
instances seem to use around 20mb each, so even on an 80mb vps I can
easily run three.
> and what if one instance crashes -
> would some users then just hang in a queue waiting for it to come back
> up while others get in one of the good queues?
If an cluster instance crashes, the load balancer will stop handing
requests to that instance until it returns, using the other instances
instead.  This should mean that only a single request fails.  If a
threaded application server crashed, all requests would fail until the
server restarts.  So running a cluster of servers (even on a single
machine) can more stable than running just a single one.

There are other advantages to this deployment setup.  It''s easy to add
more machines to the cluster as load increases, or to integrate other
web applications.  Also, each part of the deployment is dedicated to a
single task (Apache to serve static content and balance, Mongrel to
serve dynamic content), and can be tested independently.
> Okay, I admit, I''m more
> confused than anything about this. Does a site like gbposters.com
> really run a lot of Rails instances to handle their 5000+ hits per day?
Almost certainly.
> Maybe I should just ask them :)
Yeah ;)

Tom

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 9/27/06, Daniel Smedegaard Buus
<danielbuus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> Richard Conroy wrote:
> > Have a look at http://shopify.com, an e-commerce hosting provider,
written in
> > Rails.
> >
>
> Thanks for the link, I just skimmed it, will check it out properly in a
> little while. Is it just me, though, or are RoR apps generally more
> nicely designed than "regular" web apps?
I am only touching base with Rails too, but I have managed to
accomplish some significant non-trivial results. Getting sophisticated
(in terms of complexity) views put together in Rails is shockingly
quick and simple, and its done *right*. In my experience, this
was done so quick that I had free time to make significant in-roads
into getting up to speed with CSS. Rails views are correctly
engineered practically from first authoring so they do not need
the levels of rework often seen in other frameworks.

Rails coders have far more free time left over for UI polishing
exercises. Rails also has one of the best AJAX integrations.

As a learning exercise, experimentation is very effective with
Rails, this conditions developers to be more confident about
trying new things, and will use more of the ''pretty'' features.
There is also a significant after-market in Rails plugins.
> > My gut feeling and the herd opinion too is that Rails is perfectly
scalable
> > beyond your needs. As long as you dont burn CPU frivolously, your
individual
> > web servers will never be CPU pegged - you will max out your database
> > first in a properly architected system.
> >
>
> Thanks for saying that. I need as many opinions like this as humanly
> possible to put my mind at rest :)
But as a caveat, it doesn''t offer all of this ''for
free'' to scalability
novices. No more so than any other solution. You have to be familiar
with what is involved in achieving a scaling solution. But to be honest,
as a scalability novice myself, I would have more confidence engineering
a scalable rails solution than that of a different framework. Rails uses
a very simple, proven stack. .NET, EJB etc. seem to interfere with/
overcomplicate this too much making them much less simple to
architect into super-scaling solutions.
> > To get to Amazon levels, no web framework will suit your really, you
will have
> > to write your own architecture from scratch.
>
> I''ve heard this before. And I assume that when we talk about
"Amazon
> levels" it''s in regards to user load, and not functionality,
right?
Correct. Any high-scaling solution implicitly has diminished user
functionality. There will be very little server-side CPU-intensive stuff
done on the behalf of the user, a user request will not be initiating
secondary/tertiary connections, and most of the work is involved
in taking database contents for a specific view and passing them
onto the user.

Big Websites actually have extra-ordinarily simple design architecture.
This simplicity is what allows them to scale. Its only when you
start introducing the scaling architecture that it starts to get wierd.
Even then the reasons for the scaling architecture are pretty
obvious.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Daniel:

One instance of mongrel can handle, on its own, anywhere from 5 requests per
second up to 100 requests per second depending on the OS. Windows will be
the low end, Linux will be the high end

5 requests per second = around 50,000 requests in 24 hours. You need
additional mongrel instances for your app if you start noticing performance
problems. That''s "load balancing" and is common in web
application
deployment.  PHP uses FastCGI for this, and Rails can do that too....

but separate Mongrel instances using the same application means that you can
actually deploy across physical servers as well to distribute the load even
more.

I once heard that Alistapart.com uses only 4 dispatchers. They receive lots
of traffic and I am sure they make good use of page and action caching.

One caution: This is Rails... new territory which has been discovered by
people who have been burned by previous experiences in other languages /
platforms.  Things may not appear to make sense at first until you use it.
If you look back at my posts from a year ago, you''ll see me asking
similar
questions :)




>
> Okay, wait a minute... This seems like quite an ugly hack? I assume
> you''d keep the many instances running to avoid the delay from
having to
> start an instance for each request? Is there no plan to fix this soon?
> If not threaded, then at least Rails should be able to fork itself? Or
> am I completely off here...?
> It seems that having severel Rails running concurrently would be hard
> to administer, use excessive memory, and what if one instance crashes -
> would some users then just hang in a queue waiting for it to come back
> up while others get in one of the good queues? Okay, I admit, I''m
more
> confused than anything about this. Does a site like gbposters.com
> really run a lot of Rails instances to handle their 5000+ hits per day?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Richard Conroy wrote:
> On 9/27/06, Daniel Smedegaard Buus
<danielbuus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Thanks for the link, I just skimmed it, will check it out properly in
a
> > little while. Is it just me, though, or are RoR apps generally more
> > nicely designed than "regular" web apps?
>
> I am only touching base with Rails too, but I have managed to
> accomplish some significant non-trivial results. Getting sophisticated
> (in terms of complexity) views put together in Rails is shockingly
> quick and simple, and its done *right*. In my experience, this
> was done so quick that I had free time to make significant in-roads
> into getting up to speed with CSS. Rails views are correctly
> engineered practically from first authoring so they do not need
> the levels of rework often seen in other frameworks.
>
> Rails coders have far more free time left over for UI polishing
> exercises. Rails also has one of the best AJAX integrations.
This is probably true, but I think it has more to do with Rails
attracting a more contemporary breed of programmer, like myself:
somebody who came from more of an interaction/graphic design background
and shifted over onto the server side and other more ''serious''
programming concerns. People from these backgrounds tend not to have
learned staticly typed, compiled languages, so a powerful, intuitive
framework like Rails based on a beautiful, dynamic language like Ruby
is a natural fit. I think there is also something about the design of
Ruby in general that is more agreeable to the more creative types. See
why the lucky stiff as a shining example of the community in this
regard, though he is certainly not alone.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Okay, guys, this is gonna be a collective one with status for this
thing.

I''ve been kindly asked to leave research be until the control group has
reviewed the current document (which concludes that we should use TYPO3
with a note that RoR entered late in the process and may turn out to
beat TYPO3 as the system of choice), and either said that there''s no
way we can go with RoR, or that there''s still a possibility.

This means that I''ll now be reassigned to work on requirements, data
modelling, etc.

I just touched setting up Mongrel + IIS + ISAPIRewrite, and I read
about problems with zombie processes using FastCGI on Apache, and all
in all, Windows seems like such a crappy platform to do this on.

Good news is yes, we need to talk to an MS SQL Server, but it''s been
decided that this server will run on a dedicated machine, and thus
there''s a slight possibility that I can get permission to move the
currently running websites from the current IIS web server to a spare
machine, wipe Windows from the web server, install Debian, and set up
an Apache/Lighty/whatever/RoR combo to serve this thing. The machine is
a dual-core 3.2 GHz Xeon with 2GB mem and mirrored SCSI, and it''ll be
running ONLY this site. EXCLUSIVE database, which has its own machine.
I think it''d be safe to say that Ruby on Rails is now adequate beyond
any doubt to serve the maximum of maybe 100.000 page views on the
busiest day of the year. In my mind, there''s no way RoR should
represent any kind of bottleneck in this respect. It''ll be the MSSQL
machine, if any at all.

Okay, so while I''ve been told for the time being to use my day hours
here at work on forementioned work (and probably getting to know TYPO3
as well), I have received green light to use evenings to set up a Linux
environment on my personal laptop to do some testing with RoR, page
serving, clustering, whatever. If my tests are positive, then I can
probably sell this whole thing.

In this respect, if anyone can provide best-practices approaches
setting up the most stable, and preferably very scalable, Linux + RoR
combo, that would be wonderful.

Also, I''ve already received very convincing figures on the load
handling capabilities of gbposters.com, but if you know of other
figures that tell tales of RoR being a capable
"serve-many-serve-quickly" contender, I would love to see them.
Benchmarks comparing RoR to anything else in a web context (i.e. not
the "which language is quicker to render mandelbrots" type of deal)
would be useful. Basically anything you can use to sell the RoR
solution to the fat cats that make all the decisions.

For now, thank you so much for all your help with my many questions. I
hope this is not the end of my adventures with RoR. Well, I know it
won''t be cause I already have it planned for a different project (of my
own), I just hope that the next many months of developing this
particular website will be done in RoR :)

Thanks again,
Daniel Buus


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

2006/9/28, Daniel Smedegaard Buus
<danielbuus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>
> In this respect, if anyone can provide best-practices approaches
> setting up the most stable, and preferably very scalable, Linux + RoR
> combo, that would be wonderful.

there is a series of blog entries by the developers of  eins.de, a german
community site server around 1M page views a day:
http://poocs.net/2006/03/13/the-adventures-of-scaling-stage-1

and, as a base of that, in order to set up an apache
2.2/mongrel/rails/capistrano
stack on linux, i find this blog article very useful:
http://blog.codahale.com/2006/06/19/time-for-a-grown-up-server-rails-mongrel-apache-capistrano-and-you/

again for the point of setting up such a stack: it sounds harder than it is.
with some time to start and willing to read a few docs, such a wonderful
stack can be set up in no time. and if you''ve done it one, the next
times
(deploying the app on another server, or deploying another new project) will
be even faster. it then just works.

Also, I''ve already received very convincing figures on the
load
> handling capabilities of gbposters.com, but if you know of other
> figures that tell tales of RoR being a capable
> "serve-many-serve-quickly" contender, I would love to see them.
> Benchmarks comparing RoR to anything else in a web context (i.e. not
> the "which language is quicker to render mandelbrots" type of
deal)
> would be useful. Basically anything you can use to sell the RoR
> solution to the fat cats that make all the decisions.

IMHO, ruby/rails may be not the fastest of all language/framework
combinations, but as always said: hardware''s cheap, developers are not.
so
buying one ore two more servers will be less expensive as hiring one ore two
more developers.and, what i consider the killer-argument: rails is fun,
rails makes (at least me) happy. and a happy programmer is a more productive
programmer. (at least thats right for me!)

good luck, rock''em :)


-- 
Michael Siebert <info-norLuBQQNv0t+8dGM1inlw@public.gmane.org>

www.siebert-wd.de - Gedanken lesen
www.stellar-legends.de - Weltraum-Browsergame im Alpha-Stadium


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 9/28/06, Daniel Smedegaard Buus
<danielbuus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Okay, guys, this is gonna be a collective one with status for this
> thing.
<snip>
> The machine is
> a dual-core 3.2 GHz Xeon with 2GB mem and mirrored SCSI, and it''ll
be
> running ONLY this site. EXCLUSIVE database, which has its own machine.
> I think it''d be safe to say that Ruby on Rails is now adequate
beyond
> any doubt to serve the maximum of maybe 100.000 page views on the
> busiest day of the year. In my mind, there''s no way RoR should
> represent any kind of bottleneck in this respect. It''ll be the
MSSQL
> machine, if any at all.
Hang on a bit here. There isn''t really a lot of hard facts on the
capability
of a properly engineered single-machine Rails install. Rails is designed
for scalability and that is achieved through the best practice of adding
more machines. It is more likely that the single Rails machine will be
the bottleneck than the SQL server (because Rails is designed to have
multiple Rails machines using a single database).

For single machine instances what you are looking for is *performance*
not scalability. Rails may still be enough for your needs, even without
heavy tweaking, and especially on *NIX boxes, but be under no illusions.

> Okay, so while I''ve been told for the time being to use my day
hours
> here at work on forementioned work (and probably getting to know TYPO3
> as well), I have received green light to use evenings to set up a Linux
> environment on my personal laptop to do some testing with RoR, page
> serving, clustering, whatever. If my tests are positive, then I can
> probably sell this whole thing.
Your company gave you the green light to do the work for free? :/

With Rails the only way to prove it properly is to build the app that
was requested and have it ready by the end of the reqs gathering
stage. Don''t research, just build the app. Come back to your superiours
with a working app, instead of pro/con analysis.
> Benchmarks comparing RoR to anything else in a web context (i.e. not
> the "which language is quicker to render mandelbrots" type of
deal)
> would be useful. Basically anything you can use to sell the RoR
> solution to the fat cats that make all the decisions.
The nice thing about Rails is how elegant it scales to best practices
solutions. You start small with a couple of Rails boxes and a database.
When your Rails boxes feel the heat, just add more. When your DB
starts to feel the heat, add another one and partition your custom.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Okay everybody, here''s the final status for this project.

The bad news for me is that the control group down-thumbed Rails,
argumenting a too short history, too much risk, and too big a change to
migrate the server to Linux. We''re continuing with TYPO3, which I
really hope will turn out to be adequate and fast to develop with. The
learning curve is a bit scary, but at least I know what I''ll be doing
the next few weeks :)

Thanks to every one who helped me. And even if this project will go
with an old-school CMF strategy, I''m still hanging in - I joined the
Copenhagen Ruby Brigade, and we''re gathering on october 21st it seems.
I''ll find a place for Rails yet.

Cheers everyone,
Daniel



Cheers,
Daniel


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---