FastCGI behind Apache?

Hi everyone,

Does anyone have experience with setting up Seaside on GS with FastCGI behind Apache?

We achieve to deploy a Swazoo behind Apache using rewrite rules such that:
<myserver>/WebApp/ is forwarded to Seaside
<myserver>/javascripts/ is served by Apache (static files)

However, our trials to achieve the same using FastCGI fail. This is what happens:

We can reach the webapp on <myserver>/WebApp but it loads _very_ slow.
Next, we see that no javascripts are loaded. This is because our webapp references these at the following relative url:
'./images/javascripts/<file>', which should be resolved to <myserver>/javascripts/<file>. This works fine with Swazoo (and a local seaside install in Pharo). However, with FastCGI, this relative url is resolved to <myserver>/Webapp/javascripts/<file>.

Why does FastCGI change this relative url resolution?
Should we change our relative urls to '../<path>' ?

btw, we based our config on the Apache config that comes with the GLASS appliance.

Thanks for any help or ideas.

Johan

Johan,

Yes, we have experience setting up Seaside on GemStone with FastCGI behind Apache. See the "Setup and Configuration" section of http://programminggems.wordpress.com/directory/. See http://programminggems.wordpress.com/2010/01/12/slicehost-2/ for my notes on the setup process.

The problem you describe is likely a bug in FastCGI. See http://programminggems.wordpress.com/2010/01/11/fastcgi-3/ and see if it addresses your problem.

James

On Oct 27, 2010, at 11:19 AM, Johan Brichau wrote:

Am 2010-10-28 um 02:59 schrieb James Foster:
> Johan,
>
> Yes, we have experience setting up Seaside on GemStone with FastCGI behind Apache. See the "Setup and Configuration" section of http://programminggems.wordpress.com/directory/. See http://programminggems.wordpress.com/2010/01/12/slicehost-2/ for my notes on the setup process.
>
> The problem you describe is likely a bug in FastCGI. See http://programminggems.wordpress.com/2010/01/11/fastcgi-3/ and see if it addresses your problem.
>
> James

Wow, this response was fast :)
As I encountered just that problem some time ago and
it took me days to figure out, I added your post as
the link ‘Pitfalls when using FastCGI’ to the TOC
of the GlassDB wiki (http://code.google.com/p/glassdb/wiki/TableOfContents)

So Long,
        -Tobias

My comments below address the FastCGI delay problem. As to configuring Apache to serve static files, we had a discussion on that a few days ago titled "Serving files from a WAFileLibrary behind Apache." I believe that the general advice is to serve the static files with Apache. I'll let others expand on those issues.

James

On Oct 27, 2010, at 5:59 PM, James Foster wrote:

Hi James,

Thanks for the pointers on the fastcgi problem. We will try that.

About the apache configurations: it seems all configurations that include serving static files are using seaside2.8, where the apps are served behind '/seaside/app'. Using that setup, we can make it work but the fact that seaside3.0 serves apps as '/app' (ommitting /seaside) seems to break the config (apart from the obvious changes that involves).

In the meantime, we switched to lighttpd which seems to work nicely, but I will definitely try apache again by walking through the detailed instructions and see if I can figure out the problem.

Johan

On 28.10.2010, at 09:53, Johan Brichau wrote:

> Hi James,
>
> Thanks for the pointers on the fastcgi problem. We will try that.
>
> About the apache configurations: it seems all configurations that include serving static files are using seaside2.8, where the apps are served behind '/seaside/app'. Using that setup, we can make it work but the fact that seaside3.0 serves apps as '/app' (ommitting /seaside) seems to break the config (apart from the obvious changes that involves).
>
There is a legacy redirector in seaside3.0. So you don't need to change the path at first. /seaside/app should still work.

> In the meantime, we switched to lighttpd which seems to work nicely, but I will definitely try apache again by walking through the detailed instructions and see if I can figure out the problem.

Do I understand you correct and you switched from http proxying to fastcgi? Can you elaborate on that? I only switched to fast-cgi because the other adaptors aren't as stable as fastcgi is. Usually I think http proxying is less confusing.

If you need even another http server I can throw cherokee in the mix. I'm still missing this blog post. Anyway I started using apache and friends then I changed to lighttpd and daemontools. Since last week I switched all my http serving to cherokee. The configuration is done completely per web interface and I have fastcgi working with load balancing. It is really nice. Cherokee even starts my gems.

If you need more details than I would feel more pressure to blog about it ;)

Norbert

Norbert Hartl <[hidden email]> writes:

>
> If you need more details than I would feel more pressure to blog about
> it ;)
Ok feel the pressure. I'm interested also ;-)

Regards
Friedrich

--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

On 10/28/10 1:05 AM, Norbert Hartl wrote:
> Anyway I started using apache and friends then I changed to lighttpd and daemontools.
A while back I wrote some shell scripts to make it easy to configure
lighttpd to run GLASS.
See lighttpd_setup from: http://github.com/Monty/GemStone_daemontools_setup

It didn't include serving static files using lighttpd, but it still
might be useful for those
who don't want to figure out lighttpd.conf from scratch.

If you want to clone it and update or enhance it, please do. I'll
include anything useful
in the next Appliance we ship.

-- Monty

Hi Norbert,

Sorry about the latency...

On 28 Oct 2010, at 10:05, Norbert Hartl wrote:

> Do I understand you correct and you switched from http proxying to fastcgi? Can you elaborate on that? I only switched to fast-cgi because the other adaptors aren't as stable as fastcgi is. Usually I think http proxying is less confusing.

Well, indeed, we starting using fastcgi because that is the recommended one.
With the Swazoo adaptor, we can get the configuration with static files working just fine. However, doing the same with fastcgi gives us that url resolution problem I mentioned.
At this time, I have not investigated the problem any further because we are happily running lightttpd. But I want to get to the bottom of it and will get back to this thread once I have...

And, yes, please provide some more info on cherokee ;-)

Johan

It seems to me that if the non-FastCGI path needs some attention, that would be worth the effort, since FastCGI is really kind of an anachronistic solution.

On 10/29/2010 07:23 AM, Chris Curtis wrote:
> It seems to me that if the non-FastCGI path needs some attention, that
> would be worth the effort, since FastCGI is really kind of an
> anachronistic solution.
>
> --chris
>

At the moment I don't have the time to devote to:

   - fixi swazoo on GemStone
   - create a hyper adaptor for Seaside3.0
   - port another web server to GemStone
   - ???

FastCGI is not the only issue that I've run into with Apache ... The
load balancer doesn't seem to round robin (the way I expect it too). At
about 100 requests/second Apache has gone catatonic and locked up for
20-30 seconds at a time ... that's when I switched to lighttpd which can
handle all the requests you can throw at it until it saturates the spu
(1000's of requests per second) and lighttpd supports fastcgi just fine ...

Dale

I should have been slightly more explicit -- in that I was wondering if there might be something *I* could tackle to help improve things. I'm not an expert yet, but I'm happy to try and contribute. 

On 10/29/2010 09:44 AM, Chris Curtis wrote:
> I should have been slightly more explicit -- in that I was wondering if
> there might be something *I* could tackle to help improve things. I'm
> not an expert yet, but I'm happy to try and contribute.
>
> If there's a rough outline somewhere of (a) what's broken with Swazoo,
> and/or (b) what needs to be done to create a Hyper adapter, I'd love to
> take a look and see if I can help.
>
> --chris

Chris,

There are a handful of issues that have been discussed in the mailing
list and some that have been reported against swazoo in glassdb
(http://code.google.com/p/glassdb/issues/list?can=2&q=swazoo). Issues 61
and 80 are probably the most pertinent, but as far as I know neither of
the issues has been adequately characterized, so the real work boils
down to setting up a test environment where you bang the heck out of
Seaside3.0/Swazoo using siege/jcrawler/etc. and then fix the issues as
they are discovered/characterized.

The Hyper adaptor work involves creating a Seaside3.0 adaptor for Hyper.
The best way to proceed with that is to set up a Seaside2.8 system with
Hyper installed and then copy the basic framework of the fastcgi adaptor
and then adapt it for Hyper. Once the basic work is done, you should
take a look at Issue 109
(http://code.google.com/p/glassdb/issues/detail?id=109) and make sure
that the adaptor/Hyper doesn't suffer from the same UTF8 problem (I
suspect that it does) ... BTW, in this case it is worth using
SqueakSource3.0 for the testing, because you can use the ü in the
title/url/links/etc. which makes validating correctness much easier ...

Register on GemSource and I'll add you to the GLASS DEVs group so you
can commit your changes.

Of course I will find the time to help you get started and along the way
as needed.

Thanks,

Dale