[Catalyst] patch to C::P::SubRequest / RFC

[John Napiorkowski]

Yeah, there is overhead for spawning a thread, but if
you have 6 or 8 subrequest per page and a decent
multicpu server my guess is that it could be faster. 
But I am not sure until I can test the theory.  To be
honest, my tests of subrequest showed that using LWP
to access the URI instead wasn't much slower, so my
guess is there is room for improvement with it.

I'm building a new version of the site today and will
run my tests and benches.

--john

--- luke saunders <luke.saunders at gmail.com> wrote:

> Hi John,
> 
> >
> > I'm using subrequests quite extensively in my
> > application so I'll test out your patch and see if
> > anything breaks :)
> >
> 
> That would be great, thanks.
> 
> > I've actually been trying to work out a patch for
> this
> > that spawns off a new thread.  I've been using
> > subrequest for a quasi portal like approach to
> > building my site and I find that performance
> suffers
> > when there are too many subrequests.  --john
> >
> 
> Wouldn't spawning a new thread make it slower? Since
> the calling
> thread still needs to wait for the spawned thread to
> return.
> 
> > --- luke saunders <luke.saunders at gmail.com> wrote:
> >
> > > I've noticed that if, using C::P::SubRequest,
> > > action_a subreqs to
> > > action_b and action_b does $c->res->status(400)
> then
> > > action_a will
> > > also return a 400 unless overridden. This is
> also
> > > the case for any
> > > other changes to $c->res that the subreq'd
> action
> > > might make.
> > >
> > > This is because C::P::SubRequest doesn't give
> the
> > > subreq'd action its
> > > own Response object. There was some discussion
> on
> > > #catalyst where it
> > > was pretty much decided that this was wrong.
> > >
> > > Attached is a patch which changes SubRequest.pm
> so
> > > that it passes the
> > > subreq'd action a shiny new Response object to
> > > prevent it stamping all
> > > over the original. It's feasible that the
> calling
> > > action may actually
> > > be interested in the subreq'd action's Response
> > > object (for status
> > > code checking etc) and for this reason if subreq
> is
> > > called in list
> > > context the subreq'd action's Response object is
> > > returned as the
> > > second return value: my ($body, $res) =
> > > $c->subreq(...)
> > >
> > > Ideally, the subreq'd action should probably get
> a
> > > whole $c of its
> > > own, but this would require much work. So I
> propose
> > > that this will do
> > > for now .
> > >
> > > There may be a problem with backwards
> compatibility
> > > if this patch is
> > > actually applied, so maybe this new behaviour
> should
> > > only occur if
> > > some flag is set or if subreq_local (or
> whatever) is
> > > called instead.
> > >
> > > Any thoughts?
> > > >
> _______________________________________________
> > > List: Catalyst at lists.rawmode.org
> > > Listinfo:
> > >
> http://lists.rawmode.org/mailman/listinfo/catalyst
> > > Searchable archive:
> > >
> >
>
http://www.mail-archive.com/catalyst@lists.rawmode.org/
> > > Dev site: http://dev.catalyst.perl.org/
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> >
> > _______________________________________________
> > List: Catalyst at lists.rawmode.org
> > Listinfo:
> http://lists.rawmode.org/mailman/listinfo/catalyst
> > Searchable archive:
>
http://www.mail-archive.com/catalyst@lists.rawmode.org/
> > Dev site: http://dev.catalyst.perl.org/
> >
> 
> _______________________________________________
> List: Catalyst at lists.rawmode.org
> Listinfo:
> http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive:
>
http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com