From chris at codeintensity.com  Sat Sep  1 00:54:53 2007
From: chris at codeintensity.com (Christopher Bailey)
Date: Fri, 31 Aug 2007 21:54:53 -0700
Subject: [Mongrel] Possible memory leak problem...
In-Reply-To: <86987bdf0708192050r282351bu7256e44cbba28b7@mail.gmail.com>
References: <61B5B973-C9E5-48AC-AD8F-E748FD22F4CA@zero.it>
	<C2DB09C9-5852-46B2-91FD-17F75758B2D7@gmail.com>
	<86987bdf0708192050r282351bu7256e44cbba28b7@mail.gmail.com>
Message-ID: <8c8513100708312154l16071187te3e8e75270ef063@mail.gmail.com>

We are finding that anytime our application sends back large files to the
requestor, we start chewing up memory fast.  We haven't determined the
precise cause or how to solve it yet, but it sounds like the same kind of
situation.  In our case, the particular large files are usually not
generated by Builder, but typically are actually files being
downloaded/transferred (e.g. images, documents, etc.).

On 8/19/07, Chris Carter <cdcarter at gmail.com> wrote:
>
> On 8/19/07, Wayne E. Seguin <wayneeseguin at gmail.com> wrote:
> >
> > Massimo,
> >
> > You should post this to ruby-talk mailing list. Make sure to include the
> > version of ruby, the version  rails, as well as any plugins and/or gems
> your
> > app uses. If at all possible try to include some code for analysis as
> many
> > people on that list will jump right on that to tell you what might be
> > causing it and a better way to go about it (if one exists).
> >
> > Best,
> >
> >   ~Wayne
>
> I think rails-talk would be even more appropriate.
>
>
> --
> Chris Carter
> concentrationstudios.com
> brynmawrcs.com
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070831/82795dc0/attachment-0001.html 

From zedshaw at zedshaw.com  Sat Sep  1 01:40:29 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Sat, 1 Sep 2007 01:40:29 -0400
Subject: [Mongrel] Possible memory leak problem...
In-Reply-To: <8c8513100708312154l16071187te3e8e75270ef063@mail.gmail.com>
References: <61B5B973-C9E5-48AC-AD8F-E748FD22F4CA@zero.it>
	<C2DB09C9-5852-46B2-91FD-17F75758B2D7@gmail.com>
	<86987bdf0708192050r282351bu7256e44cbba28b7@mail.gmail.com>
	<8c8513100708312154l16071187te3e8e75270ef063@mail.gmail.com>
Message-ID: <20070901014029.837dba7d.zedshaw@zedshaw.com>

On Fri, 31 Aug 2007 21:54:53 -0700
"Christopher Bailey" <chris at codeintensity.com> wrote:

> We are finding that anytime our application sends back large files to the
> requestor, we start chewing up memory fast.  We haven't determined the
> precise cause or how to solve it yet, but it sounds like the same kind of
> situation.  In our case, the particular large files are usually not
> generated by Builder, but typically are actually files being
> downloaded/transferred (e.g. images, documents, etc.).

This is because Mongrel collects your large file response into a StringIO so that it can keep rails happy.  After the StringIO is done and rails leaves the locked section of code it then shoves that out the door on the socket.

You are expecting to write a file, in rails, using Ruby's crappy IO, and that it would go immediately on the socket.  That's probably why you're seeing this.

In reality, if it's a large file, and you know where it is, then you should let a real web server handle it, or at a minimum write a Mongrel Handler to do the real heavy lifting.

There's plenty of information on doing this, but seriously, do not ever use send_file in rails or similar.  It's just a waste of resources, and even if you need to authenticate you can use X-Sendfile in apache or nginx and that'll let you auth someone then send the file.

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

From jgeiger at gmail.com  Sat Sep  1 08:41:32 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Sat, 1 Sep 2007 08:41:32 -0400
Subject: [Mongrel] Possible memory leak problem...
In-Reply-To: <20070901014029.837dba7d.zedshaw@zedshaw.com>
References: <61B5B973-C9E5-48AC-AD8F-E748FD22F4CA@zero.it>
	<C2DB09C9-5852-46B2-91FD-17F75758B2D7@gmail.com>
	<86987bdf0708192050r282351bu7256e44cbba28b7@mail.gmail.com>
	<8c8513100708312154l16071187te3e8e75270ef063@mail.gmail.com>
	<20070901014029.837dba7d.zedshaw@zedshaw.com>
Message-ID: <466af3440709010541n1100051elb4ee8b6271d6227@mail.gmail.com>

Now, I'm opening a different can of worms, but how do you suggest
sending an image file from the database without using send_data, or
does send_data not suffer from the same issues as send_file?

I tried using X-Sendfile and ran into issues that files weren't being
pulled out of the DB correctly. (Probably should be able to fix this
now, after I figured it out)

On 9/1/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
> On Fri, 31 Aug 2007 21:54:53 -0700
> "Christopher Bailey" <chris at codeintensity.com> wrote:
>
> > We are finding that anytime our application sends back large files to the
> > requestor, we start chewing up memory fast.  We haven't determined the
> > precise cause or how to solve it yet, but it sounds like the same kind of
> > situation.  In our case, the particular large files are usually not
> > generated by Builder, but typically are actually files being
> > downloaded/transferred (e.g. images, documents, etc.).
>
> This is because Mongrel collects your large file response into a StringIO so that it can keep rails happy.  After the StringIO is done and rails leaves the locked section of code it then shoves that out the door on the socket.
>
> You are expecting to write a file, in rails, using Ruby's crappy IO, and that it would go immediately on the socket.  That's probably why you're seeing this.
>
> In reality, if it's a large file, and you know where it is, then you should let a real web server handle it, or at a minimum write a Mongrel Handler to do the real heavy lifting.
>
> There's plenty of information on doing this, but seriously, do not ever use send_file in rails or similar.  It's just a waste of resources, and even if you need to authenticate you can use X-Sendfile in apache or nginx and that'll let you auth someone then send the file.
>
> --
> Zed A. Shaw
> - Hate: http://savingtheinternetwithhate.com/
> - Good: http://www.zedshaw.com/
> - Evil: http://yearofevil.com/
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From ezmobius at gmail.com  Sat Sep  1 11:55:31 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Sat, 1 Sep 2007 08:55:31 -0700
Subject: [Mongrel] Possible memory leak problem...
In-Reply-To: <466af3440709010541n1100051elb4ee8b6271d6227@mail.gmail.com>
References: <61B5B973-C9E5-48AC-AD8F-E748FD22F4CA@zero.it>
	<C2DB09C9-5852-46B2-91FD-17F75758B2D7@gmail.com>
	<86987bdf0708192050r282351bu7256e44cbba28b7@mail.gmail.com>
	<8c8513100708312154l16071187te3e8e75270ef063@mail.gmail.com>
	<20070901014029.837dba7d.zedshaw@zedshaw.com>
	<466af3440709010541n1100051elb4ee8b6271d6227@mail.gmail.com>
Message-ID: <0F2D93B1-BACD-440C-BEA7-D95F2D08B434@brainspl.at>


On Sep 1, 2007, at 5:41 AM, Joey Geiger wrote:

> Now, I'm opening a different can of worms, but how do you suggest
> sending an image file from the database without using send_data, or
> does send_data not suffer from the same issues as send_file?
>
> I tried using X-Sendfile and ran into issues that files weren't being
> pulled out of the DB correctly. (Probably should be able to fix this
> now, after I figured it out)


	You should never store files in the database in the first place.  
send_data has the same leaky problem as send_file. The filesystem is  
a database for files already and is much more efficient at storing  
files then using the database for it.

Cheers-
-- Ezra Zygmuntowicz 
-- Founder & Ruby Hacker
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)



From will at hotgazpacho.com  Sat Sep  1 13:46:18 2007
From: will at hotgazpacho.com (Will Green)
Date: Sat, 01 Sep 2007 13:46:18 -0400
Subject: [Mongrel] Possible memory leak problem...
In-Reply-To: <0F2D93B1-BACD-440C-BEA7-D95F2D08B434@brainspl.at>
References: <61B5B973-C9E5-48AC-AD8F-E748FD22F4CA@zero.it>	<C2DB09C9-5852-46B2-91FD-17F75758B2D7@gmail.com>	<86987bdf0708192050r282351bu7256e44cbba28b7@mail.gmail.com>	<8c8513100708312154l16071187te3e8e75270ef063@mail.gmail.com>	<20070901014029.837dba7d.zedshaw@zedshaw.com>	<466af3440709010541n1100051elb4ee8b6271d6227@mail.gmail.com>
	<0F2D93B1-BACD-440C-BEA7-D95F2D08B434@brainspl.at>
Message-ID: <46D9A56A.1010408@hotgazpacho.com>

Not necessarily so, Ezra. Storing images in the database is perfectly 
legitimate.  However, just like Rails HTML views, you could implement 
caching of the images on the filesystem (i.e. write them to both the FS 
and the DB). Whatever action "renders" the image could take care of 
caching on the FS, serving the FS version if the DB version has, for 
example, the same MD5 hash as the one in the DB.

Yes, performance will be a bit less than pure FS, but backups are a 
whole lot simpler (just backup and restore the DB). Besides, servers are 
cheap compared to developers (just ask the 37s guys), right?

==
Will Green

Find out why this email is 5 sentences or less at http://five.sentec.es/

From _ at whats-your.name  Sat Sep  1 17:46:30 2007
From: _ at whats-your.name (cr)
Date: Sat, 1 Sep 2007 17:46:30 -0400
Subject: [Mongrel] Possible memory leak problem...
In-Reply-To: <46D9A56A.1010408@hotgazpacho.com>
References: <61B5B973-C9E5-48AC-AD8F-E748FD22F4CA@zero.it>
	<C2DB09C9-5852-46B2-91FD-17F75758B2D7@gmail.com>
	<86987bdf0708192050r282351bu7256e44cbba28b7@mail.gmail.com>
	<8c8513100708312154l16071187te3e8e75270ef063@mail.gmail.com>
	<20070901014029.837dba7d.zedshaw@zedshaw.com>
	<466af3440709010541n1100051elb4ee8b6271d6227@mail.gmail.com>
	<0F2D93B1-BACD-440C-BEA7-D95F2D08B434@brainspl.at>
	<46D9A56A.1010408@hotgazpacho.com>
Message-ID: <20070901214630.GA2748@replic.net>

> Not necessarily so, Ezra. Storing images in the database is perfectly 
> legitimate.  However, just like Rails HTML views, you could implement 
> caching of the images on the filesystem (i.e. write them to both the FS 
> and the DB). Whatever action "renders" the image could take care of 
> caching on the FS, serving the FS version if the DB version has, for 
> example, the same MD5 hash as the one in the DB.

and why do all that then put them on the fs when you can just put them on the FS in the first place?

> 
> Yes, performance will be a bit less than pure FS, but backups are a 
> whole lot simpler (just backup and restore the DB).

rsync and tar are very simple

> Besides, servers are 
> cheap compared to developers

you get a significant productivity boost out of putting binary files into the database? really?

From zedshaw at zedshaw.com  Sat Sep  1 17:51:09 2007
From: zedshaw at zedshaw.com (Zed A. Shaw)
Date: Sat, 1 Sep 2007 17:51:09 -0400
Subject: [Mongrel] Possible memory leak problem...
In-Reply-To: <46D9A56A.1010408@hotgazpacho.com>
References: <61B5B973-C9E5-48AC-AD8F-E748FD22F4CA@zero.it>
	<C2DB09C9-5852-46B2-91FD-17F75758B2D7@gmail.com>
	<86987bdf0708192050r282351bu7256e44cbba28b7@mail.gmail.com>
	<8c8513100708312154l16071187te3e8e75270ef063@mail.gmail.com>
	<20070901014029.837dba7d.zedshaw@zedshaw.com>
	<466af3440709010541n1100051elb4ee8b6271d6227@mail.gmail.com>
	<0F2D93B1-BACD-440C-BEA7-D95F2D08B434@brainspl.at>
	<46D9A56A.1010408@hotgazpacho.com>
Message-ID: <20070901175109.7983daa0.zedshaw@zedshaw.com>

On Sat, 01 Sep 2007 13:46:18 -0400
Will Green <will at hotgazpacho.com> wrote:

> Not necessarily so, Ezra. Storing images in the database is perfectly 
> legitimate.  However, just like Rails HTML views, you could implement 
> caching of the images on the filesystem (i.e. write them to both the FS 
> and the DB). Whatever action "renders" the image could take care of 
> caching on the FS, serving the FS version if the DB version has, for 
> example, the same MD5 hash as the one in the DB.

No, not right at all.  All RDBMS were originally designed to store relations, not files.  It's only recently that people started putting every damn thing they could into a RDBMS.  The smart folks just put the data on a file system behind a specialized image web server.  Then, when you need to serve the image, you, uh serve it.  Doesn't get much easier than that.

> Yes, performance will be a bit less than pure FS, but backups are a 
> whole lot simpler (just backup and restore the DB). Besides, servers are 
> cheap compared to developers (just ask the 37s guys), right?

That's it?  Backups?  Seriously man, that's a lame reason to do anything.  Especially since backing up a file system is *infinitely* easier than a database.  In real companies around the world there are little children crying because every night the DBA has to shut the production databases down to back them up, even if Oracle says they don't.

Backing up a file system does not require shutting it down, and can even be done with just simple rsync scripts.

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

From will at hotgazpacho.com  Sat Sep  1 19:17:04 2007
From: will at hotgazpacho.com (Will Green)
Date: Sat, 01 Sep 2007 19:17:04 -0400
Subject: [Mongrel] Possible memory leak problem...
In-Reply-To: <20070901175109.7983daa0.zedshaw@zedshaw.com>
References: <61B5B973-C9E5-48AC-AD8F-E748FD22F4CA@zero.it>	<C2DB09C9-5852-46B2-91FD-17F75758B2D7@gmail.com>	<86987bdf0708192050r282351bu7256e44cbba28b7@mail.gmail.com>	<8c8513100708312154l16071187te3e8e75270ef063@mail.gmail.com>	<20070901014029.837dba7d.zedshaw@zedshaw.com>	<466af3440709010541n1100051elb4ee8b6271d6227@mail.gmail.com>	<0F2D93B1-BACD-440C-BEA7-D95F2D08B434@brainspl.at>	<46D9A56A.1010408@hotgazpacho.com>
	<20070901175109.7983daa0.zedshaw@zedshaw.com>
Message-ID: <46D9F2F0.2070007@hotgazpacho.com>

Please, by all means, feel free to make this argument to my boss...


Zed A. Shaw wrote:
> On Sat, 01 Sep 2007 13:46:18 -0400
> Will Green <will at hotgazpacho.com> wrote:
> 
>> Not necessarily so, Ezra. Storing images in the database is perfectly 
>> legitimate.  However, just like Rails HTML views, you could implement 
>> caching of the images on the filesystem (i.e. write them to both the FS 
>> and the DB). Whatever action "renders" the image could take care of 
>> caching on the FS, serving the FS version if the DB version has, for 
>> example, the same MD5 hash as the one in the DB.
> 
> No, not right at all.  All RDBMS were originally designed to store relations, not files.  It's only recently that people started putting every damn thing they could into a RDBMS.  The smart folks just put the data on a file system behind a specialized image web server.  Then, when you need to serve the image, you, uh serve it.  Doesn't get much easier than that.
> 
>> Yes, performance will be a bit less than pure FS, but backups are a 
>> whole lot simpler (just backup and restore the DB). Besides, servers are 
>> cheap compared to developers (just ask the 37s guys), right?
> 
> That's it?  Backups?  Seriously man, that's a lame reason to do anything.  Especially since backing up a file system is *infinitely* easier than a database.  In real companies around the world there are little children crying because every night the DBA has to shut the production databases down to back them up, even if Oracle says they don't.
> 
> Backing up a file system does not require shutting it down, and can even be done with just simple rsync scripts.
> 

-- 
==
Will Green

Find out why this email is 5 sentences or less at http://five.sentec.es/

From evan at cloudbur.st  Sun Sep  2 01:59:56 2007
From: evan at cloudbur.st (Evan Weaver)
Date: Sun, 2 Sep 2007 01:59:56 -0400
Subject: [Mongrel] Possible memory leak problem...
In-Reply-To: <46D9F2F0.2070007@hotgazpacho.com>
References: <61B5B973-C9E5-48AC-AD8F-E748FD22F4CA@zero.it>
	<C2DB09C9-5852-46B2-91FD-17F75758B2D7@gmail.com>
	<86987bdf0708192050r282351bu7256e44cbba28b7@mail.gmail.com>
	<8c8513100708312154l16071187te3e8e75270ef063@mail.gmail.com>
	<20070901014029.837dba7d.zedshaw@zedshaw.com>
	<466af3440709010541n1100051elb4ee8b6271d6227@mail.gmail.com>
	<0F2D93B1-BACD-440C-BEA7-D95F2D08B434@brainspl.at>
	<46D9A56A.1010408@hotgazpacho.com>
	<20070901175109.7983daa0.zedshaw@zedshaw.com>
	<46D9F2F0.2070007@hotgazpacho.com>
Message-ID: <b6f68fc60709012259uf771103obc1662a562a91fdd@mail.gmail.com>

The experimental MyBS MySQL engine can serve columns directly from the
db to the client.

http://www.blobstreaming.org/download/index.php

Just saying.

Evan

On 9/1/07, Will Green <will at hotgazpacho.com> wrote:
> Please, by all means, feel free to make this argument to my boss...
>
>
> Zed A. Shaw wrote:
> > On Sat, 01 Sep 2007 13:46:18 -0400
> > Will Green <will at hotgazpacho.com> wrote:
> >
> >> Not necessarily so, Ezra. Storing images in the database is perfectly
> >> legitimate.  However, just like Rails HTML views, you could implement
> >> caching of the images on the filesystem (i.e. write them to both the FS
> >> and the DB). Whatever action "renders" the image could take care of
> >> caching on the FS, serving the FS version if the DB version has, for
> >> example, the same MD5 hash as the one in the DB.
> >
> > No, not right at all.  All RDBMS were originally designed to store relations, not files.  It's only recently that people started putting every damn thing they could into a RDBMS.  The smart folks just put the data on a file system behind a specialized image web server.  Then, when you need to serve the image, you, uh serve it.  Doesn't get much easier than that.
> >
> >> Yes, performance will be a bit less than pure FS, but backups are a
> >> whole lot simpler (just backup and restore the DB). Besides, servers are
> >> cheap compared to developers (just ask the 37s guys), right?
> >
> > That's it?  Backups?  Seriously man, that's a lame reason to do anything.  Especially since backing up a file system is *infinitely* easier than a database.  In real companies around the world there are little children crying because every night the DBA has to shut the production databases down to back them up, even if Oracle says they don't.
> >
> > Backing up a file system does not require shutting it down, and can even be done with just simple rsync scripts.
> >
>
> --
> ==
> Will Green
>
> Find out why this email is 5 sentences or less at http://five.sentec.es/
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


-- 
Evan Weaver
Cloudburst, LLC

From j.list at blueboxdev.com  Sun Sep  2 03:17:46 2007
From: j.list at blueboxdev.com (Jesse Proudman)
Date: Sun, 2 Sep 2007 00:17:46 -0700
Subject: [Mongrel] Possible memory leak problem...
In-Reply-To: <b6f68fc60709012259uf771103obc1662a562a91fdd@mail.gmail.com>
References: <61B5B973-C9E5-48AC-AD8F-E748FD22F4CA@zero.it>
	<C2DB09C9-5852-46B2-91FD-17F75758B2D7@gmail.com>
	<86987bdf0708192050r282351bu7256e44cbba28b7@mail.gmail.com>
	<8c8513100708312154l16071187te3e8e75270ef063@mail.gmail.com>
	<20070901014029.837dba7d.zedshaw@zedshaw.com>
	<466af3440709010541n1100051elb4ee8b6271d6227@mail.gmail.com>
	<0F2D93B1-BACD-440C-BEA7-D95F2D08B434@brainspl.at>
	<46D9A56A.1010408@hotgazpacho.com>
	<20070901175109.7983daa0.zedshaw@zedshaw.com>
	<46D9F2F0.2070007@hotgazpacho.com>
	<b6f68fc60709012259uf771103obc1662a562a91fdd@mail.gmail.com>
Message-ID: <7013DB4D-AFCF-4AE2-929C-FDDF904D381A@blueboxdev.com>

Does any one else find pleasure in the name MyBS?

--

Jesse Proudman,  Blue Box Group, LLC




On Sep 1, 2007, at 10:59 PM, Evan Weaver wrote:

> The experimental MyBS MySQL engine can serve columns directly from the
> db to the client.


From jgeiger at gmail.com  Sun Sep  2 09:18:09 2007
From: jgeiger at gmail.com (Joey Geiger)
Date: Sun, 2 Sep 2007 09:18:09 -0400
Subject: [Mongrel] Possible memory leak problem...
In-Reply-To: <7013DB4D-AFCF-4AE2-929C-FDDF904D381A@blueboxdev.com>
References: <61B5B973-C9E5-48AC-AD8F-E748FD22F4CA@zero.it>
	<8c8513100708312154l16071187te3e8e75270ef063@mail.gmail.com>
	<20070901014029.837dba7d.zedshaw@zedshaw.com>
	<466af3440709010541n1100051elb4ee8b6271d6227@mail.gmail.com>
	<0F2D93B1-BACD-440C-BEA7-D95F2D08B434@brainspl.at>
	<46D9A56A.1010408@hotgazpacho.com>
	<20070901175109.7983daa0.zedshaw@zedshaw.com>
	<46D9F2F0.2070007@hotgazpacho.com>
	<b6f68fc60709012259uf771103obc1662a562a91fdd@mail.gmail.com>
	<7013DB4D-AFCF-4AE2-929C-FDDF904D381A@blueboxdev.com>
Message-ID: <466af3440709020618g79f22e17k243d268289a9ee7c@mail.gmail.com>

I'm storing the images in a DB because they are shared between 4 web
servers, any of which can submit an image. We are rsynching the MAIN
webserver to the 3 other subboxes, but we aren't going the other way.

In a perfect world, I'd have a separate image server or file storage
area, but we don't have the time or money to do that. I'm not serving
the images every time from the DB, rails is actually caching the file
on the first read anyway.


On 9/2/07, Jesse Proudman <j.list at blueboxdev.com> wrote:
> Does any one else find pleasure in the name MyBS?
>
> --
>
> Jesse Proudman,  Blue Box Group, LLC
>
>
>
>
> On Sep 1, 2007, at 10:59 PM, Evan Weaver wrote:
>
> > The experimental MyBS MySQL engine can serve columns directly from the
> > db to the client.
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>

From wayneeseguin at gmail.com  Sun Sep  2 21:29:58 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Sun, 2 Sep 2007 21:29:58 -0400
Subject: [Mongrel] Possible memory leak problem...
In-Reply-To: <7013DB4D-AFCF-4AE2-929C-FDDF904D381A@blueboxdev.com>
References: <61B5B973-C9E5-48AC-AD8F-E748FD22F4CA@zero.it>
	<C2DB09C9-5852-46B2-91FD-17F75758B2D7@gmail.com>
	<86987bdf0708192050r282351bu7256e44cbba28b7@mail.gmail.com>
	<8c8513100708312154l16071187te3e8e75270ef063@mail.gmail.com>
	<20070901014029.837dba7d.zedshaw@zedshaw.com>
	<466af3440709010541n1100051elb4ee8b6271d6227@mail.gmail.com>
	<0F2D93B1-BACD-440C-BEA7-D95F2D08B434@brainspl.at>
	<46D9A56A.1010408@hotgazpacho.com>
	<20070901175109.7983daa0.zedshaw@zedshaw.com>
	<46D9F2F0.2070007@hotgazpacho.com>
	<b6f68fc60709012259uf771103obc1662a562a91fdd@mail.gmail.com>
	<7013DB4D-AFCF-4AE2-929C-FDDF904D381A@blueboxdev.com>
Message-ID: <30BAD1B2-AEDD-4809-A11F-83FB4C1BF002@gmail.com>

On Sep 02, 2007, at 03:17 , Jesse Proudman wrote:
> Does any one else find pleasure in the name MyBS?

Very much so :)

   ~Wayne

s///g
Wayne E. Seguin
Sr. Systems Architect & Systems Administrator

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070902/c8a23bd3/attachment.html 

From flujan at gmail.com  Mon Sep  3 19:09:40 2007
From: flujan at gmail.com (Fernando Lujan)
Date: Mon, 3 Sep 2007 20:09:40 -0300
Subject: [Mongrel] Mongrel and Memory usage.
Message-ID: <631837390709031609x3cca5608s6a2756e04e9a6f6f@mail.gmail.com>

Hi,

I am using mongrel for a long time... But just now I see a problem. I am
running 3 instances using mongrel_cluster and nginx as a reverse proxy. When
I start the cluster I have a memory usage of 20MB per instance... In the end
of the day this usage is something about 230MB for each instance. It should
be a memory leak?

Thanks for the help.

-- 
Fernando Lujan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070903/3b3d3f1a/attachment.html 

From bk at benjaminkrause.com  Tue Sep  4 03:27:59 2007
From: bk at benjaminkrause.com (Benjamin Krause)
Date: Tue, 4 Sep 2007 09:27:59 +0200
Subject: [Mongrel] Mongrel and Memory usage.
In-Reply-To: <631837390709031609x3cca5608s6a2756e04e9a6f6f@mail.gmail.com>
References: <631837390709031609x3cca5608s6a2756e04e9a6f6f@mail.gmail.com>
Message-ID: <5A4D2AA6-B55D-4D26-BF4A-D4B0B582773C@benjaminkrause.com>

Fernando,

> I am using mongrel for a long time... But just now I see a problem.  
> I am running 3 instances using mongrel_cluster and nginx as a  
> reverse proxy. When I start the cluster I have a memory usage of  
> 20MB per instance... In the end of the day this usage is something  
> about 230MB for each instance. It should be a memory leak?

This is most probably a memory leak, but not necessarily a mongrel  
related issue.

You should check your app with bleak_house[1] or any other memory  
profiling tool to see, where the leak comes from. I had the same  
problem and the leak was caused by ferret[2]. Some native extensions  
(like rmagick) might be the problem.

Ben

[1] http://blog.evanweaver.com/files/doc/fauna/bleak_house/files/ 
README.html
[2] http://blog.omdb-beta.org/2007/7/29/tracking-down-a-memory-leak- 
in-ferret-0-11-4


From matte at ruckuswireless.com  Tue Sep  4 16:37:52 2007
From: matte at ruckuswireless.com (Matte Edens)
Date: Tue, 04 Sep 2007 13:37:52 -0700
Subject: [Mongrel] Mongrel and Memory usage.
In-Reply-To: <5A4D2AA6-B55D-4D26-BF4A-D4B0B582773C@benjaminkrause.com>
References: <631837390709031609x3cca5608s6a2756e04e9a6f6f@mail.gmail.com>
	<5A4D2AA6-B55D-4D26-BF4A-D4B0B582773C@benjaminkrause.com>
Message-ID: <46DDC220.3020904@ruckuswireless.com>

Here's another possibility that I encountered before I was smarter (heh)

Are you providing download capabilities of large files.  I manage a 
support site for firmware downloads and other documents.  Before I 
discovered the X-Sendfile header, mongrel was loading and serving the 
files.  I had MAJOR memory spikes.  Now that Apache is grabbing that 
request (and sending the file) before proxying the request to Mongrel, 
no more problems.

matte - webmonkey
webmaster at ruckuswireless.com

Benjamin Krause wrote:
> Fernando,
>
>   
>> I am using mongrel for a long time... But just now I see a problem.  
>> I am running 3 instances using mongrel_cluster and nginx as a  
>> reverse proxy. When I start the cluster I have a memory usage of  
>> 20MB per instance... In the end of the day this usage is something  
>> about 230MB for each instance. It should be a memory leak?
>>     
>
> This is most probably a memory leak, but not necessarily a mongrel  
> related issue.
>
> You should check your app with bleak_house[1] or any other memory  
> profiling tool to see, where the leak comes from. I had the same  
> problem and the leak was caused by ferret[2]. Some native extensions  
> (like rmagick) might be the problem.
>
> Ben
>
> [1] http://blog.evanweaver.com/files/doc/fauna/bleak_house/files/ 
> README.html
> [2] http://blog.omdb-beta.org/2007/7/29/tracking-down-a-memory-leak- 
> in-ferret-0-11-4
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070904/bd49ce45/attachment.html 

From chris at codeintensity.com  Tue Sep  4 19:55:36 2007
From: chris at codeintensity.com (Christopher Bailey)
Date: Tue, 4 Sep 2007 16:55:36 -0700
Subject: [Mongrel] Possible memory leak problem...
In-Reply-To: <20070901014029.837dba7d.zedshaw@zedshaw.com>
References: <61B5B973-C9E5-48AC-AD8F-E748FD22F4CA@zero.it>
	<C2DB09C9-5852-46B2-91FD-17F75758B2D7@gmail.com>
	<86987bdf0708192050r282351bu7256e44cbba28b7@mail.gmail.com>
	<8c8513100708312154l16071187te3e8e75270ef063@mail.gmail.com>
	<20070901014029.837dba7d.zedshaw@zedshaw.com>
Message-ID: <8c8513100709041655v381657baj36553e82cc338442@mail.gmail.com>

Thanks Zed.  This is the direction we are going, but it is non-trivial due
to how our storage and authentication system works.  A reality
none-the-less.

On 8/31/07, Zed A. Shaw <zedshaw at zedshaw.com> wrote:
>
> On Fri, 31 Aug 2007 21:54:53 -0700
> "Christopher Bailey" <chris at codeintensity.com> wrote:
>
> > We are finding that anytime our application sends back large files to
> the
> > requestor, we start chewing up memory fast.  We haven't determined the
> > precise cause or how to solve it yet, but it sounds like the same kind
> of
> > situation.  In our case, the particular large files are usually not
> > generated by Builder, but typically are actually files being
> > downloaded/transferred (e.g. images, documents, etc.).
>
> This is because Mongrel collects your large file response into a StringIO
> so that it can keep rails happy.  After the StringIO is done and rails
> leaves the locked section of code it then shoves that out the door on the
> socket.
>
> You are expecting to write a file, in rails, using Ruby's crappy IO, and
> that it would go immediately on the socket.  That's probably why you're
> seeing this.
>
> In reality, if it's a large file, and you know where it is, then you
> should let a real web server handle it, or at a minimum write a Mongrel
> Handler to do the real heavy lifting.
>
> There's plenty of information on doing this, but seriously, do not ever
> use send_file in rails or similar.  It's just a waste of resources, and even
> if you need to authenticate you can use X-Sendfile in apache or nginx and
> that'll let you auth someone then send the file.
>
> --
> Zed A. Shaw
> - Hate: http://savingtheinternetwithhate.com/
> - Good: http://www.zedshaw.com/
> - Evil: http://yearofevil.com/
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070904/42ce64f6/attachment.html 

From mrueckert at suse.de  Wed Sep  5 09:47:02 2007
From: mrueckert at suse.de (Marcus Rueckert)
Date: Wed, 5 Sep 2007 15:47:02 +0200
Subject: [Mongrel] Possible memory leak problem...
In-Reply-To: <8c8513100709041655v381657baj36553e82cc338442@mail.gmail.com>
References: <61B5B973-C9E5-48AC-AD8F-E748FD22F4CA@zero.it>
	<C2DB09C9-5852-46B2-91FD-17F75758B2D7@gmail.com>
	<86987bdf0708192050r282351bu7256e44cbba28b7@mail.gmail.com>
	<8c8513100708312154l16071187te3e8e75270ef063@mail.gmail.com>
	<20070901014029.837dba7d.zedshaw@zedshaw.com>
	<8c8513100709041655v381657baj36553e82cc338442@mail.gmail.com>
Message-ID: <20070905134702.GV3255@suse.de>

On 2007-09-04 16:55:36 -0700, Christopher Bailey wrote:
> Thanks Zed.  This is the direction we are going, but it is non-trivial due
> to how our storage and authentication system works.  A reality
> none-the-less.

at least the authentication/authorization issues can be solved with
x-(lighttpd-)sendfile

    darix

-- 
          openSUSE - SUSE Linux is my linux
              openSUSE is good for you
                  www.opensuse.org

From cjwoodward at gmail.com  Thu Sep  6 13:55:37 2007
From: cjwoodward at gmail.com (Carl Woodward)
Date: Thu,  6 Sep 2007 18:55:37 +0100 (BST)
Subject: [Mongrel] Invite from Carl Woodward (cjwoodward@gmail.com)
Message-ID: <20070906175537.766442B0CF3@mail2.quechup.com>

CarlWoodward (cjwoodward at gmail.com)
has invited you as a friend on Quechup... 
	...the social networking platform sweeping the globe

Go to: http://quechup.com/join.php/aT0wMDAwMDAwMDA5NTI5MTMxJmM9OTkyMDg%3D
to accept Carl's invite

You can use Quechup to meet new people, catch up with old friends,
maintain a blog, share videos &amp; photos, chat with other members, play
games, and more.
It's no wonder Quechup is fast becoming 'The Social Networking site to be
on'

Join Carl and his friends today:
http://quechup.com/join.php/aT0wMDAwMDAwMDA5NTI5MTMxJmM9OTkyMDg%3D
------------------------------------------------------------------
You received this because Carl Woodward (cjwoodward at gmail.com) knows and
agreed to invite you. You will only receive one invitation from
cjwoodward at gmail.com. Quechup will not spam or sell your email address, see
our privacy policy - http://quechup.com/privacy.php
Go to
http://quechup.com/emailunsubscribe.php/ZW09bW9uZ3JlbC11c2Vyc0BydWJ5Zm9yZ2Uub3Jn
if you do not wish to receive any more emails from Quechup.
------------------------------------------------------------------
Copyright Quechup.com 2007.
------------------------------------
Go to
http://quechup.com/emailunsubscribe.php/ZW09bW9uZ3JlbC11c2Vyc0BydWJ5Zm9yZ2Uub3Jn
if you do not wish to receive any more emails from Quechup
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070906/8331d0e4/attachment-0001.html 

From casper at lol.dk  Fri Sep  7 03:30:23 2007
From: casper at lol.dk (Casper Fabricius)
Date: Fri, 07 Sep 2007 09:30:23 +0200
Subject: [Mongrel] Fails to restart mongrel cluster after Capistrano
 rollback (PIDs not deleted)
Message-ID: <389A7842-CD02-435F-8B76-D3BE5EB2C4E0@lol.dk>

Hi,

I am deploying a Rails website using Capistrano to a VPS running the  
site through Apache and Mongrel.

'cap deploy' works fine, and mongrels are restarted. When I execute  
'cap deploy:rollback', however, my script fails to restart the  
mongrels giving this error:
!!! PID file tmp/pids/mongrel.5000.pid already exists.  Mongrel could  
be running already.  Check your log/mongrel.5000.log for errors.

I have a hunch that the error is related to the fact that I link /tmp/ 
pids into the shared directory upon each release in the  
"after_update" task, but I'm not sure how I end up with this problem,  
as the old dir I'm rolling back also has the link setup. The mongrels  
are stopped, but for some reason they don't clean up their PID files,  
and thus they fail to start again.

The full output of the rollback looks like this:
http://pastie.caboo.se/94602

My deploy.rb looks like this:
http://pastie.caboo.se/94600

Any help on this issue would be appreciated - thanks!

Best regards,
Casper Fabricius

From wayneeseguin at gmail.com  Fri Sep  7 12:15:34 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Fri, 7 Sep 2007 12:15:34 -0400
Subject: [Mongrel] Fails to restart mongrel cluster after Capistrano
	rollback (PIDs not deleted)
In-Reply-To: <389A7842-CD02-435F-8B76-D3BE5EB2C4E0@lol.dk>
References: <389A7842-CD02-435F-8B76-D3BE5EB2C4E0@lol.dk>
Message-ID: <29182826-820D-43A3-A673-9987549D8461@gmail.com>

On Sep 07, 2007, at 03:30 , Casper Fabricius wrote:
> Hi,
>
> I am deploying a Rails website using Capistrano to a VPS running the
> site through Apache and Mongrel.
>
> 'cap deploy' works fine, and mongrels are restarted. When I execute
> 'cap deploy:rollback', however, my script fails to restart the
> mongrels giving this error:
> !!! PID file tmp/pids/mongrel.5000.pid already exists.  Mongrel could
> be running already.  Check your log/mongrel.5000.log for errors.
>
> I have a hunch that the error is related to the fact that I link /tmp/
> pids into the shared directory upon each release in the
> "after_update" task, but I'm not sure how I end up with this problem,
> as the old dir I'm rolling back also has the link setup. The mongrels
> are stopped, but for some reason they don't clean up their PID files,
> and thus they fail to start again.
>
> The full output of the rollback looks like this:
> http://pastie.caboo.se/94602
>
> My deploy.rb looks like this:
> http://pastie.caboo.se/94600
>
> Any help on this issue would be appreciated - thanks!
>
> Best regards,
> Casper Fabricius
> ________________________________________

Casper,

I'd rewrite the default rollback task to:
1. Stop mongrel cluster
2. Rollback
3. Restart mongrel cluster

Between 2-3 you might also want to ensure that the new (old)  
"current" directory links the pid directory correctly.

   ~Wayne

s///g
Wayne E. Seguin
Sr. Systems Architect & Systems Administrator

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070907/f6484653/attachment.html 

From rogerpack2005 at gmail.com  Fri Sep  7 14:33:20 2007
From: rogerpack2005 at gmail.com (Roger Pack)
Date: Fri, 7 Sep 2007 12:33:20 -0600
Subject: [Mongrel] multi threaded theoretically useful?
Message-ID: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>

So here's a random question:  if a (Ruby) multi-threaded rails server could
exist (bug free), would it be faster than using a mongrel cluster?
(I.e. 10 mongrel processes versus 10 Ruby threads).  I'm not sure if
it would.  RAM it
might save, though.  Any thoughts?
-Roger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070907/d2fed9f0/attachment.html 

From ezmobius at gmail.com  Fri Sep  7 14:43:24 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Fri, 7 Sep 2007 11:43:24 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
Message-ID: <B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>


On Sep 7, 2007, at 11:33 AM, Roger Pack wrote:

> So here's a random question: if a (Ruby) multi-threaded rails  
> server could exist (bug free), would it be faster than using a  
> mongrel cluster? (I.e. 10 mongrel processes versus 10 Ruby  
> threads). I'm not sure if it would. RAM it might save, though. Any  
> thoughts? -Roger
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


Hey Roger-

	No it would not be as fast at all. Current ruby threads are green  
threads, meaning that they do not use native OS threads so there is  
no real parallel execution. Ruby has an internal timer and just  
switches between threads really fast. So 10 mongrels will trounce one  
thread safe mongrel.

	Ruby 1.9, Jruby and Rubinius will eventually have native threads and  
may make this situation better but for now such is life.

Cheers-
-- Ezra Zygmuntowicz 
-- Founder & Ruby Hacker
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)



From erik.hetzner at ucop.edu  Fri Sep  7 15:02:55 2007
From: erik.hetzner at ucop.edu (Erik Hetzner)
Date: Fri, 07 Sep 2007 12:02:55 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
Message-ID: <87d4wuz4bk.wl%erik.hetzner@ucop.edu>

At Fri, 7 Sep 2007 11:43:24 -0700,
Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> Hey Roger-
>
> 	No it would not be as fast at all. Current ruby threads are green
> threads, meaning that they do not use native OS threads so there is
> no real parallel execution. Ruby has an internal timer and just
> switches between threads really fast. So 10 mongrels will trounce one
> thread safe mongrel.
>
> 	Ruby 1.9, Jruby and Rubinius will eventually have native
> threads and may make this situation better but for now such is life.

I don?t want to muddy the waters here, as my knowledge of Ruby
threading performance is minimal, but there isn?t any ?real? parallel
execution on any uniprocessor machine: it?s all emulation. Erlang uses
green threads (but calls them processes) but context switches quite a
bit faster (if I understand correctly) than native threads or
processes. True, on a multiprocessor machine Ruby isn?t going to take
advantage of the situation without native threads or running multiple
processes. But it may turn out that a mixture of multiple processes
AND green threads provides greater performance than plain old multiple
processes.

This paper, for instance, from 2002, claims significantly better
performance on the JVM (Linux) with green threads than native.
<http://cselab.snu.ac.kr/member/naehyuck/papers/%5BJ14%5DComparative%20performance%20evaluation%20of%20Java%20threads%20for%20embedded%20applications.pdf>

best,
Erik Hetzner
;; Erik Hetzner, California Digital Library
;; gnupg key id: 1024D/01DB07E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070907/129a6b26/attachment.bin 

From cleaner416 at gmail.com  Fri Sep  7 13:37:06 2007
From: cleaner416 at gmail.com (cleaner416)
Date: Fri, 7 Sep 2007 13:37:06 -0400
Subject: [Mongrel] memcached and fragment storage,
	session storage with a mongrel cluster
Message-ID: <758206FE-C02C-422F-BAFF-61C6E21F7A08@gmail.com>

Greetings,

I posted this not on the Rails mailing list and didn't get a definitive
response so I thought I'd post it here, since I figure lots of you  
are using
mongrel with Rails apps. Any suggestions would be greatly appreciated.

I've been using file-based fragment caching and DB-based session
caching quite extensively.  I decided to try out memcached for both to
see if I could achieve a meaningful performance gain for a particular  
app.

I searched around a bit and simply added two lines to my
development.rb:

config.action_controller.fragment_cache_store = :mem_cache_store
config.action_controller.session_store = :mem_cache_store

(I also changed config.action_controller.perform_caching = true for
testing )

This works like a charm on my development box.  (Mac) I've got  
memcached -vv
running in another terminal window I can see it doing it's thing.

However, as soon as I tried this on my production box, (by adding the
above lines to production.rb) I ran into some odd problems.   My
production setup is pretty vanilla: Apache 2.2 load balancing to a
couple of mongrel instances via mongrel cluster on a fedora core 5
box.   It seems as if a memcache pool is being created for each
mongrel instance, instead of the app.  Is there some other kind of
config I need to do in production.rb?  The stuff I've found via
googling seems to apply to Rails < 1.2

Thanks much

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070907/308447f3/attachment-0001.html 

From wyhaines at gmail.com  Fri Sep  7 15:32:22 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Fri, 7 Sep 2007 12:32:22 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <87d4wuz4bk.wl%erik.hetzner@ucop.edu>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
Message-ID: <f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>

On 9/7/07, Erik Hetzner <erik.hetzner at ucop.edu> wrote:
> processes. True, on a multiprocessor machine Ruby isn't going to take
> advantage of the situation without native threads or running multiple
> processes. But it may turn out that a mixture of multiple processes
> AND green threads provides greater performance than plain old multiple
> processes.

I can state with a great deal of confidence that in this problem
domain, Ruby's green threading will not get you greater throughput.

A given process can only do so much work. If, in the course of doing
that work, there is an external latency, such as waiting on some IO,
that can be done in a non-blocking way, then it's possible to get more
work out of that process per unit time by using threads.

The work involved in handling web browser requests and rendering
responses back to them, though, doesn't tend to fall into this
category. It tends to be CPU intensive, and when one is waiting for
something external, like a database query, one is usually waiting
inside the body of the low level extension based database driver, so
thread context switching doesn't happen there, anyway.

The most efficient way of dealing with these sorts of things, from a
throughput perspective, is to avoid the overhead of threads completely
and just pound them through, one at a time, with 100% of the process
resources working on that single request at a time.

This doesn't change if you have one process or ten processes for your app/site.


Kirk Haines

swiftiply.swiftcore.org
analogger.swiftcore.org

From pete at nextengine.com  Fri Sep  7 15:06:41 2007
From: pete at nextengine.com (Pete DeLaurentis)
Date: Fri, 7 Sep 2007 12:06:41 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <87d4wuz4bk.wl%erik.hetzner@ucop.edu>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
Message-ID: <9795143F-AE04-49F2-B8E5-907EEC910417@nextengine.com>

Here's one question that I think would have an impact on how useful  
green threads are for many server apps:

If you are blocking on something like a database SELECT in one green  
thread, will the Ruby interpreter switch to another green thread  
while it's waiting for the response?

Or does a blocking request block all green threads?

Thanks,
Pete


On Sep 7, 2007, at 12:02 PM, Erik Hetzner wrote:

> At Fri, 7 Sep 2007 11:43:24 -0700,
> Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>> Hey Roger-
>>
>> 	No it would not be as fast at all. Current ruby threads are green
>> threads, meaning that they do not use native OS threads so there is
>> no real parallel execution. Ruby has an internal timer and just
>> switches between threads really fast. So 10 mongrels will trounce one
>> thread safe mongrel.
>>
>> 	Ruby 1.9, Jruby and Rubinius will eventually have native
>> threads and may make this situation better but for now such is life.
>
> I don?t want to muddy the waters here, as my knowledge of Ruby
> threading performance is minimal, but there isn?t any ?real? parallel
> execution on any uniprocessor machine: it?s all emulation. Erlang uses
> green threads (but calls them processes) but context switches quite a
> bit faster (if I understand correctly) than native threads or
> processes. True, on a multiprocessor machine Ruby isn?t going to take
> advantage of the situation without native threads or running multiple
> processes. But it may turn out that a mixture of multiple processes
> AND green threads provides greater performance than plain old multiple
> processes.
>
> This paper, for instance, from 2002, claims significantly better
> performance on the JVM (Linux) with green threads than native.
> <http://cselab.snu.ac.kr/member/naehyuck/papers/%5BJ14%5DComparative 
> %20performance%20evaluation%20of%20Java%20threads%20for%20embedded% 
> 20applications.pdf>
>
> best,
> Erik Hetzner
> ;; Erik Hetzner, California Digital Library
> ;; gnupg key id: 1024D/01DB07E3
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From terry.reese at oregonstate.edu  Fri Sep  7 16:01:03 2007
From: terry.reese at oregonstate.edu (Reese, Terry)
Date: Fri, 7 Sep 2007 13:01:03 -0700
Subject: [Mongrel] memcached and fragment storage,
	session storage with a mongrel cluster
In-Reply-To: <758206FE-C02C-422F-BAFF-61C6E21F7A08@gmail.com>
References: <758206FE-C02C-422F-BAFF-61C6E21F7A08@gmail.com>
Message-ID: <1454CCD2A8D4B74F9EEE8CB68C891CC901B6255D@NWS-EXCH3.nws.oregonstate.edu>

So we had some similar problems related to running our rails application
using either memcache or an sql-based sessioning solution using a number
of mongrels with Apache's balancer.  In the end, I think the problem we
had was related to a race condition when setting session data between
ajax calls.  On the rails trac instance, there has been a plugin
developed for these types of conditions called smartsessionstore.  It
works with the sql_session plugin, meaning your sessioning will be sql
based so not quite as fast as memcache, but I'm not sure if the
difference is actually noticable to users.  Here's the link:
http://www.texperts.com/2007/05/01/race-conditions-in-rails-sessions-and
-how-to-fix-them/
 
--TR 


________________________________

	From: mongrel-users-bounces at rubyforge.org
[mailto:mongrel-users-bounces at rubyforge.org] On Behalf Of cleaner416
	Sent: Friday, September 07, 2007 10:37 AM
	To: mongrel-users at rubyforge.org
	Subject: [Mongrel] memcached and fragment storage,session
storage with a mongrel cluster
	
	
	Greetings,

	I posted this not on the Rails mailing list and didn't get a
definitive 
	response so I thought I'd post it here, since I figure lots of
you are using
	mongrel with Rails apps. Any suggestions would be greatly
appreciated.
	
	
	I've been using file-based fragment caching and DB-based session
	caching quite extensively.  I decided to try out memcached for
both to
	see if I could achieve a meaningful performance gain for a
particular app.

	I searched around a bit and simply added two lines to my
	development.rb:

	config.action_controller.fragment_cache_store = :mem_cache_store
	config.action_controller.session_store = :mem_cache_store

	(I also changed config.action_controller.perform_caching = true
for
	testing )

	This works like a charm on my development box.  (Mac) I've got
memcached -vv
	running in another terminal window I can see it doing it's
thing.

	However, as soon as I tried this on my production box, (by
adding the
	above lines to production.rb) I ran into some odd problems.   My
	production setup is pretty vanilla: Apache 2.2 load balancing to
a
	couple of mongrel instances via mongrel cluster on a fedora core
5
	box.   It seems as if a memcache pool is being created for each
	mongrel instance, instead of the app.  Is there some other kind
of
	config I need to do in production.rb?  The stuff I've found via
	googling seems to apply to Rails < 1.2

	Thanks much
	
	

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070907/725fbbd6/attachment.html 

From wyhaines at gmail.com  Fri Sep  7 16:14:09 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Fri, 7 Sep 2007 13:14:09 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <9795143F-AE04-49F2-B8E5-907EEC910417@nextengine.com>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<9795143F-AE04-49F2-B8E5-907EEC910417@nextengine.com>
Message-ID: <f4cd26df0709071314o70430be5q22d0f9d0158809c0@mail.gmail.com>

On 9/7/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> Here's one question that I think would have an impact on how useful
> green threads are for many server apps:
>
> If you are blocking on something like a database SELECT in one green
> thread, will the Ruby interpreter switch to another green thread
> while it's waiting for the response?
>
> Or does a blocking request block all green threads?

When the flow of execution leaves Ruby and goes into some 3rd party
extension (like that of a DB library), then ruby can't context switch.

So yes, when one does a DB query that is going through a C extension,
all of the other green threads are blocked, so that latency can't be
captured.

If it could be, then yes, there would be some benefit from some number
of green threads per process for typical web apps.


Kirk Haines

From faisal at faisal.com  Fri Sep  7 16:14:29 2007
From: faisal at faisal.com (Faisal N Jawdat)
Date: Fri, 7 Sep 2007 16:14:29 -0400
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
Message-ID: <7AAA915C-358F-4C6D-9AA1-6983F10BDE6E@faisal.com>

Are you assuming that the memory hit per-thread is about the same as  
per mongrel process?

-faisal

On Sep 7, 2007, at 2:43 PM, Ezra Zygmuntowicz wrote:

>
> On Sep 7, 2007, at 11:33 AM, Roger Pack wrote:
>
>> So here's a random question: if a (Ruby) multi-threaded rails
>> server could exist (bug free), would it be faster than using a
>> mongrel cluster? (I.e. 10 mongrel processes versus 10 Ruby
>> threads). I'm not sure if it would. RAM it might save, though. Any
>> thoughts? -Roger
>> _______________________________________________
>> Mongrel-users mailing list
>> Mongrel-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-users
>
>
> Hey Roger-
>
> 	No it would not be as fast at all. Current ruby threads are green
> threads, meaning that they do not use native OS threads so there is
> no real parallel execution. Ruby has an internal timer and just
> switches between threads really fast. So 10 mongrels will trounce one
> thread safe mongrel.
>
> 	Ruby 1.9, Jruby and Rubinius will eventually have native threads and
> may make this situation better but for now such is life.
>
> Cheers-
> -- Ezra Zygmuntowicz 
> -- Founder & Ruby Hacker
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users


From wyhaines at gmail.com  Fri Sep  7 16:35:53 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Fri, 7 Sep 2007 13:35:53 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <7AAA915C-358F-4C6D-9AA1-6983F10BDE6E@faisal.com>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<7AAA915C-358F-4C6D-9AA1-6983F10BDE6E@faisal.com>
Message-ID: <f4cd26df0709071335l17f9cecevab876166097885bf@mail.gmail.com>

On 9/7/07, Faisal N Jawdat <faisal at faisal.com> wrote:
> Are you assuming that the memory hit per-thread is about the same as
> per mongrel process?

No.  It's irrelevant, because there's only so much work that a single
ruby process can do, regardless of the number of threads it contains.
Once the process is doing all of the work that it can, you only get
more work done by adding another process.  Repeat until all of your
CPUs are doing all of the work that they can.

I have a personal hunch that most of the time people are running more
Mongrels than they need to run to maximize the throughput on their
hardware, though.  Anyone who is concerned about the RAM footprint of
their application should step back and take a look at how many mongrel
processes they are running.  Do some analysis and see if they can
reduce that number without affecting throughput.

Maybe take a look at using Swiftiply+swiftiplied_mongrel
evented_mongrel instead of the threaded mongrel and look again.  I
think that in many cases a person can run a lot fewer processes than
they are, and still get the same, or maybe even better throughput.
Once your CPUs are at max utilization, more processes don't help.


Kirk Haines

From erik.hetzner at ucop.edu  Fri Sep  7 16:40:20 2007
From: erik.hetzner at ucop.edu (Erik Hetzner)
Date: Fri, 07 Sep 2007 13:40:20 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
Message-ID: <87bqceyzt7.wl%erik.hetzner@ucop.edu>

At Fri, 7 Sep 2007 12:32:22 -0700,
"Kirk Haines" <wyhaines at gmail.com> wrote:
>
> On 9/7/07, Erik Hetzner <erik.hetzner at ucop.edu> wrote:
> > processes. True, on a multiprocessor machine Ruby isn't going to take
> > advantage of the situation without native threads or running multiple
> > processes. But it may turn out that a mixture of multiple processes
> > AND green threads provides greater performance than plain old multiple
> > processes.
>
> I can state with a great deal of confidence that in this problem
> domain, Ruby's green threading will not get you greater throughput.

What problem domain? Web servers in general? Web applications? Web
applications which are heavily database dependent? I show below
that there are web apps whose throughput can be improved by green
threading.

> A given process can only do so much work. If, in the course of doing
> that work, there is an external latency, such as waiting on some IO,
> that can be done in a non-blocking way, then it's possible to get more
> work out of that process per unit time by using threads.

A process can use almost all the cycles available on a machine if the
scheduler allows it to, and if it has something to do. Threads and a
thread scheduler allow a process to have something to do.

> The work involved in handling web browser requests and rendering
> responses back to them, though, doesn't tend to fall into this
> category. It tends to be CPU intensive, and when one is waiting for
> something external, like a database query, one is usually waiting
> inside the body of the low level extension based database driver, so
> thread context switching doesn't happen there, anyway.

In my experience web applications tend to spend most of their time
waiting for other things, from databases, web services, etc. So
obviously your mileage may vary.

> The most efficient way of dealing with these sorts of things, from a
> throughput perspective, is to avoid the overhead of threads completely
> and just pound them through, one at a time, with 100% of the process
> resources working on that single request at a time.
>
> This doesn't change if you have one process or ten processes for
> your app/site.

Below is an example of what I?m getting at. You can tweak it to test
various things. It is a simple mongrel server that sleeps for 5 usecs
and then calculates the fibonacci number of 15. You can turn it into a
multi-threaded server by commented out the synchronize stuff. On my
uniprocessor machine you get half again the performance in terms of
requests/sec from multithreaded.

This probably does not model a typical web app. But my original
response was to a blanket statement that it was impossible to get
better performance from more threads. Here is an example of a web app
that gets better performance with more threads.

best,
Erik Hetzner

===============

require 'rubygems'
require 'mongrel'
require 'monitor'
port = ARGV[0]

class MyHttpHandler < Mongrel::HttpHandler
  @@lock = Monitor.new
  def fib(n)
    if n == 1 or n == 2 then
      return 1
    else
      return fib(n - 1) + fib(n - 2)
    end
  end
  def process(request,response)
    @@lock.synchronize do
      sleep 0.005
      response.start(200) do |head,body|
        body << fib(15).to_s
      end
    end
  end
end

config = Mongrel::Configurator.new :host => "localhost" do
  listener :port => port do
    uri "/", :handler => MyHttpHandler.new
  end
end
config.run
begin
  while true do
    sleep 1000000
  end
rescue Interrupt
end

===============;; Erik Hetzner, California Digital Library
;; gnupg key id: 1024D/01DB07E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070907/d7d2cc73/attachment-0001.bin 

From wyhaines at gmail.com  Fri Sep  7 16:50:50 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Fri, 7 Sep 2007 13:50:50 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <87bqceyzt7.wl%erik.hetzner@ucop.edu>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
Message-ID: <f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>

On 9/7/07, Erik Hetzner <erik.hetzner at ucop.edu> wrote

> What problem domain? Web servers in general? Web applications? Web
> applications which are heavily database dependent? I show below
> that there are web apps whose throughput can be improved by green
> threading.

The general area of Ruby web applications and the serving thereof.

> A process can use almost all the cycles available on a machine if the
> scheduler allows it to, and if it has something to do. Threads and a
> thread scheduler allow a process to have something to do.

Sure, but the _only_ way to get this with Ruby green threads is if you
have threads that are blocking on something within Ruby code, so that
Ruby can context switch to a different thread and get something done
with it while the first one sits around, waiting.  You artificially
construct exactly that scenario in your example below.  I'll comment
on it more in a minute.  In real apps, though, most of the time, that
just isn't happening.

> > The work involved in handling web browser requests and rendering
> > responses back to them, though, doesn't tend to fall into this
> > category. It tends to be CPU intensive, and when one is waiting for
> > something external, like a database query, one is usually waiting
> > inside the body of the low level extension based database driver, so
> > thread context switching doesn't happen there, anyway.
>
> In my experience web applications tend to spend most of their time
> waiting for other things, from databases, web services, etc. So
> obviously your mileage may vary.

And when you are waiting on something like a database, you are doing
it within the DB driver extension, so there are no context switches
happening -- your green threads are blocked.

> Below is an example of what I'm getting at. You can tweak it to test
> various things. It is a simple mongrel server that sleeps for 5 usecs
> and then calculates the fibonacci number of 15. You can turn it into a
> multi-threaded server by commented out the synchronize stuff. On my
> uniprocessor machine you get half again the performance in terms of
> requests/sec from multithreaded.

The reason you get more performance when multithreading is because of
that sleep call.  It is all happening inside of Ruby, so when running
in a multithreaded context, when one thread goes to sleep, the others
just get the execution cycles.  It's artificial, though.  Read Ruby
web apps don't tend to have latencies like that.  When they are
waiting, they are waiting inside of things that block the entire Ruby
process, and not just waiting for something that is blocking a single
thread.


Kirk Haines

From cleaner416 at gmail.com  Fri Sep  7 17:26:08 2007
From: cleaner416 at gmail.com (cleaner416)
Date: Fri, 7 Sep 2007 17:26:08 -0400
Subject: [Mongrel] memcached and fragment storage,
	session storage with a mongrel cluster
In-Reply-To: <1454CCD2A8D4B74F9EEE8CB68C891CC901B6255D@NWS-EXCH3.nws.oregonstate.edu>
References: <758206FE-C02C-422F-BAFF-61C6E21F7A08@gmail.com>
	<1454CCD2A8D4B74F9EEE8CB68C891CC901B6255D@NWS-EXCH3.nws.oregonstate.edu>
Message-ID: <77ED31AB-42C8-4129-BCA6-C89622FD1206@gmail.com>

Thanks, Terry.  That's very helpful.


On Sep 7, 2007, at 4:01 PM, Reese, Terry wrote:

> So we had some similar problems related to running our rails  
> application using either memcache or an sql-based sessioning  
> solution using a number of mongrels with Apache's balancer.  In the  
> end, I think the problem we had was related to a race condition  
> when setting session data between ajax calls.  On the rails trac  
> instance, there has been a plugin developed for these types of  
> conditions called smartsessionstore.  It works with the sql_session  
> plugin, meaning your sessioning will be sql based so not quite as  
> fast as memcache, but I'm not sure if the difference is actually  
> noticable to users.  Here's the link: http://www.texperts.com/ 
> 2007/05/01/race-conditions-in-rails-sessions-and-how-to-fix-them/
>
> --TR
>
> From: mongrel-users-bounces at rubyforge.org [mailto:mongrel-users- 
> bounces at rubyforge.org] On Behalf Of cleaner416
> Sent: Friday, September 07, 2007 10:37 AM
> To: mongrel-users at rubyforge.org
> Subject: [Mongrel] memcached and fragment storage,session storage  
> with a mongrel cluster
>
> Greetings,
>
> I posted this not on the Rails mailing list and didn't get a  
> definitive
> response so I thought I'd post it here, since I figure lots of you  
> are using
> mongrel with Rails apps. Any suggestions would be greatly appreciated.
>
> I've been using file-based fragment caching and DB-based session
> caching quite extensively.  I decided to try out memcached for both to
> see if I could achieve a meaningful performance gain for a  
> particular app.
>
> I searched around a bit and simply added two lines to my
> development.rb:
>
> config.action_controller.fragment_cache_store = :mem_cache_store
> config.action_controller.session_store = :mem_cache_store
>
> (I also changed config.action_controller.perform_caching = true for
> testing )
>
> This works like a charm on my development box.  (Mac) I've got  
> memcached -vv
> running in another terminal window I can see it doing it's thing.
>
> However, as soon as I tried this on my production box, (by adding the
> above lines to production.rb) I ran into some odd problems.   My
> production setup is pretty vanilla: Apache 2.2 load balancing to a
> couple of mongrel instances via mongrel cluster on a fedora core 5
> box.   It seems as if a memcache pool is being created for each
> mongrel instance, instead of the app.  Is there some other kind of
> config I need to do in production.rb?  The stuff I've found via
> googling seems to apply to Rails < 1.2
>
> Thanks much
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070907/8c47179d/attachment.html 

From erik.hetzner at ucop.edu  Fri Sep  7 17:36:56 2007
From: erik.hetzner at ucop.edu (Erik Hetzner)
Date: Fri, 07 Sep 2007 14:36:56 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
Message-ID: <87abryyx6v.wl%erik.hetzner@ucop.edu>

At Fri, 7 Sep 2007 13:50:50 -0700,
"Kirk Haines" <wyhaines at gmail.com> wrote:
>
> On 9/7/07, Erik Hetzner <erik.hetzner at ucop.edu> wrote
>
> > What problem domain? Web servers in general? Web applications? Web
> > applications which are heavily database dependent? I show below
> > that there are web apps whose throughput can be improved by green
> > threading.
>
> The general area of Ruby web applications and the serving thereof.

Which in my experience involves waiting for external web services,
among other things. If you want to say that this is something that
isn?t a typical rails app, fine. I?m telling you that my threads are
often i/o bound.

> Sure, but the _only_ way to get this with Ruby green threads is if
> you have threads that are blocking on something within Ruby code, so
> that Ruby can context switch to a different thread and get something
> done with it while the first one sits around, waiting. You
> artificially construct exactly that scenario in your example below.
> I'll comment on it more in a minute. In real apps, though, most of
> the time, that just isn't happening.

I understand how threads work, and I don?t think that my construction
is artificial.

> And when you are waiting on something like a database, you are doing
> it within the DB driver extension, so there are no context switches
> happening -- your green threads are blocked.

Surely it is possible to write a C extension for Ruby that allows
context switching from within it? This is outside my understanding of
Ruby threads.

> The reason you get more performance when multithreading is because
> of that sleep call. It is all happening inside of Ruby, so when
> running in a multithreaded context, when one thread goes to sleep,
> the others just get the execution cycles. It's artificial, though.
> Read Ruby web apps don't tend to have latencies like that. When they
> are waiting, they are waiting inside of things that block the entire
> Ruby process, and not just waiting for something that is blocking a
> single thread.

I know why we are getting greater performance, and again, I don?t
think it?s artificial. But, in any case, it was a demonstration,
mostly for the original responder, who claimed that you would never
get more performance from Ruby threads.

Again, your mileage may vary. And it?s all moot for rails users since
I don?t see rails going multithreaded.

best,
Erik Hetzner
;; Erik Hetzner, California Digital Library
;; gnupg key id: 1024D/01DB07E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070907/ec5d9f95/attachment.bin 

From brandorr at opensolaris.org  Fri Sep  7 17:45:56 2007
From: brandorr at opensolaris.org (Brandorr)
Date: Fri, 7 Sep 2007 17:45:56 -0400
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <9795143F-AE04-49F2-B8E5-907EEC910417@nextengine.com>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<9795143F-AE04-49F2-B8E5-907EEC910417@nextengine.com>
Message-ID: <5b5090780709071445w300a8444jeb0ed50ab50a51df@mail.gmail.com>

On 9/7/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> Here's one question that I think would have an impact on how useful
> green threads are for many server apps:
>
> If you are blocking on something like a database SELECT in one green
> thread, will the Ruby interpreter switch to another green thread
> while it's waiting for the response?
>
> Or does a blocking request block all green threads?

Well considering that a single-threaded process will map to a single
kernel thread in Solaris 9+ and Linux 2.6+. A process with green
threads that makes a system call will be blocked, until the call
returns, that means that all green threads in that process are
blocked. (Green threads are now known as fibers) ;)

This is one reason why IO intensive workloads, which make intensive
use of system calls, should benefit from "real" kernel threads, while
CPU intensive workloads can have the edge when implemented using green
threads, vs kernel threads. (The context switching cost being  lower.)

> Thanks,
> Pete
>
>
> On Sep 7, 2007, at 12:02 PM, Erik Hetzner wrote:
>
> > At Fri, 7 Sep 2007 11:43:24 -0700,
> > Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> >> Hey Roger-
> >>
> >>      No it would not be as fast at all. Current ruby threads are green
> >> threads, meaning that they do not use native OS threads so there is
> >> no real parallel execution. Ruby has an internal timer and just
> >> switches between threads really fast. So 10 mongrels will trounce one
> >> thread safe mongrel.
> >>
> >>      Ruby 1.9, Jruby and Rubinius will eventually have native
> >> threads and may make this situation better but for now such is life.
> >
> > I don't want to muddy the waters here, as my knowledge of Ruby
> > threading performance is minimal, but there isn't any 'real' parallel
> > execution on any uniprocessor machine: it's all emulation. Erlang uses
> > green threads (but calls them processes) but context switches quite a
> > bit faster (if I understand correctly) than native threads or
> > processes. True, on a multiprocessor machine Ruby isn't going to take
> > advantage of the situation without native threads or running multiple
> > processes. But it may turn out that a mixture of multiple processes
> > AND green threads provides greater performance than plain old multiple
> > processes.
> >
> > This paper, for instance, from 2002, claims significantly better
> > performance on the JVM (Linux) with green threads than native.
> > <http://cselab.snu.ac.kr/member/naehyuck/papers/%5BJ14%5DComparative
> > %20performance%20evaluation%20of%20Java%20threads%20for%20embedded%
> > 20applications.pdf>
> >
> > best,
> > Erik Hetzner
> > ;; Erik Hetzner, California Digital Library
> > ;; gnupg key id: 1024D/01DB07E3
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
>


-- 
- Brian Gupta

http://opensolaris.org/os/project/nycosug/

From wyhaines at gmail.com  Fri Sep  7 18:34:49 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Fri, 7 Sep 2007 15:34:49 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <87abryyx6v.wl%erik.hetzner@ucop.edu>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
	<87abryyx6v.wl%erik.hetzner@ucop.edu>
Message-ID: <f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>

On 9/7/07, Erik Hetzner <erik.hetzner at ucop.edu> wrote:

> > And when you are waiting on something like a database, you are doing
> > it within the DB driver extension, so there are no context switches
> > happening -- your green threads are blocked.
>
> Surely it is possible to write a C extension for Ruby that allows
> context switching from within it? This is outside my understanding of
> Ruby threads.

Maybe, but it's irrelevant.  The MySQL/Pg/whatever drivers aren't
written to be aware of Ruby internals.

> > The reason you get more performance when multithreading is because
> > of that sleep call. It is all happening inside of Ruby, so when
> > running in a multithreaded context, when one thread goes to sleep,
> > the others just get the execution cycles. It's artificial, though.
> > Read Ruby web apps don't tend to have latencies like that. When they
> > are waiting, they are waiting inside of things that block the entire
> > Ruby process, and not just waiting for something that is blocking a
> > single thread.
>
> I know why we are getting greater performance, and again, I don't
> think it's artificial. But, in any case, it was a demonstration,
> mostly for the original responder, who claimed that you would never
> get more performance from Ruby threads.

Ezra?  His response simplified it.  Of course there are situations
where green threads improve performance.  They can be quantified very
simply, as I already have.  When there are external latencies that are
not blocking the entire process, green threads can capture those
latencies and turn them into additional work.  A sleep() call is such
a latency.  Any pure ruby code that stays in rubyland and doesn't go
into an external extension is such a latency.  A DB query that spends
most of its time inside of some C library that is external to Ruby is
not such a latency.

> Again, your mileage may vary. And it's all moot for rails users since
> I don't see rails going multithreaded.

It's not very difficult, actually, to do it.  Just make a copy of the
rails.rb mongrel handler for Rails.  Remove the bit that wraps the
call to Dispatcher.dispatch() in a @guard.synchronize block.

Whether all of Rails is actually threadsafe, and whether one's code
is....that's another thing, but it's easy to run Rails in multiple
threads under Mongrel if one wants to play with that.


Kirk Haines

From ezmobius at gmail.com  Fri Sep  7 18:39:33 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Fri, 7 Sep 2007 15:39:33 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
	<87abryyx6v.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
Message-ID: <0BD07355-FCC0-4029-BA1E-A3542C2EF32A@gmail.com>

Hi~

On Sep 7, 2007, at 3:34 PM, Kirk Haines wrote:

> On 9/7/07, Erik Hetzner <erik.hetzner at ucop.edu> wrote:
>
>>> And when you are waiting on something like a database, you are doing
>>> it within the DB driver extension, so there are no context switches
>>> happening -- your green threads are blocked.
>>
>> Surely it is possible to write a C extension for Ruby that allows
>> context switching from within it? This is outside my understanding of
>> Ruby threads.
>
> Maybe, but it's irrelevant.  The MySQL/Pg/whatever drivers aren't
> written to be aware of Ruby internals.
>
>>> The reason you get more performance when multithreading is because
>>> of that sleep call. It is all happening inside of Ruby, so when
>>> running in a multithreaded context, when one thread goes to sleep,
>>> the others just get the execution cycles. It's artificial, though.
>>> Read Ruby web apps don't tend to have latencies like that. When they
>>> are waiting, they are waiting inside of things that block the entire
>>> Ruby process, and not just waiting for something that is blocking a
>>> single thread.
>>
>> I know why we are getting greater performance, and again, I don't
>> think it's artificial. But, in any case, it was a demonstration,
>> mostly for the original responder, who claimed that you would never
>> get more performance from Ruby threads.

Yeah I actually said that you would never get more performance out of  
one mongrel running 10 threads then you would with 10 mongrels  
running one thread. Just to clarify ;)


-- Ezra



From erik.hetzner at ucop.edu  Fri Sep  7 19:23:18 2007
From: erik.hetzner at ucop.edu (Erik Hetzner)
Date: Fri, 07 Sep 2007 16:23:18 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <0BD07355-FCC0-4029-BA1E-A3542C2EF32A@gmail.com>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
	<87abryyx6v.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
	<0BD07355-FCC0-4029-BA1E-A3542C2EF32A@gmail.com>
Message-ID: <878x7iys9l.wl%erik.hetzner@ucop.edu>

At Fri, 7 Sep 2007 15:39:33 -0700,
Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> [?]
>
> > On 9/7/07, Erik Hetzner <erik.hetzner at ucop.edu> wrote:

> [?]

> >> I know why we are getting greater performance, and again, I don't
> >> think it's artificial. But, in any case, it was a demonstration,
> >> mostly for the original responder, who claimed that you would never
> >> get more performance from Ruby threads.
>
> Yeah I actually said that you would never get more performance out of
> one mongrel running 10 threads then you would with 10 mongrels
> running one thread. Just to clarify ;)

My apologies for misquoting you, and also apologies for referring to
you as ?the original responder? - a bit rude, really. :) Here is your
original message:

> Hey Roger-

> No it would not be as fast at all. Current ruby threads are green
> threads, meaning that they do not use native OS threads so there is
> no real parallel execution. Ruby has an internal timer and just
> switches between threads really fast. So 10 mongrels will trounce
> one thread safe mongrel.

> Ruby 1.9, Jruby and Rubinius will eventually have native threads and
> may make this situation better but for now such is life.

I?ve just tested this on my uniprocessor machine. 10 single-threaded
mongrels of my sample sleep + fibonacci web server, balanced behind an
apache load balancer, versus 1 multithreaded mongrels without a load
balancer. The performance, in terms of requests/second, is almost
identical.

best,
Erik Hetzner
;; Erik Hetzner, California Digital Library
;; gnupg key id: 1024D/01DB07E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070907/d1198563/attachment.bin 

From work at ashleymoran.me.uk  Sat Sep  8 12:39:37 2007
From: work at ashleymoran.me.uk (Ashley Moran)
Date: Sat, 8 Sep 2007 17:39:37 +0100
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
	<87abryyx6v.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
Message-ID: <1448881C-BF5D-48F3-BBA7-521B52428BD8@ashleymoran.me.uk>


On Sep 07, 2007, at 11:34 pm, Kirk Haines wrote:

> Whether all of Rails is actually threadsafe, and whether one's code
> is....that's another thing, but it's easy to run Rails in multiple
> threads under Mongrel if one wants to play with that.

Just out of curiosity, does anyone here use Nitro?  I'm going to  
switch from Rails to Nitro for one of my own projects.  I've heard it  
runs happily multi-threaded.  Anyone noticed any difference in  
performance?  (Or for that matter, with other frameworks that run  
multi-threaded like Camping and Merb?)  To my knowledge, the only  
apps big enough for scalability to be a serious issue are all in Rails.

Also, this thread has answered the question I've wondered lately,  
namely that MRI can't context switch if one thread is in a C  
extension like a database adapter?.  Will Rubinius go any way to help  
this, assuming the adapter is re-entrant?

Ashley

From wyhaines at gmail.com  Sat Sep  8 17:02:56 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Sat, 8 Sep 2007 14:02:56 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <1448881C-BF5D-48F3-BBA7-521B52428BD8@ashleymoran.me.uk>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
	<87abryyx6v.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
	<1448881C-BF5D-48F3-BBA7-521B52428BD8@ashleymoran.me.uk>
Message-ID: <f4cd26df0709081402g2d43e9ebs924027646ba769e1@mail.gmail.com>

On 9/8/07, Ashley Moran <work at ashleymoran.me.uk> wrote:

> Just out of curiosity, does anyone here use Nitro?  I'm going to
> switch from Rails to Nitro for one of my own projects.  I've heard it
> runs happily multi-threaded.  Anyone noticed any difference in
> performance?  (Or for that matter, with other frameworks that run
> multi-threaded like Camping and Merb?)  To my knowledge, the only
> apps big enough for scalability to be a serious issue are all in Rails.

I don't use Nitro, but I have followed its development for a couple
years, and have done some benchmarks with it.

It is somewhat faster than Rails (though there was a very extensive
rewrite that is nearing completion for the 0.50 release, and I have no
idea what the rewrite has done to overall performance), and yes, it's
Mongrel handler runs in a multithreaded mode.

Actually, every framework except for Rails will Run in that way.
Merb, as an example, runs multithreaded, and is one of the fastest
Ruby frameworks (in my benchmarks, only IOWA is faster), and it has
some projects that do use clusters (I am helping someone setup a small
clustered app for demo purposes this weekend, for example).  I have
written several applications that were designed for clustering and for
heavy, multiserver use with IOWA (but the customers never ended up
taking them there, alas).  Ramaze is also a nice, multithread-safe
framework that merits some attention.  It is kind of like Nitro's
Merb.  Inspired by Nitro, but lighter weight, reasonably fast, with
some good ideas in it.

> Also, this thread has answered the question I've wondered lately,
> namely that MRI can't context switch if one thread is in a C
> extension like a database adapter?.  Will Rubinius go any way to help
> this, assuming the adapter is re-entrant?

With Rubinius (or JRuby) it is not the same issue because they are
using OS level threads.


Kirk Haines

From work at ashleymoran.me.uk  Sat Sep  8 17:53:27 2007
From: work at ashleymoran.me.uk (Ashley Moran)
Date: Sat, 8 Sep 2007 22:53:27 +0100
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <f4cd26df0709081402g2d43e9ebs924027646ba769e1@mail.gmail.com>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
	<87abryyx6v.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
	<1448881C-BF5D-48F3-BBA7-521B52428BD8@ashleymoran.me.uk>
	<f4cd26df0709081402g2d43e9ebs924027646ba769e1@mail.gmail.com>
Message-ID: <49065EA3-33E9-46A6-888A-780FE1D2FC46@ashleymoran.me.uk>


On Sep 08, 2007, at 10:02 pm, Kirk Haines wrote:

> Ramaze is also a nice, multithread-safe
> framework that merits some attention.  It is kind of like Nitro's
> Merb.  Inspired by Nitro, but lighter weight, reasonably fast, with
> some good ideas in it.

That one had passed me by.  Thanks for the heads up!


> With Rubinius (or JRuby) it is not the same issue because they are
> using OS level threads.

I appreciate that the issue is different with JRuby, since what  
matters there is whether the Java libraries are thread-safe (although  
I saw this week a project to give JRuby access to C libraries using  
JNI, name escapes me).

As for Rubinius, I figured it is in the same position as the Apache  
web server, where you can't use the worker MPM if you want to load  
thread-unsafe modules or modules that depend on thread-unsafe  
libraries (eg mod_php).  And I guess Rubinius still has the option of  
going the Erlang way of mapping N(requests) green threads onto N 
(cores) OS threads.

Please forgive and wildly incorrect statements I may have made...  
concurrent programming isn't something I know much about, mainly  
because I've avoided it due to the mind-boggling complexity of it  
(well, of threads).

Ashley

From erik.hetzner at ucop.edu  Sat Sep  8 18:19:28 2007
From: erik.hetzner at ucop.edu (Erik Hetzner)
Date: Sat, 08 Sep 2007 15:19:28 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
	<87abryyx6v.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
Message-ID: <873axoztov.wl%erik.hetzner@ucop.edu>

At Fri, 7 Sep 2007 15:34:49 -0700,
"Kirk Haines" <wyhaines at gmail.com> wrote:
> Maybe, but it's irrelevant.  The MySQL/Pg/whatever drivers aren't
> written to be aware of Ruby internals.

It is my estimation that any application is going to have a lot of
places where a ruby thread context switch is possible.

> Ezra?  His response simplified it.  Of course there are situations
> where green threads improve performance.  They can be quantified very
> simply, as I already have.  When there are external latencies that are
> not blocking the entire process, green threads can capture those
> latencies and turn them into additional work.  A sleep() call is such
> a latency.  Any pure ruby code that stays in rubyland and doesn't go
> into an external extension is such a latency.  A DB query that spends
> most of its time inside of some C library that is external to Ruby is
> not such a latency.

Here is what I am trying to get at.

(a) It is nonsense to say that because ruby threads are not ?real?
they will never be as fast as ?real? threads or multiple processes. It
is dependent, as I take you to mean, on the balance of your code
between code from which context switching can happen & code from which
it cannot.

(b) *If* you have an application that is threadsafe, you ought to
*test* it with multiple threads before you discount the possibility
that you will be able to get *comparable* performance out of ruby?s
threading than you will from multiple processes, esp. because running
multiple threads rather than multiple processes provides some
benefits.

It is my belief that in general with a threadsafe mongrel app you are
going to find that the best system is one that combines multiple
processes to take advantage of multiple cores & of preemptive
multitasking and multiple threads to take advantage of lower memory
consumption and the faster context switching which ruby should
provide.

Obviously everything depends on (a) your code, (b) your ruby
implementation, (c) your os?s scheduler, and (d) the phase of the
moon, which is why you ought to test to find out what works best.

best,
Erik Hetzner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070908/310c053b/attachment.bin 

From work at ashleymoran.me.uk  Sat Sep  8 18:50:34 2007
From: work at ashleymoran.me.uk (Ashley Moran)
Date: Sat, 8 Sep 2007 23:50:34 +0100
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <873axoztov.wl%erik.hetzner@ucop.edu>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
	<87abryyx6v.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
	<873axoztov.wl%erik.hetzner@ucop.edu>
Message-ID: <ADD3770F-EDA5-4AE0-8695-5AA1F7F8D630@ashleymoran.me.uk>


On Sep 08, 2007, at 11:19 pm, Erik Hetzner wrote:

> It is my belief that in general with a threadsafe mongrel app you are
> going to find that the best system is one that combines multiple
> processes to take advantage of multiple cores & of preemptive
> multitasking and multiple threads to take advantage of lower memory
> consumption and the faster context switching which ruby should
> provide.

Like I touched on in my last post, this is the strategy that Erlang  
takes, right?  (They seem to have the concurrency problem solved.)   
My immediate interest here is mainly lower memory consumption.  The  
server (read - dirt cheap PC) I just bought "only" has 1GB RAM, and  
will only hold 2GB.  Simply because I can't afford to go and buy  
anything bigger right now, I'd like to know I don't have to waste RAM  
running a shedload of 50-200MB processes.


> Obviously everything depends on (a) your code, (b) your ruby
> implementation, (c) your os?s scheduler, and (d) the phase of the
> moon

True.  Lycanthropy is not conducive to good software development.

Ashley

From _ at whats-your.name  Sat Sep  8 15:34:30 2007
From: _ at whats-your.name (cdr)
Date: Sat, 8 Sep 2007 19:34:30 +0000
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <f4cd26df0709081402g2d43e9ebs924027646ba769e1@mail.gmail.com>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
	<87abryyx6v.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
	<1448881C-BF5D-48F3-BBA7-521B52428BD8@ashleymoran.me.uk>
	<f4cd26df0709081402g2d43e9ebs924027646ba769e1@mail.gmail.com>
Message-ID: <20070908193430.GA2750@replic.net>

> taking them there, alas).  Ramaze is also a nice, multithread-safe
> framework that merits some attention.  It is kind of like Nitro's
> Merb.  Inspired by Nitro, but lighter weight, reasonably fast, with

now that MRI1.9 has Coroutines, it might be interseting to check out some of the Lua frameworks/webservers multiplexed on coroutines rather than threads, like Copas / Xavante.

er, i guess that would have to wait for anything to run on MRI1.9, nevermind..


From wyhaines at gmail.com  Sat Sep  8 19:49:58 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Sat, 8 Sep 2007 16:49:58 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <ADD3770F-EDA5-4AE0-8695-5AA1F7F8D630@ashleymoran.me.uk>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
	<87abryyx6v.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
	<873axoztov.wl%erik.hetzner@ucop.edu>
	<ADD3770F-EDA5-4AE0-8695-5AA1F7F8D630@ashleymoran.me.uk>
Message-ID: <f4cd26df0709081649r518df9bi38c1996de2df8b21@mail.gmail.com>

On 9/8/07, Ashley Moran <work at ashleymoran.me.uk> wrote:

> Like I touched on in my last post, this is the strategy that Erlang
> takes, right?  (They seem to have the concurrency problem solved.)
> My immediate interest here is mainly lower memory consumption.  The
> server (read - dirt cheap PC) I just bought "only" has 1GB RAM, and
> will only hold 2GB.  Simply because I can't afford to go and buy
> anything bigger right now, I'd like to know I don't have to waste RAM
> running a shedload of 50-200MB processes.

Just as a practical example, I run about 60 separate backend ruby
processes on one very modest server with 2GB of RAM, and a bunch more
across a few other servers.  These 60+ processes represent a cross
section of communications/request management technique, all backed by
the same basic framework, IOWA.

Some are multithreaded with a mod_ruby based handler for
communications to the backends (these are the oldest ones).

Some use FCGI as the communications conduit, to multithreaded backends.

Some run in Mongrel via a mongrel handler, multi-threaded.

Some use the Mongrel HTTP parser inside an event based application
loop, rendering them effectively single threaded, event based apps.

And some of them run behind Swiftiply, some with one node, and some
with multiple nodes.

On the one machine that has 60 backends on it, each of those
represents a separate site.  That is, all of the sites are ran off of
a single process.  They all use the same basic framework -- IOWA --
regardless of the communications model being used.

The sites with the greatest throughput capacity are invariably the
ones that run an event based communications model -- either the
mongrel HTTP parser inside an event loop, or behind Swiftiply.  I have
sites that, with every page rendered dynamically (from content stored
in a database), are capable of handling 285 requests/second with no
concurrency, up to about 360/second with a concurrency of 50 (measured
using ab).  If I switch it to a multithreaded model (mongrel handler),
the best that I can do, with no concurrency, is 220 page
requests/second, and if I have much concurrency at all, that number
quickly drops down towards 150/second.

I have two points, here.  First, you can run a considerable number of
ruby based sites on a single modest server like yours, and they can
handle a rather impressive traffic load on a single process, depending
on your framework.  And second, running the same code in an event
based pipeline versus a multithreaded pipeline invariably gives me
better peformance in my apps.


Kirk Haines

From work at ashleymoran.me.uk  Sat Sep  8 20:34:56 2007
From: work at ashleymoran.me.uk (Ashley Moran)
Date: Sun, 9 Sep 2007 01:34:56 +0100
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <f4cd26df0709081649r518df9bi38c1996de2df8b21@mail.gmail.com>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
	<87abryyx6v.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
	<873axoztov.wl%erik.hetzner@ucop.edu>
	<ADD3770F-EDA5-4AE0-8695-5AA1F7F8D630@ashleymoran.me.uk>
	<f4cd26df0709081649r518df9bi38c1996de2df8b21@mail.gmail.com>
Message-ID: <BE6B1856-0CC1-4440-A58E-FF4A81439F90@ashleymoran.me.uk>


On Sep 09, 2007, at 12:49 am, Kirk Haines wrote:

> I have two points, here.  First, you can run a considerable number of
> ruby based sites on a single modest server like yours, and they can
> handle a rather impressive traffic load on a single process, depending
> on your framework.  And second, running the same code in an event
> based pipeline versus a multithreaded pipeline invariably gives me
> better peformance in my apps.

Interesting!  What about the case of long-running requests, eg file  
uploads, outgoing web service requests or complex calculations?  Do  
you have any of those, and if so, how does it affect the balance of  
event-based vs multithreaded?

Ashley

From wyhaines at gmail.com  Sat Sep  8 21:31:48 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Sat, 8 Sep 2007 18:31:48 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <BE6B1856-0CC1-4440-A58E-FF4A81439F90@ashleymoran.me.uk>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
	<87abryyx6v.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
	<873axoztov.wl%erik.hetzner@ucop.edu>
	<ADD3770F-EDA5-4AE0-8695-5AA1F7F8D630@ashleymoran.me.uk>
	<f4cd26df0709081649r518df9bi38c1996de2df8b21@mail.gmail.com>
	<BE6B1856-0CC1-4440-A58E-FF4A81439F90@ashleymoran.me.uk>
Message-ID: <f4cd26df0709081831y1dd9e493t81bacc1636908985@mail.gmail.com>

On 9/8/07, Ashley Moran <work at ashleymoran.me.uk> wrote:
>
> Interesting!  What about the case of long-running requests, eg file
> uploads, outgoing web service requests or complex calculations?  Do
> you have any of those, and if so, how does it affect the balance of
> event-based vs multithreaded?

Yeah.

File uploads -- the most efficient way to deal with these is really to
run a separate, dedicated mini-app just for them.  If I remember my
history correctly, this is actually what originally gave rize to Merb.
 Ezra needed something fast and lightweight to efficiently handle file
uploads.

In Ruby, a dedicated file upload handler running event based, though,
will still outperform the multithreaded approach. That might make an
interesting topic for a blog post sometime soon....

Regarding accessing web services, it all depends on whether those
accesses are done in a way that block other threads or not.  If they
do not, then heavy web service access would be a place where latencies
could also be captured.

Heavy calculations, on the other hand, are a hands down winner for the
single threaded approach.  There are no latencies to capture -- it's
CPU all the way, so you just need to bring all the resources available
to the process to bear on one problem at a time.


Kirk haines

From work at ashleymoran.me.uk  Sun Sep  9 06:52:24 2007
From: work at ashleymoran.me.uk (Ashley Moran)
Date: Sun, 9 Sep 2007 11:52:24 +0100
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <f4cd26df0709081831y1dd9e493t81bacc1636908985@mail.gmail.com>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
	<87abryyx6v.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
	<873axoztov.wl%erik.hetzner@ucop.edu>
	<ADD3770F-EDA5-4AE0-8695-5AA1F7F8D630@ashleymoran.me.uk>
	<f4cd26df0709081649r518df9bi38c1996de2df8b21@mail.gmail.com>
	<BE6B1856-0CC1-4440-A58E-FF4A81439F90@ashleymoran.me.uk>
	<f4cd26df0709081831y1dd9e493t81bacc1636908985@mail.gmail.com>
Message-ID: <27ACD9D0-84D4-4616-A292-2287F49AAA6A@ashleymoran.me.uk>


On Sep 09, 2007, at 2:31 am, Kirk Haines wrote:

> In Ruby, a dedicated file upload handler running event based, though,
> will still outperform the multithreaded approach. That might make an
> interesting topic for a blog post sometime soon....

Definately!



From neongrau at gmail.com  Mon Sep 10 11:09:26 2007
From: neongrau at gmail.com (Ralf Vitasek)
Date: Mon, 10 Sep 2007 17:09:26 +0200
Subject: [Mongrel] mongrel_rails service on windows incompatible with recent
	ruby builds?
Message-ID: <7adba8e60709100809sa1f19c8g4466f1703db48e1@mail.gmail.com>

i was suffering from a massive memory leak in my application. after
searching and testing for quite a while i finally found that it wasn't
my app that had a leak but the win32ole support that was used by the
ADO driver in sqlserver adapter.

the solution to fix the leak was to install ruby 1.8.5p52 or 1.8.6p36

but sadly as soon i install one of the fixed releases mongrel won't
start as service anymore.

the latest version i was able to run as a service is 1.8.5p35 but that
doesn't have the leak fixed.

"mongrel_rails start" will run the app in dev or production mode on
the console without problems.

when trying to start the service in mmc it fails with the message that
the service was started and that it stopped right away.

when running mongrel_service.exe with the "console" option:
###
C:\informer_rails>"c:/ruby/bin/mongrel_service.exe" console -e development -p 30
00 -a 0.0.0.0 -l "log/mongrel.log" -P "log/mongrel.pid" -c "c:/informer_rails" -
t 0 -r "public" -n 1024
Mongrel Win32 Service, version 0.3.1
(c) 2006 The Mongrel development team.

Starting service 'single' in console mode, please wait...
Service is in running state.
Press Ctrl-C to stop it.
###

i see a ruby.exe for a second in the task manager that seems to die
right away. no log files are created.

i also wonder why it says "Mongrel Win32 Service, version 0.3.1"
because i have 0.3.2 installed. i tried uninstalling and then
reinstalling mongrel, mongrel_service and win32-service without any
luck.

and the error doesn't seem to come from win32-service as i'm able to
run an acts_as_ferret serving DRb without any problems with every ruby
version.

please check the attached servicefb.log and mongrel_service.log
as i can't see anything wrong in those logs.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: servicefb.log
Url: http://rubyforge.org/pipermail/mongrel-users/attachments/20070910/4689b21f/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mongrel_service.log
Url: http://rubyforge.org/pipermail/mongrel-users/attachments/20070910/4689b21f/attachment-0001.pl 

From jan.svitok at gmail.com  Mon Sep 10 12:56:49 2007
From: jan.svitok at gmail.com (Jano Svitok)
Date: Mon, 10 Sep 2007 18:56:49 +0200
Subject: [Mongrel] mongrel_rails service on windows incompatible with
	recent ruby builds?
In-Reply-To: <7adba8e60709100809sa1f19c8g4466f1703db48e1@mail.gmail.com>
References: <7adba8e60709100809sa1f19c8g4466f1703db48e1@mail.gmail.com>
Message-ID: <8d9b3d920709100956v20967799t15f957b6e6a88d56@mail.gmail.com>

On 9/10/07, Ralf Vitasek <neongrau at gmail.com> wrote:
> i also wonder why it says "Mongrel Win32 Service, version 0.3.1"
> because i have 0.3.2 installed. i tried uninstalling and then
> reinstalling mongrel, mongrel_service and win32-service without any
> luck.

It's a bug in the service code:
http://mongrel.rubyforge.org/svn/trunk/projects/mongrel_service/native/mongrel_service.bi

No need to worry.

I've reported to
http://rubyforge.org/tracker/index.php?func=detail&aid=13823&group_id=1306&atid=5145

From erik.hetzner at ucop.edu  Mon Sep 10 14:25:47 2007
From: erik.hetzner at ucop.edu (Erik Hetzner)
Date: Mon, 10 Sep 2007 11:25:47 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <f4cd26df0709081649r518df9bi38c1996de2df8b21@mail.gmail.com>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
	<87abryyx6v.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
	<873axoztov.wl%erik.hetzner@ucop.edu>
	<ADD3770F-EDA5-4AE0-8695-5AA1F7F8D630@ashleymoran.me.uk>
	<f4cd26df0709081649r518df9bi38c1996de2df8b21@mail.gmail.com>
Message-ID: <87wsuyxtqs.wl%erik.hetzner@ucop.edu>

At Sat, 8 Sep 2007 16:49:58 -0700,
"Kirk Haines" <wyhaines at gmail.com> wrote:
> I have two points, here.  First, you can run a considerable number of
> ruby based sites on a single modest server like yours, and they can
> handle a rather impressive traffic load on a single process, depending
> on your framework.  And second, running the same code in an event
> based pipeline versus a multithreaded pipeline invariably gives me
> better peformance in my apps.

Hi Kirk,

Thanks so much for your information here. I?m going to have a closer
look at your event driven mongrel and see what kind of results I can
get out of it for my systems.

best,
Erik Hetzner



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070910/a677a1d0/attachment.bin 

From erik.hetzner at ucop.edu  Mon Sep 10 14:26:04 2007
From: erik.hetzner at ucop.edu (Erik Hetzner)
Date: Mon, 10 Sep 2007 11:26:04 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <f4cd26df0709081649r518df9bi38c1996de2df8b21@mail.gmail.com>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<B220AB03-C117-4537-9E01-C25003C93D6C@brainspl.at>
	<87d4wuz4bk.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
	<87abryyx6v.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
	<873axoztov.wl%erik.hetzner@ucop.edu>
	<ADD3770F-EDA5-4AE0-8695-5AA1F7F8D630@ashleymoran.me.uk>
	<f4cd26df0709081649r518df9bi38c1996de2df8b21@mail.gmail.com>
Message-ID: <87veaixtqb.wl%erik.hetzner@ucop.edu>

At Sat, 8 Sep 2007 16:49:58 -0700,
"Kirk Haines" <wyhaines at gmail.com> wrote:
> I have two points, here.  First, you can run a considerable number of
> ruby based sites on a single modest server like yours, and they can
> handle a rather impressive traffic load on a single process, depending
> on your framework.  And second, running the same code in an event
> based pipeline versus a multithreaded pipeline invariably gives me
> better peformance in my apps.

Hi Kirk,

Thanks so much for your information here. I?m going to have a closer
look at your event driven mongrel and see what kind of results I can
get out of it for my systems.

best,
Erik Hetzner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070910/7ac39b85/attachment-0001.bin 

From wyhaines at gmail.com  Mon Sep 10 14:31:45 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Mon, 10 Sep 2007 11:31:45 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <87veaixtqb.wl%erik.hetzner@ucop.edu>
References: <966599840709071133y20757821rcda9b36a3d73cc4e@mail.gmail.com>
	<f4cd26df0709071232g1c9d7d5eu7ab880838c0df20a@mail.gmail.com>
	<87bqceyzt7.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071350m347fd19fx43f57f670a7f6f83@mail.gmail.com>
	<87abryyx6v.wl%erik.hetzner@ucop.edu>
	<f4cd26df0709071534t50bd0981m683777c958b490ce@mail.gmail.com>
	<873axoztov.wl%erik.hetzner@ucop.edu>
	<ADD3770F-EDA5-4AE0-8695-5AA1F7F8D630@ashleymoran.me.uk>
	<f4cd26df0709081649r518df9bi38c1996de2df8b21@mail.gmail.com>
	<87veaixtqb.wl%erik.hetzner@ucop.edu>
Message-ID: <f4cd26df0709101131k48a43ddaqffb4aebb2424fbfe@mail.gmail.com>

On 9/10/07, Erik Hetzner <erik.hetzner at ucop.edu> wrote:

> Thanks so much for your information here. I'm going to have a closer
> look at your event driven mongrel and see what kind of results I can
> get out of it for my systems.

Cool.  Feel free to email me if you have any questions.  There is a
new release Swiftiply and of evented_mongrel coming just as soon as I
manage to disentangle myself from client facing work I'm getting
buried with.  From a scalability standpoint, the new release of
evented_mongrel enables it to use epoll on platforms that support that
(Linux 2.6.x platforms), instead of select.  I've been saying for two
weeks, now, "This week...."  but...hopefully this week I get to the
light at the end of the tunnel.  ;)


Kirk Haines

From luislavena at gmail.com  Mon Sep 10 15:05:52 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 10 Sep 2007 16:05:52 -0300
Subject: [Mongrel] mongrel_rails service on windows incompatible with
	recent ruby builds?
In-Reply-To: <7adba8e60709100809sa1f19c8g4466f1703db48e1@mail.gmail.com>
References: <7adba8e60709100809sa1f19c8g4466f1703db48e1@mail.gmail.com>
Message-ID: <71166b3b0709101205m57645994rccc9ea6e29957ccc@mail.gmail.com>

On 9/10/07, Ralf Vitasek <neongrau at gmail.com> wrote:
> i was suffering from a massive memory leak in my application. after
> searching and testing for quite a while i finally found that it wasn't
> my app that had a leak but the win32ole support that was used by the
> ADO driver in sqlserver adapter.
>

Ralf, we need to clarify that win32-service, mongrel and even
mongrel_service are quite different stuff from quite different
developers.

> the solution to fix the leak was to install ruby 1.8.5p52 or 1.8.6p36
>
> but sadly as soon i install one of the fixed releases mongrel won't
> start as service anymore.
>
> the latest version i was able to run as a service is 1.8.5p35 but that
> doesn't have the leak fixed.
>
> "mongrel_rails start" will run the app in dev or production mode on
> the console without problems.
>
> when trying to start the service in mmc it fails with the message that
> the service was started and that it stopped right away.
>
> when running mongrel_service.exe with the "console" option:
> ###
> C:\informer_rails>"c:/ruby/bin/mongrel_service.exe" console -e development -p 30
> 00 -a 0.0.0.0 -l "log/mongrel.log" -P "log/mongrel.pid" -c "c:/informer_rails" -
> t 0 -r "public" -n 1024
> Mongrel Win32 Service, version 0.3.1
> (c) 2006 The Mongrel development team.
>
> Starting service 'single' in console mode, please wait...
> Service is in running state.
> Press Ctrl-C to stop it.
> ###
>
> i see a ruby.exe for a second in the task manager that seems to die
> right away. no log files are created.
>
> i also wonder why it says "Mongrel Win32 Service, version 0.3.1"
> because i have 0.3.2 installed. i tried uninstalling and then
> reinstalling mongrel, mongrel_service and win32-service without any
> luck.
>

Version 0.3.1 was a error in the definition headers, my mistake.

> and the error doesn't seem to come from win32-service as i'm able to
> run an acts_as_ferret serving DRb without any problems with every ruby
> version.
>

For the record, the problem with win32-service was not able to serve
Rails application properly, for other ruby tasks, it works fine.

Also, mongrel_service only uses win32-service to install/remove the
service from the SCM, nothing else.

> please check the attached servicefb.log and mongrel_service.log
> as i can't see anything wrong in those logs.
>

>From mongrel_service.log, could you try running this command line?
ruby.exe c:\ruby\bin\mongrel_rails start -e development -p 3000 -a
0.0.0.0 -l log/mongrel.log -P log/mongrel.pid -c c:/informer_rails -t
0 -r public -n 1024

It seems it's trying to run ruby.exe from the PATH, maybe you don't
have it in your environment variables?

Latest version (0.3.2) properly uses C:\ruby\bin\ruby.exe as ruby executable.

For get that fixes, you need to remove and reinstall the service.

Sorry the troubles, and please let us know if that help you :-)

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From casper at lol.dk  Tue Sep 11 03:31:11 2007
From: casper at lol.dk (Casper Fabricius)
Date: Tue, 11 Sep 2007 09:31:11 +0200
Subject: [Mongrel] Fails to restart mongrel cluster after Capistrano
 rollback (PIDs not deleted)
In-Reply-To: <29182826-820D-43A3-A673-9987549D8461@gmail.com>
References: <389A7842-CD02-435F-8B76-D3BE5EB2C4E0@lol.dk>
	<29182826-820D-43A3-A673-9987549D8461@gmail.com>
Message-ID: <C476B4CF-CCEA-45B0-B5DC-C97938D53879@lol.dk>

Thanks Wayne,

That does the trick for me! I simply added this:

   task :rollback do
     stop
     rollback_code
     start
   end

Cheers,
Casper


On 07/09/2007, at 18:15, Wayne E. Seguin wrote:

> On Sep 07, 2007, at 03:30 , Casper Fabricius wrote:
>> Hi,
>>
>> I am deploying a Rails website using Capistrano to a VPS running the
>> site through Apache and Mongrel.
>>
>> 'cap deploy' works fine, and mongrels are restarted. When I execute
>> 'cap deploy:rollback', however, my script fails to restart the
>> mongrels giving this error:
>> !!! PID file tmp/pids/mongrel.5000.pid already exists.  Mongrel could
>> be running already.  Check your log/mongrel.5000.log for errors.
>>
>> I have a hunch that the error is related to the fact that I link / 
>> tmp/
>> pids into the shared directory upon each release in the
>> "after_update" task, but I'm not sure how I end up with this problem,
>> as the old dir I'm rolling back also has the link setup. The mongrels
>> are stopped, but for some reason they don't clean up their PID files,
>> and thus they fail to start again.
>>
>> The full output of the rollback looks like this:
>> http://pastie.caboo.se/94602
>>
>> My deploy.rb looks like this:
>> http://pastie.caboo.se/94600
>>
>> Any help on this issue would be appreciated - thanks!
>>
>> Best regards,
>> Casper Fabricius
>> ________________________________________
>
> Casper,
>
> I'd rewrite the default rollback task to:
> 1. Stop mongrel cluster
> 2. Rollback
> 3. Restart mongrel cluster
>
> Between 2-3 you might also want to ensure that the new (old)  
> "current" directory links the pid directory correctly.
>
>   ~Wayne
>
> s///g
> Wayne E. Seguin
> Sr. Systems Architect & Systems Administrator
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070911/e459260c/attachment.html 

From neongrau at gmail.com  Tue Sep 11 04:39:20 2007
From: neongrau at gmail.com (Ralf Vitasek)
Date: Tue, 11 Sep 2007 10:39:20 +0200
Subject: [Mongrel] mongrel_rails service on windows incompatible with	recent
 ruby builds?
References: 7adba8e60709100809sa1f19c8g4466f1703db48e1@mail.gmail.com
Message-ID: <46E65438.5040307@gmail.com>

hello luis!

thank you very much for your reply.

>/ From mongrel_service.log, could you try running this command line?
/> ruby.exe c:\ruby\bin\mongrel_rails start -e development -p 3000 -a
> 0.0.0.0 -l log/mongrel.log -P log/mongrel.pid -c c:/informer_rails -t
> 0 -r public -n 1024

as i said before starting via "mongrel_rails" works with every ruby version.
but i tested again to be correct. so YES this works!


> It seems it's trying to run ruby.exe from the PATH, maybe you don't
> have it in your environment variables?

ruby is in PATH, as i said before the problem is that ruby.exe starts
but just dies right away when started as a service with the latest patchlevel


> Latest version (0.3.2) properly uses C:\ruby\bin\ruby.exe as ruby executable.
> For get that fixes, you need to remove and reinstall the service.

as i said, already tried uninstalling and reinstalling everything before
(3 times already, please don't ask me to try again, i hardly doubt it'll change anything).


> Sorry the troubles, and please let us know if that help you :-)

no, thanks for trying to walk me through but sorry, that didn't really help :-(



let me summarize the problem again:

the service dies right away, without creating any logs in the rails log dir
when using the latest patchlevel ruby version with the win32ole fix 
( http://rubyforge.org/tracker/?func=detail&atid=1698&aid=7553&group_id=426 ).

running the app via "mongrel_rails start" works with EVERY version.
i just need to copy over the zipped ruby version into c:\ruby to see the problem
1.8.5p35 -> service works
copy 1.8.5p52 into c:\ruby -> doesnt work anymore
copy 1.8.5p35 back into c:\ruby -> works again
copy 1.8.6p36 into c:\ruby -> doesnt work anymore
copy 1.8.6 into c:\ruby -> work again


please try this ruby release:
ftp://ftp.ruby-lang.org/pub/ruby/binaries/mswin32/ruby-1.8.5-p52-i386-mswin32.zip
(this is the latest version with the memory leak fixed)

or in case you're using 1.8.6
ftp://ftp.ruby-lang.org/pub/ruby/binaries/mswin32/ruby-1.8.6-p36-i386-mswin32.zip


and for the record: these are the latest ruby versions that will get the services to run:
ftp://ftp.ruby-lang.org/pub/ruby/binaries/mswin32/ruby-1.8.5-p35-i386-mswin32.zip
or
ftp://ftp.ruby-lang.org/pub/ruby/binaries/mswin32/ruby-1.8.6-i386-mswin32.zip


i hope this clears things more up.

cheers,
ralf


From wayneeseguin at gmail.com  Tue Sep 11 11:08:31 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Tue, 11 Sep 2007 11:08:31 -0400
Subject: [Mongrel] Fails to restart mongrel cluster after Capistrano
	rollback (PIDs not deleted)
In-Reply-To: <C476B4CF-CCEA-45B0-B5DC-C97938D53879@lol.dk>
References: <389A7842-CD02-435F-8B76-D3BE5EB2C4E0@lol.dk>
	<29182826-820D-43A3-A673-9987549D8461@gmail.com>
	<C476B4CF-CCEA-45B0-B5DC-C97938D53879@lol.dk>
Message-ID: <C2A90466-5319-485C-A251-83FA8FC03780@gmail.com>

On Sep 11, 2007, at 03:31 , Casper Fabricius wrote:
> Thanks Wayne,
>
> That does the trick for me! I simply added this:
>
>   task :rollback do
>     stop
>     rollback_code
>     start
>   end
>
> Cheers,
> Casper

Casper,

Excellent! I am glad that worked. Thank you for sharing your solution.

Regards,

   ~Wayne

s///g
Wayne E. Seguin
Sr. Systems Architect & Systems Administrator

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070911/bf156885/attachment-0001.html 

From rogerpack2005 at gmail.com  Tue Sep 11 15:02:17 2007
From: rogerpack2005 at gmail.com (Roger Pack)
Date: Tue, 11 Sep 2007 13:02:17 -0600
Subject: [Mongrel] multi threaded theoretically useful?
Message-ID: <966599840709111202p25c7060dyf91d17f2ec3617d@mail.gmail.com>

So I'd say overall the concensus is that multi-threading might be faster,
depends on where an apps specific latencies end up (notice the might).

Now if I could only come up with a multi-thread safe version of Rails... :)
[ha ha] and pure ruby DB interfaces... :)

Thank you all!
-Roger
Belief is good. http://www.google.com/search?q=free+bible
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070911/dded4681/attachment.html 

From wayneeseguin at gmail.com  Tue Sep 11 15:03:50 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Tue, 11 Sep 2007 15:03:50 -0400
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <966599840709111202p25c7060dyf91d17f2ec3617d@mail.gmail.com>
References: <966599840709111202p25c7060dyf91d17f2ec3617d@mail.gmail.com>
Message-ID: <70E19272-55EA-4620-B58D-77FACE63AAE6@gmail.com>

On Sep 11, 2007, at 15:02 , Roger Pack wrote:
> So I'd say overall the concensus is that multi-threading might be  
> faster, depends on where an apps specific latencies end up (notice  
> the might).
>
> Now if I could only come up with a multi-thread safe version of  
> Rails... :) [ha ha] and pure ruby DB interfaces... :)
>
> Thank you all!
> -Roger

Merb + Sequel :)

   ~Wayne

s///g
Wayne E. Seguin
Sr. Systems Architect & Systems Administrator

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070911/f21441ff/attachment.html 

From work at ashleymoran.me.uk  Tue Sep 11 16:17:55 2007
From: work at ashleymoran.me.uk (Ashley Moran)
Date: Tue, 11 Sep 2007 21:17:55 +0100
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <966599840709111202p25c7060dyf91d17f2ec3617d@mail.gmail.com>
References: <966599840709111202p25c7060dyf91d17f2ec3617d@mail.gmail.com>
Message-ID: <853BADE0-9DA0-4A76-AFCE-582F9CCF0C83@ashleymoran.me.uk>


On Sep 11, 2007, at 8:02 pm, Roger Pack wrote:

> pure ruby DB interfaces... :)


There's a postgres-pr gem, but I don't use it myself.  I tell people  
running Windows they need it, but I always go for the C version  
myself.  If I was in a situation where I had a lot of long-running  
queries, would I be better with the pure Ruby interface from a  
concurrency point of view?

(I'm assuming that as Ruby VMs improve, this will become true in any  
case)

Ashley

From wyhaines at gmail.com  Tue Sep 11 16:40:54 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 11 Sep 2007 13:40:54 -0700
Subject: [Mongrel] multi threaded theoretically useful?
In-Reply-To: <853BADE0-9DA0-4A76-AFCE-582F9CCF0C83@ashleymoran.me.uk>
References: <966599840709111202p25c7060dyf91d17f2ec3617d@mail.gmail.com>
	<853BADE0-9DA0-4A76-AFCE-582F9CCF0C83@ashleymoran.me.uk>
Message-ID: <f4cd26df0709111340g54835ab4r7911108f0f0b8c4f@mail.gmail.com>

On 9/11/07, Ashley Moran <work at ashleymoran.me.uk> wrote:

> There's a postgres-pr gem, but I don't use it myself.  I tell people
> running Windows they need it, but I always go for the C version
> myself.  If I was in a situation where I had a lot of long-running
> queries, would I be better with the pure Ruby interface from a
> concurrency point of view?
>
> (I'm assuming that as Ruby VMs improve, this will become true in any
> case)

It depends.  In _general_, the blocking, C extension based drivers
will still net you better performance, currently, becase they are so
much faster than the pure ruby drivers.  Additionally, because they
are typically just interfaces to the database's own API layer, you
know that they are stable and compatible, while the pure ruby
implementations may not be as stable.

However, if a large number of your queries are very slow, then there
may be room to use some of those wasted cycles by using a
multithreaded deployment.  It's something that one would really have
to benchmark to know for sure for any given use case.


Kirk Haines

From ff at onebeat.com  Tue Sep 11 16:46:51 2007
From: ff at onebeat.com (Farhad Farzaneh)
Date: Tue, 11 Sep 2007 13:46:51 -0700
Subject: [Mongrel] Mongrel instance dies unexpectedly, but cleanly....
Message-ID: <47bbe02f0709111346r7a559d74ha287412d3906fe80@mail.gmail.com>

Hi,

I have a two instance mongrel cluster, running behind apache
mod_proxy_balancer on a linux VPS.  Mongrel_cluster is 1.01, mongrel is
v1.02, rails 1.2.3, ruby 1.8.6. I seem to have enough memory.

About 2 minutes after I start the cluster, one of my instances dies - it
could be either one.  The log file indicates that it received a TERM
signal.  The instance does die cleanly, removing its pid file.  But I didn't
give it a TERM signal, and I don't think I'm running any services that would
do so.

My searches haven't been very fruitful.  Any ideas would be appreciated.

Thanks

Farhad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070911/82052ed2/attachment.html 

From wayneeseguin at gmail.com  Tue Sep 11 17:05:14 2007
From: wayneeseguin at gmail.com (Wayne E. Seguin)
Date: Tue, 11 Sep 2007 17:05:14 -0400
Subject: [Mongrel] Mongrel instance dies unexpectedly, but cleanly....
In-Reply-To: <47bbe02f0709111346r7a559d74ha287412d3906fe80@mail.gmail.com>
References: <47bbe02f0709111346r7a559d74ha287412d3906fe80@mail.gmail.com>
Message-ID: <6F7B4B03-3BBD-431C-835E-9F649E3920F4@gmail.com>

On Sep 11, 2007, at 16:46 , Farhad Farzaneh wrote:
> Hi,
>
> I have a two instance mongrel cluster, running behind apache  
> mod_proxy_balancer on a linux VPS.  Mongrel_cluster is 1.01,  
> mongrel is v1.02, rails 1.2.3, ruby 1.8.6. I seem to have enough  
> memory.
>
> About 2 minutes after I start the cluster, one of my instances dies  
> - it could be either one.  The log file indicates that it received  
> a TERM signal.  The instance does die cleanly, removing its pid  
> file.  But I didn't give it a TERM signal, and I don't think I'm  
> running any services that would do so.
>
> My searches haven't been very fruitful.  Any ideas would be  
> appreciated.
>
> Thanks
>
> Farhad

Farhad,

You're running on a shared server and when you startup the second  
mongrel more than likely the VPS system is sending the second Mongrel  
a kill signal because you've gone over your resource allocation.

   ~Wayne

s///g
Wayne E. Seguin
Sr. Systems Architect & Systems Administrator

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20070911/b00e5743/attachment.html 

From luislavena at gmail.com  Tue Sep 11 17:28:30 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 11 Sep 2007 18:28:30 -0300
Subject: [Mongrel] mongrel_rails service on windows incompatible with
	recent ruby builds?
In-Reply-To: <46E65438.5040307@gmail.com>
References: <46E65438.5040307@gmail.com>
Message-ID: <71166b3b0709111428v43ad1540m8d89f17b6b4e27bf@mail.gmail.com>

On 9/11/07, Ralf Vitasek <neongrau at gmail.com> wrote:
> hello luis!
>
> thank you very much for your reply.
>
> >/ From mongrel_service.log, could you try running this command line?
> /> ruby.exe c:\ruby\bin\mongrel_rails start -e development -p 3000 -a
> > 0.0.0.0 -l log/mongrel.log -P log/mongrel.pid -c c:/informer_rails -t
> > 0 -r public -n 1024
>
> as i said before starting via "mongrel_rails" works with every ruby version.
> but i tested again to be correct. so YES this works!
>
>
> > It seems it's trying to run ruby.exe from the PATH, maybe you don't
> > have it in your environment variables?
>
> ruby is in PATH, as i said before the problem is that ruby.exe starts
> but just dies right away when started as a service with the latest patchlevel
>

So far, everything is ok in the ruby land...

> > Latest version (0.3.2) properly uses C:\ruby\bin\ruby.exe as ruby executable.
> > For get that fixes, you need to remove and reinstall the service.
>
> as i said, already tried uninstalling and reinstalling everything before
> (3 times already, please don't ask me to try again, i hardly doubt it'll change anything).
>

No problem, I'll not ;-)


>
> let me summarize the problem again:
>
> the service dies right away, without creating any logs in the rails log dir
> when using the latest patchlevel ruby version with the win32ole fix
> ( http://rubyforge.org/tracker/?func=detail&atid=1698&aid=7553&group_id=426 ).
>
> running the app via "mongrel_rails start" works with EVERY version.
> i just need to copy over the zipped ruby version into c:\ruby to see the problem
> 1.8.5p35 -> service works
> copy 1.8.5p52 into c:\ruby -> doesnt work anymore
> copy 1.8.5p35 back into c:\ruby -> works again
> copy 1.8.6p36 into c:\ruby -> doesnt work anymore
> copy 1.8.6 into c:\ruby -> work again
>

Mmm, you're using win32ole to connect to ADO driver, right?

Maybe there is a problem due the non-impersonation of the service,
since by default it will run as SYSTEM, and not the user you're logged
in.

This often bring problems when dealing with ActiveX/OLE and the proper
creation of instances of these objects.

>
> please try this ruby releas