From jnicoll at goldnoteexpress.com  Sat Sep  1 20:22:54 2007
From: jnicoll at goldnoteexpress.com (Jeremy Nicoll)
Date: Sat, 01 Sep 2007 17:22:54 -0700
Subject: [Swiftiply-users] Crashing of server on HEAD request (I think...)
Message-ID: <46DA025E.7050105@goldnoteexpress.com>

Hello,
    I recently visited 
http://www.websiteoptimization.com/services/analyze/wso.php to see how 
big my site was.  I was thoroughly surprised to find that after doing 
so, my site was only 13KB in size (the size of the 503 error page) and 
that the server was unavailable.  I did confirm that it crashed every 
time that attempted to access the site through the optimization site.  
Here is my setup:

Apache 2.2 <- Swiftiply 6.1 -> swiftiply_mongrel_rails (no patches)

Here is an excerpt from my Apache access log:

72.51.34.164 - - [01/Sep/2007:23:58:50 +0000] "HEAD / HTTP/1.1" 200 -
72.51.34.164 - - [01/Sep/2007:23:58:51 +0000] "HEAD / HTTP/1.1" 200 -
72.51.34.164 - - [01/Sep/2007:23:58:51 +0000] "GET / HTTP/1.1" 503 18


Here is the setup I have for the site in Apache:

<VirtualHost *:80>
        ServerName somesite.com
        ServerAlias wwwsomesite.com
        ProxyPass         /  http://127.0.0.1:88/
        ProxyPassReverse  /  http://127.0.0.1:88/
</VirtualHost>


(If you want I can send the original site name to the maintainer or 
anyone else who wants to help - I don't want random people crashing my site)

My swiftiply.conf:

cluster_address: 127.0.0.1
cluster_port: 88
daemonize: true
timeout: 3
map:
   - incoming:
     - somesite.com
     - www.somesite.com
     outgoing: 127.0.0.1:4000
     default: true
     redeployable: true


And finally my mongrel_cluster.yml file:

--- 
cwd: /home/mitrob/rails/adamsfirst
log_file: log/mongrel.log
port: "4000"address: 127.0.0.1
pid_file: tmp/pids/mongrel.pid
servers: 2



The way I currently start up swiftiply_mongrel_rails is in the directory 
of the rails app with the parameters of -n2 -d

TIA,
Jeremy


   



From jeremy at hinegardner.org  Tue Sep  4 12:42:32 2007
From: jeremy at hinegardner.org (Jeremy Hinegardner)
Date: Tue, 4 Sep 2007 10:42:32 -0600
Subject: [Swiftiply-users] swiftiply architecture
Message-ID: <20070904164232.GG20103@hinegardner.org>

Hi all,

I've read through all the documentation and mailing list archives for
swiftiply, and I haven't seen this mentioned specifically.  Swiftiply
only dispatches a single request to each mongrel, correct?  

We are currently using apache with mod_proxy_balance -> mongrels and
apache will stack up requests in a mongrel that is processing a poorly
performing request.  We would like to avoid this situation, and even
more, be able to find these poorly performing requests when they happen.  

Maybe this is partly feature checking and feature requesting :-).  

In swiftiply's case does it queue up the requests internally and only feeds
them to mongrels that are available for processing?  Also, is there
something in the works for swiftiply to have it dump performance
information about the requests it is dispatching?  

URL statistics possibly? Something along the lines of average response
times by request.  This would help find those requests that all of a
suddent start performing poorly.  Or maybe I'm missing out on something
to find those already.

Thanks for all the work on swiftiply by the way, and analogger, I'm
probably going to be converting several apps to use Analogger.

enjoy,

-jeremy

-- 
========================================================================
 Jeremy Hinegardner                              jeremy at hinegardner.org 


From ammon.christiansen at gmail.com  Tue Sep  4 12:46:54 2007
From: ammon.christiansen at gmail.com (Ammon Christiansen)
Date: Tue, 4 Sep 2007 09:46:54 -0700
Subject: [Swiftiply-users] swiftiply architecture
In-Reply-To: <20070904164232.GG20103@hinegardner.org>
References: <20070904164232.GG20103@hinegardner.org>
Message-ID: <5dc7d1c20709040946g493eb0efsad07f87f1100015d@mail.gmail.com>

Jeremy,
very good questions.  I hope someone on the list can answer them because I'm
interested in hearing answers to how it balances between connected clients -
round robin or load-based...

The statistics, especially per request sound good.  I'm not sure if
swiftiply is the exact right place to measure that or in a rails log file or
what...

On 9/4/07, Jeremy Hinegardner <jeremy at hinegardner.org> wrote:
>
> Hi all,
>
> I've read through all the documentation and mailing list archives for
> swiftiply, and I haven't seen this mentioned specifically.  Swiftiply
> only dispatches a single request to each mongrel, correct?
>
> We are currently using apache with mod_proxy_balance -> mongrels and
> apache will stack up requests in a mongrel that is processing a poorly
> performing request.  We would like to avoid this situation, and even
> more, be able to find these poorly performing requests when they happen.
>
> Maybe this is partly feature checking and feature requesting :-).
>
> In swiftiply's case does it queue up the requests internally and only
> feeds
> them to mongrels that are available for processing?  Also, is there
> something in the works for swiftiply to have it dump performance
> information about the requests it is dispatching?
>
> URL statistics possibly? Something along the lines of average response
> times by request.  This would help find those requests that all of a
> suddent start performing poorly.  Or maybe I'm missing out on something
> to find those already.
>
> Thanks for all the work on swiftiply by the way, and analogger, I'm
> probably going to be converting several apps to use Analogger.
>
> enjoy,
>
> -jeremy
>
> --
> ========================================================================
> Jeremy Hinegardner                              jeremy at hinegardner.org
>
> _______________________________________________
> Swiftiply-users mailing list
> Swiftiply-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/swiftiply-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/swiftiply-users/attachments/20070904/eec5d23f/attachment.html 

From ezmobius at gmail.com  Tue Sep  4 12:54:23 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Tue, 4 Sep 2007 09:54:23 -0700
Subject: [Swiftiply-users] swiftiply architecture
In-Reply-To: <20070904164232.GG20103@hinegardner.org>
References: <20070904164232.GG20103@hinegardner.org>
Message-ID: <5B2CEA77-59EE-4175-A5A2-E88173264D42@gmail.com>


On Sep 4, 2007, at 9:42 AM, Jeremy Hinegardner wrote:

> Hi all,
>
> I've read through all the documentation and mailing list archives for
> swiftiply, and I haven't seen this mentioned specifically.  Swiftiply
> only dispatches a single request to each mongrel, correct?
>
> We are currently using apache with mod_proxy_balance -> mongrels and
> apache will stack up requests in a mongrel that is processing a poorly
> performing request.  We would like to avoid this situation, and even
> more, be able to find these poorly performing requests when they  
> happen.
>
> Maybe this is partly feature checking and feature requesting :-).
>
> In swiftiply's case does it queue up the requests internally and  
> only feeds
> them to mongrels that are available for processing?  Also, is there
> something in the works for swiftiply to have it dump performance
> information about the requests it is dispatching?
>
> URL statistics possibly? Something along the lines of average response
> times by request.  This would help find those requests that all of a
> suddent start performing poorly.  Or maybe I'm missing out on  
> something
> to find those already.
>
> Thanks for all the work on swiftiply by the way, and analogger, I'm
> probably going to be converting several apps to use Analogger.
>
> enjoy,
>
> -jeremy
>


	Yeah swiftiply only allows one request to be processed per backend  
at a time. It queues requests internally and waits for an open  
mongrel before dispatching. The queing is very efficient since its in  
an event machine event loop.

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



From jeremy at hinegardner.org  Tue Sep  4 13:12:08 2007
From: jeremy at hinegardner.org (Jeremy Hinegardner)
Date: Tue, 4 Sep 2007 11:12:08 -0600
Subject: [Swiftiply-users] swiftiply architecture
In-Reply-To: <5B2CEA77-59EE-4175-A5A2-E88173264D42@gmail.com>
References: <20070904164232.GG20103@hinegardner.org>
	<5B2CEA77-59EE-4175-A5A2-E88173264D42@gmail.com>
Message-ID: <20070904171208.GH20103@hinegardner.org>

On Tue, Sep 04, 2007 at 09:54:23AM -0700, Ezra Zygmuntowicz wrote:
> 
> On Sep 4, 2007, at 9:42 AM, Jeremy Hinegardner wrote:
[...]

> >
> >In swiftiply's case does it queue up the requests internally and
> >only feeds them to mongrels that are available for processing?  Also,
> >is there something in the works for swiftiply to have it dump
> >performance information about the requests it is dispatching?

[...]

> 	Yeah swiftiply only allows one request to be processed per backend  
> at a time. It queues requests internally and waits for an open  
> mongrel before dispatching. The queing is very efficient since its in  
> an event machine event loop.

Thanks Ezra, that clears things up a bit.  Oh, by the way, is Swiftiply
going to make it into the book?  I'm enjoying what's in the Beta so far.

enjoy,

-jeremy


-- 
========================================================================
 Jeremy Hinegardner                              jeremy at hinegardner.org 


From wyhaines at gmail.com  Tue Sep  4 13:22:32 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Tue, 4 Sep 2007 10:22:32 -0700
Subject: [Swiftiply-users] swiftiply architecture
In-Reply-To: <20070904164232.GG20103@hinegardner.org>
References: <20070904164232.GG20103@hinegardner.org>
Message-ID: <f4cd26df0709041022k64eeabf9k6e7100e3c5a9d67c@mail.gmail.com>

On 9/4/07, Jeremy Hinegardner <jeremy at hinegardner.org> wrote:

> I've read through all the documentation and mailing list archives for
> swiftiply, and I haven't seen this mentioned specifically.  Swiftiply
> only dispatches a single request to each mongrel, correct?

Correct.

> We are currently using apache with mod_proxy_balance -> mongrels and
> apache will stack up requests in a mongrel that is processing a poorly
> performing request.  We would like to avoid this situation, and even
> more, be able to find these poorly performing requests when they happen.
>
> Maybe this is partly feature checking and feature requesting :-).
>
> In swiftiply's case does it queue up the requests internally and only feeds
> them to mongrels that are available for processing?  Also, is there
> something in the works for swiftiply to have it dump performance
> information about the requests it is dispatching?

Here's the request handling flow:

1) Request comes into Swiftiply from a browser.
2) Request is minimally parsed for some key bits of information, and
then matched to an "incoming" section.
3) If static file handling is enabled, check for a static file that
will fullfill the request; if found, serve that.
4) If not found, check to see if there is a backend processin queue
waiting for work; if there is, start feeding request to that backend.
5) If not, request goes into a queue to wait for a backend to handle it.
6) When a backend gets a request, it is removed from the queue of
available servers.  Thus, a server that is handling a request may not
receive another until it finishes with the first.
7) When the response is returned, in full, from the backend, it is
added again to the queue, and a check is made to see if there are
clients waiting to be serviced.  If there are, it pops the first one
in the queue off for handling.
8) There is a periodic loop that checks waiting requests to see if any
have been waiting too long for handling.  Those that have receive a
503 Server Unavailable response.  "Too long" is a configurable number
of seconds.

So, it is round robin only in the sense that each server in queue
receives a request in order, one after the next.  However, if a
process is handling a slow request, it will simply be out of the queue
for longer, and the fast requests will go to other processes.  The net
result is that when under load, load balancing automatically falls out
of this algorithm.

> URL statistics possibly? Something along the lines of average response
> times by request.  This would help find those requests that all of a
> suddent start performing poorly.  Or maybe I'm missing out on something
> to find those already.

Hmmm.  I am adding some statistics gathering to swiftiply, if I were
to add per-url stats, it would have to be an option turned on by
configuration only.  Can't Rails log how long it takes to generate a
response, though?  I do that in IOWA, and I thought Rails could do
something similar?  So, in my log files, I have this:


2007/09/04 19:12:26|swiftiply.com|info|Tue Sep 04 19:12:27 +0200 2007
(0.0/0.0008) :: /rss.xml "200 OK" 3566B
2007/09/04 19:13:17|swiftiply.com|info|Tue Sep 04 19:13:18 +0200 2007
(0.0/0.001617) :: /index.html "200 OK" 3468B
2007/09/04 19:13:18|swiftiply.com|info|Tue Sep 04 19:13:18 +0200 2007
(0.0/0.000966) :: /styles.css "200 OK" 3332B
2007/09/04 19:13:24|swiftiply.com|info|Tue Sep 04 19:13:24 +0200 2007
(0.0/0.001215) :: /download.html "200 OK" 3445B
2007/09/04 19:13:24|swiftiply.com|info|Tue Sep 04 19:13:25 +0200 2007
(0.0/0.000792) :: /styles.css "304 Not Modified" 0B

So I can look at my logfile and see how quickly or slowly I am rendering pages.

That sort of thing from Swiftiply itself, as some sort of aggregate
log, is possible, but it doesn't fill me with warm fuzzies as I am not
it's the best place for it.

> Thanks for all the work on swiftiply by the way, and analogger, I'm
> probably going to be converting several apps to use Analogger.

Thanks.

I'm still working hard on getting my now seriously overdue 0.6.2
release out, and there will be an Analogger release after that.  Just
ping me directly if you have any Analogger questions.


Kirk Haines

From jeremy at hinegardner.org  Tue Sep  4 17:21:27 2007
From: jeremy at hinegardner.org (Jeremy Hinegardner)
Date: Tue, 4 Sep 2007 15:21:27 -0600
Subject: [Swiftiply-users] swiftiply architecture
In-Reply-To: <f4cd26df0709041022k64eeabf9k6e7100e3c5a9d67c@mail.gmail.com>
References: <20070904164232.GG20103@hinegardner.org>
	<f4cd26df0709041022k64eeabf9k6e7100e3c5a9d67c@mail.gmail.com>
Message-ID: <20070904212127.GA25014@hinegardner.org>

On Tue, Sep 04, 2007 at 10:22:32AM -0700, Kirk Haines wrote:
> On 9/4/07, Jeremy Hinegardner <jeremy at hinegardner.org> wrote:
> 
> Here's the request handling flow:
> 
> 1) Request comes into Swiftiply from a browser.
> 2) Request is minimally parsed for some key bits of information, and
> then matched to an "incoming" section.
> 3) If static file handling is enabled, check for a static file that
> will fullfill the request; if found, serve that.
> 4) If not found, check to see if there is a backend processin queue
> waiting for work; if there is, start feeding request to that backend.
> 5) If not, request goes into a queue to wait for a backend to handle it.
> 6) When a backend gets a request, it is removed from the queue of
> available servers.  Thus, a server that is handling a request may not
> receive another until it finishes with the first.
> 7) When the response is returned, in full, from the backend, it is
> added again to the queue, and a check is made to see if there are
> clients waiting to be serviced.  If there are, it pops the first one
> in the queue off for handling.
> 8) There is a periodic loop that checks waiting requests to see if any
> have been waiting too long for handling.  Those that have receive a
> 503 Server Unavailable response.  "Too long" is a configurable number
> of seconds.
> 
> So, it is round robin only in the sense that each server in queue
> receives a request in order, one after the next.  However, if a
> process is handling a slow request, it will simply be out of the queue
> for longer, and the fast requests will go to other processes.  The net
> result is that when under load, load balancing automatically falls out
> of this algorithm.

Perfect.  Thanks for the information.

> > URL statistics possibly? Something along the lines of average response
> > times by request.  This would help find those requests that all of a
> > suddent start performing poorly.  Or maybe I'm missing out on something
> > to find those already.
> 
> Hmmm.  I am adding some statistics gathering to swiftiply, if I were
> to add per-url stats, it would have to be an option turned on by
> configuration only.  Can't Rails log how long it takes to generate a
> response, though?  I do that in IOWA, and I thought Rails could do
> something similar?  So, in my log files, I have this:
> 
> 
> 2007/09/04 19:12:26|swiftiply.com|info|Tue Sep 04 19:12:27 +0200 2007
> (0.0/0.0008) :: /rss.xml "200 OK" 3566B
> 2007/09/04 19:13:17|swiftiply.com|info|Tue Sep 04 19:13:18 +0200 2007
> (0.0/0.001617) :: /index.html "200 OK" 3468B
> 2007/09/04 19:13:18|swiftiply.com|info|Tue Sep 04 19:13:18 +0200 2007
> (0.0/0.000966) :: /styles.css "200 OK" 3332B
> 2007/09/04 19:13:24|swiftiply.com|info|Tue Sep 04 19:13:24 +0200 2007
> (0.0/0.001215) :: /download.html "200 OK" 3445B
> 2007/09/04 19:13:24|swiftiply.com|info|Tue Sep 04 19:13:25 +0200 2007
> (0.0/0.000792) :: /styles.css "304 Not Modified" 0B
> 
> So I can look at my logfile and see how quickly or slowly I am rendering pages.
> 
> That sort of thing from Swiftiply itself, as some sort of aggregate
> log, is possible, but it doesn't fill me with warm fuzzies as I am not
> it's the best place for it.

Most likely it wouldn't be a good place for it in swiftiply, I was just
thinking off the cuff there.    A good aggreagate place for this is
necessary somewhere, still not quite sure where it would best fit for my
situation.  Just pondering...

thanks again,

-jeremy

-- 
========================================================================
 Jeremy Hinegardner                              jeremy at hinegardner.org 


From jnicoll at gnexp.com  Sat Sep  8 10:48:29 2007
From: jnicoll at gnexp.com (Jeremy Nicoll)
Date: Sat, 08 Sep 2007 08:48:29 -0600
Subject: [Swiftiply-users] Preventing others from connecting to Swiftiply
	backend
Message-ID: <46E2B63D.5070306@gnexp.com>

I am not at this point yet - but I was wondering when you have multiple 
machines that are connecting to a swiftiply instance on one machine, how 
does one go about preventing others from connecting to the same port and 
impersonating one's site? 

--
Jeremy Nicoll

From wyhaines at gmail.com  Sat Sep  8 11:54:10 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Sat, 8 Sep 2007 08:54:10 -0700
Subject: [Swiftiply-users] Preventing others from connecting to
	Swiftiply backend
In-Reply-To: <46E2B63D.5070306@gnexp.com>
References: <46E2B63D.5070306@gnexp.com>
Message-ID: <f4cd26df0709080854i558955f9m129c574b13691c33@mail.gmail.com>

On 9/8/07, Jeremy Nicoll <jnicoll at gnexp.com> wrote:
> I am not at this point yet - but I was wondering when you have multiple
> machines that are connecting to a swiftiply instance on one machine, how
> does one go about preventing others from connecting to the same port and
> impersonating one's site?

A security key.

map:
  - incoming:
    - mysite.com
    - www.mysite.com
    key: cb14dd0c0184f246ee82b3070cc0571f93769c1ab74220a63131f6308751e322
    outgoing: 127.0.0.1:10000
    default: true
    docroot: /usr/local/htdocs/swiftcore.org/doc


Anything trying to connect to Swiftiply to serve mysite.com or
www.mysite.com has to present the correct security key, or their
connection will be unceremoniously dropped.

IOWA deals with this just dandy, and swiftiplied_mongrel is setup to
deal with this in it's protocol handler.

All is not flowers and butterflies, though, in Mongrel-land.  The
reason is this:  The security key needs to come from the application's
configuration, and I haven't conceived of any framework-neutral way to
get that security key from the application layer into the Mongrel
layer so that it is available to the swiftiplied_mongrel code.

I was working on this before I pushed 0.6.1, but decided I needed to
get it released, so left this issue unsolved.  I fear that it may take
framework specific code to enable a seamless delivery of the security
key from the application's configuration into the innards of Mongrel.

If someone wants to take a closer look at this issue and send me
patches, I'd love to have them.  I've been weighed down by the chains
and shackles of some very high priority client work over the last
week, and don't see that ending for a few more days, and I have other
work I am trying to finish for Swiftiply, so I don't see myself coming
back to this issue anytime really soon.


Kirk Haines

From wyhaines at gmail.com  Sun Sep  9 10:31:56 2007
From: wyhaines at gmail.com (Kirk Haines)
Date: Sun,  9 Sep 2007 15:31:56 +0100 (BST)
Subject: [Swiftiply-users] Invitation from Kirk Haines (wyhaines@gmail.com)
Message-ID: <20070909143156.224772B0C15@mail2.quechup.com>

KirkHaines (wyhaines 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/aT0wMDAwMDAwMDEwMDM5NTI4JmM9MTAyNTU2 to
accept Kirk'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 Kirk and his friends today:
http://quechup.com/join.php/aT0wMDAwMDAwMDEwMDM5NTI4JmM9MTAyNTU2
------------------------------------------------------------------
You received this because Kirk Haines (wyhaines at gmail.com) knows and
agreed to invite you. You will only receive one invitation from
wyhaines 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/ZW09c3dpZnRpcGx5LXVzZXJzQHJ1Ynlmb3JnZS5vcmc%3D
if you do not wish to receive any more emails from Quechup.
------------------------------------------------------------------
Copyright Quechup.com 2007.
------------------------------------
Go to
http://quechup.com/emailunsubscribe.php/ZW09c3dpZnRpcGx5LXVzZXJzQHJ1Ynlmb3JnZS5vcmc%3D
if you do not wish to receive any more emails from Quechup
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/swiftiply-users/attachments/20070909/db3515fc/attachment-0001.html 

From jnicoll at gnexp.com  Sun Sep  9 12:59:00 2007
From: jnicoll at gnexp.com (Jeremy Nicoll)
Date: Sun, 09 Sep 2007 10:59:00 -0600
Subject: [Swiftiply-users] Preventing others from connecting to
 Swiftiply backend
In-Reply-To: <f4cd26df0709080854i558955f9m129c574b13691c33@mail.gmail.com>
References: <46E2B63D.5070306@gnexp.com>
	<f4cd26df0709080854i558955f9m129c574b13691c33@mail.gmail.com>
Message-ID: <46E42654.6000001@gnexp.com>

Kirk,
    I totally understand the dilemma.  I am fairly new to ruby and have 
begun to dig around in the code.  Do you have any suggestions on where 
to start with this?

Kirk Haines wrote:
> On 9/8/07, Jeremy Nicoll <jnicoll at gnexp.com> wrote:
>   
>> I am not at this point yet - but I was wondering when you have multiple
>> machines that are connecting to a swiftiply instance on one machine, how
>> does one go about preventing others from connecting to the same port and
>> impersonating one's site?
>>     
>
> A security key.
>
> map:
>   - incoming:
>     - mysite.com
>     - www.mysite.com
>     key: cb14dd0c0184f246ee82b3070cc0571f93769c1ab74220a63131f6308751e322
>     outgoing: 127.0.0.1:10000
>     default: true
>     docroot: /usr/local/htdocs/swiftcore.org/doc
>
>
> Anything trying to connect to Swiftiply to serve mysite.com or
> www.mysite.com has to present the correct security key, or their
> connection will be unceremoniously dropped.
>
> IOWA deals with this just dandy, and swiftiplied_mongrel is setup to
> deal with this in it's protocol handler.
>
> All is not flowers and butterflies, though, in Mongrel-land.  The
> reason is this:  The security key needs to come from the application's
> configuration, and I haven't conceived of any framework-neutral way to
> get that security key from the application layer into the Mongrel
> layer so that it is available to the swiftiplied_mongrel code.
>
> I was working on this before I pushed 0.6.1, but decided I needed to
> get it released, so left this issue unsolved.  I fear that it may take
> framework specific code to enable a seamless delivery of the security
> key from the application's configuration into the innards of Mongrel.
>
> If someone wants to take a closer look at this issue and send me
> patches, I'd love to have them.  I've been weighed down by the chains
> and shackles of some very high priority client work over the last
> week, and don't see that ending for a few more days, and I have other
> work I am trying to finish for Swiftiply, so I don't see myself coming
> back to this issue anytime really soon.
>
>
> Kirk Haines
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/swiftiply-users/attachments/20070909/d8a820ca/attachment.html 

From b.candler at pobox.com  Wed Sep 12 08:20:24 2007
From: b.candler at pobox.com (b.candler at pobox.com)
Date: Wed, 12 Sep 2007 13:20:24 +0100
Subject: [Swiftiply-users] swiftiply architecture
Message-ID: <E1IVRCi-000E10-MH@mk-webmail-1.b2b.uk.tiscali.com>

> 6) When a backend gets a request, it is removed rom the queue of
> available servers.  Thus, a server that is handling a request may not
> receive another until it finishes with the first.

Thank you for this very clear explanation. I was going to ask the same 
myself. 

This means that Swiftiply is extremely well suited to Rails. One problem I 
found with an Apache mod_proxy solution was that if one worker process was 
handling a very long-running request, other requests would still get queued 
for the same process and therefore suffer a very poor response time. 

However it might not be so well suited for something like Merb where you may 
wish to receive multiple HTTP requests concurrently, for example when 
receiving a lot of file uploads. 

I believe that raw HTTP/1.1 doesn't allow for overlapping asynchronous 
requests and responses (only straightforward pipelining, where the responses 
must come out in the same order as the requests). But maybe a simpler 
solution would be for a "swiftiplied" mongrel to be able to open N 
simultaneous TCP connections back to the proxy, e.g. 

  env SWIFT=4 merb -p 30000 

Regards, 

Brian. 

P.S. Can I make one tiny patch request please? 

 --- swiftiply-0.6.1/bin/mongrel_rails.orig      2007-09-09 
19:54:07.000000000 +0100
+++ swiftiply-0.6.1/bin/mongrel_rails   2007-09-12 13:17:23.000000000 +0100
@@ -12,7 +12,7 @@
  puts "Using Evented Mongrel"
elsif ENV['SWIFT']
  require 'swiftcore/swiftiplied_mongrel'
 -  puts "Using Evented Mongrel"
+  puts "Using Swiftiplied Mongrel"
else
 require 'mongrel'
end 

From ammon.christiansen at gmail.com  Wed Sep 12 14:58:03 2007
From: ammon.christiansen at gmail.com (Ammon Christiansen)
Date: Wed, 12 Sep 2007 11:58:03 -0700
Subject: [Swiftiply-users] swiftiply architecture
In-Reply-To: <E1IVXBX-000ASB-LF@mk-webmail-2.b2b.uk.tiscali.com>
References: <E1IVRCi-000E10-MH@mk-webmail-1.b2b.uk.tiscali.com>
	<5dc7d1c20709120806v78f8a72fnd3aa72e686d8edc4@mail.gmail.com>
	<E1IVXBX-000ASB-LF@mk-webmail-2.b2b.uk.tiscali.com>
Message-ID: <5dc7d1c20709121158t1eed60d4y1bc12d79ae745019@mail.gmail.com>

Ok, I get what you're asking now and why it is important (pipelining and
memory footprint of 25 vs 100 mongrels).  You want the SWIFT=n number before
merb -p <port> to specify the number of threads that you want merb to use or
more specifically the number of TCP connections you want it to open to the
outgoing swiftiply port.

I don't know whether each merb thread opens up a different TCP connection.
I suppose only the mongrel itself opens the TCP connection.  If you find out
which way it is, let me know.

On 9/12/07, b.candler at pobox.com <b.candler at pobox.com> wrote:
>
> Ammon Christiansen writes:
>
> > If you intended to start 4 swiftiplied merb mongrels with this
> > env SWIFT=4 merb -p 30000
> > then that isn't right.  SWIFT=1 just assigns it a value that evaluates
> to
> > true to distinguish between evented and swiftiplied and default.
>
> Indeed, that's how it works at present.
>
> > The right way to start 4 merb mongrels at once is to use the -c 4 switch
> If
> > I remember correctly.  Of course if you want them to all connect to the
> > outgoing swiftiply port, you still need the env SWIFT=1.
>
> I don't want to start four merb mongrels. I want to start one merb
> mongrel,
> which can process four HTTP requests concurrently (in four threads) which
> are proxied to it by swiftiply. As I understand it, this would mean one
> mongrel process opening four TCP connections to the swiftiply proxy.
>
> Of course, if there were only a single mongrel process handling everything
> then swiftiply wouldn't be needed at all. I'm thinking about scalability:
> for example, if I start 25 merb/mongrel processes each handling 4
> connections then I can handle 100 concurrent connections. This can be
> distributed across multiple processors or physical servers, unlike one
> merb
> process with 100 threads. Having 25 merb processes (each with 4 threads)
> uses much less RAM than 100 merb processes (each with 1 thread)
>
> This is particularly beneficial if requests take a long time to receive,
> but
> a relatively short time to process (such as a 10MB file upload)
>
> > Not sure if I understand whether you're talking about http in general or
> > mongrel queueing up rails requests, but here goes:
> >
> > As for HTTP requests a, b, and c being sent to the server in that order,
> > there is nothing that says that they have to come back in the same
> order.
> > if a takes a long time, b could come back first.
>
> Not if they come down the same TCP connection. RFC 2616 is explicit on
> this
> point:
>
> "8.1.2.2 Pipelining
>
>   A client that supports persistent connections MAY "pipeline" its
>   requests (i.e., send multiple requests without waiting for each
>   response). A server MUST send its responses to those requests in the
>   same order that the requests were received."
>
> > Consider the example of a
> > large high-res banner ad (dynamic or static) being a and a small rounded
> > corner image b.  b's response could come back before a's.  requests are
> > really independent creatures.
>
> If the client opens multiple TCP connections, yes.
>
> So to get the same effect with swiftiply + merb/mongrel, the merb/mongrel
> process would have to open multiple TCP connections to the swiftiply
> proxy,
> so that the proxy could send multiple overlapping requests to it. That's
> the
> point I was trying to make originally.
>
> Sorry if I wasn't clear before.
>
> Regards,
>
> Brian.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/swiftiply-users/attachments/20070912/9603ae71/attachment.html 

From jnicoll at gnexp.com  Thu Sep 13 12:21:36 2007
From: jnicoll at gnexp.com (Jeremy Nicoll)
Date: Thu, 13 Sep 2007 10:21:36 -0600
Subject: [Swiftiply-users] Preventing others from connecting to
 Swiftiply backend
In-Reply-To: <f4cd26df0709080854i558955f9m129c574b13691c33@mail.gmail.com>
References: <46E2B63D.5070306@gnexp.com>
	<f4cd26df0709080854i558955f9m129c574b13691c33@mail.gmail.com>
Message-ID: <46E96390.8010606@gnexp.com>

    Why not just make it a command line argument or part of a 
configuration file for mongrel itself?  That way there is no worry about 
the framework being used.  Options have to be specified anyway on where 
the application is,  and so it really would not be taking the logic of 
mongrel any further than what it is now.

Kirk Haines wrote:
> On 9/8/07, Jeremy Nicoll <jnicoll at gnexp.com> wrote:
>   
>> I am not at this point yet - but I was wondering when you have multiple
>> machines that are connecting to a swiftiply instance on one machine, how
>> does one go about preventing others from connecting to the same port and
>> impersonating one's site?
>>     
>
> A security key.
>
> map:
>   - incoming:
>     - mysite.com
>     - www.mysite.com
>     key: cb14dd0c0184f246ee82b3070cc0571f93769c1ab74220a63131f6308751e322
>     outgoing: 127.0.0.1:10000
>     default: true
>     docroot: /usr/local/htdocs/swiftcore.org/doc
>
>
> Anything trying to connect to Swiftiply to serve mysite.com or
> www.mysite.com has to present the correct security key, or their
> connection will be unceremoniously dropped.
>
> IOWA deals with this just dandy, and swiftiplied_mongrel is setup to
> deal with this in it's protocol handler.
>
> All is not flowers and butterflies, though, in Mongrel-land.  The
> reason is this:  The security key needs to come from the application's
> configuration, and I haven't conceived of any framework-neutral way to
> get that security key from the application layer into the Mongrel
> layer so that it is available to the swiftiplied_mongrel code.
>
> I was working on this before I pushed 0.6.1, but decided I needed to
> get it released, so left this issue unsolved.  I fear that it may take
> framework specific code to enable a seamless delivery of the security
> key from the application's configuration into the innards of Mongrel.
>
> If someone wants to take a closer look at this issue and send me
> patches, I'd love to have them.  I've been weighed down by the chains
> and shackles of some very high priority client work over the last
> week, and don't see that ending for a few more days, and I have other
> work I am trying to finish for Swiftiply, so I don't see myself coming
> back to this issue anytime really soon.
>
>
> Kirk Haines
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/swiftiply-users/attachments/20070913/b1b9cc3f/attachment.html 

From jnicoll at gnexp.com  Thu Sep 13 13:02:39 2007
From: jnicoll at gnexp.com (Jeremy Nicoll)
Date: Thu, 13 Sep 2007 11:02:39 -0600
Subject: [Swiftiply-users] Preventing others from connecting to
 Swiftiply backend
In-Reply-To: <f4cd26df0709130930k5eebaf30y3842c96527df9fb4@mail.gmail.com>
References: <46E2B63D.5070306@gnexp.com>	
	<f4cd26df0709080854i558955f9m129c574b13691c33@mail.gmail.com>	
	<46E96390.8010606@gnexp.com>
	<f4cd26df0709130930k5eebaf30y3842c96527df9fb4@mail.gmail.com>
Message-ID: <46E96D2F.4090501@gnexp.com>

    It's amazing how much thought and work goes into making things 
simple, isn't it?  :)  Glad I could help.

Jeremy

Kirk Haines wrote:
> On 9/13/07, Jeremy Nicoll <jnicoll at gnexp.com> wrote:
>   
>>     Why not just make it a command line argument or part of a configuration
>> file for mongrel itself?  That way there is no worry about the framework
>> being used.  Options have to be specified anyway on where the application
>> is,  and so it really would not be taking the logic of mongrel any further
>> than what it is now.
>>     
>
> So simple and so workable.  Thanks for the suggestion!  I'll see what
> I have to do to add it to swiftiplied_mongrel today!
>
>
> Kirk
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/swiftiply-users/attachments/20070913/5cb1654a/attachment-0001.html 

From steve at lesseverything.com  Sun Sep 30 21:51:02 2007
From: steve at lesseverything.com (Steven A Bristol)
Date: Sun, 30 Sep 2007 21:51:02 -0400
Subject: [Swiftiply-users] nginx->swifty->eventmachine->mongrel->rails
	question
Message-ID: <396d7d2d0709301851u36858ea1ue29fe8a776db121@mail.gmail.com>

I just posted this to http://swiftiply.swiftcore.org/faq.html, but I
got an error so I thought I ask here (sorry if this is considered
spam):


I am having trouble figuring out how to get
nginx->swifty->eventmachine->mongrel->rails working.

I have ngix passing to swifty just fine, and if I start mongrel from
RAILS_ROOT using swiftiply_mongrel_rails everything does work fine,
but I can't seem to get the mongrels started from a script. Let alone
how to stop or restart them.

Also, I had three mongrels running, I killed one and it did not
restart. Which is what I thought was supposed to happen with the
redeployable: true switch set.

Thanks in advance for your help.

-- 
Thank you,
Steven A Bristol
steve at lesseverything.com
Home page:       http://lesseverything.com
Blog:                http://b.lesseverything.com
What you need:  http://lessaccounting.com