[Q] FastCGI + Squeak?

Hi,

On what form normal seaside application is deployed? Is there anyone  
who tried seaside(squeak) with apache or other web server with  
FastCGI? What I've found was for Smalltalk/X.

Thanks in advance.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I think most use mod_proxy or mod_rewrite with apache - its dead  
easy, lets you move static images to neighboring directories and  
still have relative urls, etc.


On Feb 20, 2006, at 12:39 AM, Sungjin Chun wrote:

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> On what form normal seaside application is deployed? Is there anyone
> who tried seaside(squeak) with apache or other web server with
> FastCGI?

FastCGI? Why FastCGI? Squeak comes with it's own http server. Apache
is just used as a frontend. In the background the squeak image and
webserver are always running.

Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Feb 20, 2006, at 6:10 PM, Philippe Marschall wrote:
> FastCGI? Why FastCGI? Squeak comes with it's own http server. Apache
> is just used as a frontend. In the background the squeak image and
> webserver are always running.
>

For load balancing. Now, here comes another question, if there's many  
request per seconds, ie., high load, what is best deployment strategy  
for this?

Thanks again in advance.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> For load balancing.

But still, you can do that easily with rewrite rules and proxying. Can
you explain the advantage of using FastCGI?

> Now, here comes another question, if there's many
> request per seconds, ie., high load, what is best deployment strategy
> for this?

As you said, the strategy is to do a per-session load balancing onto
multiple images. I think a good guideline is to have one CPU and 1 GB
of RAM for each image, but that might also depend on your persistency
backend.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Feb 20, 2006, at 7:35 PM, Lukas Renggli wrote:

>> For load balancing.
>
> But still, you can do that easily with rewrite rules and proxying. Can
> you explain the advantage of using FastCGI?

Connection or Request Count Based Load Balancing, like LVS(Linux  
Virtual Server).

>
>> Now, here comes another question, if there's many
>> request per seconds, ie., high load, what is best deployment strategy
>> for this?
>
> As you said, the strategy is to do a per-session load balancing onto
> multiple images. I think a good guideline is to have one CPU and 1 GB
> of RAM for each image, but that might also depend on your persistency
> backend.

Multiple Images for Single Application in One Server? Or Single Image  
in Single Server?

What I want to write in Seaside is actually not for performance. But  
I want to know general guideline for performance in seaside application.

Thanks in advance.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> > As you said, the strategy is to do a per-session load balancing onto
> > multiple images. I think a good guideline is to have one CPU and 1 GB
> > of RAM for each image, but that might also depend on your persistency
> > backend.
>
> Multiple Images for Single Application in One Server? Or Single Image
> in Single Server?

I don't get it. If you want to do load balancing you need 1
application running on multiple images, else I wouldn't call it load
balancing, right?

> What I want to write in Seaside is actually not for performance. But
> I want to know general guideline for performance in seaside application.

What is your question then? I don't understand? Can you give an example?

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Todd Blanchard wrote:
> I think most use mod_proxy or mod_rewrite with apache - its dead easy,
> lets you move static images to neighboring directories and still have
> relative urls, etc.
I'd beg to differ on the above comment about being "dead easy".. I tried
getting mod_proxy up and going last week under Apache2 and spent quite a
bit of time monkeying around with the proxy rules for the reverse
proxy.. I got it up and running
for the initial ping of a Seaside site, but URLs that map back to
Seaside are still broken, and I've given up trying to fix them
for now until I've got a working app up and going.  As usual, YMMV!

-- Rick


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> I'd beg to differ on the above comment about being "dead easy".. I tried
> getting mod_proxy up and going last week under Apache2 and spent quite a
> bit of time monkeying around with the proxy rules for the reverse
> proxy.. I got it up and running
> for the initial ping of a Seaside site, but URLs that map back to
> Seaside are still broken, and I've given up trying to fix them
> for now until I've got a working app up and going.  As usual, YMMV!

Did you enable "ProxyPreserveHost On" (it enabled Seaside to get
absolute-urls correctly)? Did you set the correct base-path in the
Seaside application configuration?

My rewrite-rule looks like:

        RewriteEngine On
        RewriteRule ^/(.*)$ http://localhost:8080/seaside/app/$1 [P,L]

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lukas Renggli wrote:
> Did you enable "ProxyPreserveHost On" (it enabled Seaside to get
> absolute-urls correctly)? Did you set the correct base-path in the
> Seaside application configuration?
>
> My rewrite-rule looks like:
>
> RewriteEngine On
> RewriteRule ^/(.*)$ http://localhost:8080/seaside/app/$1 [P,L]
>  
Nope.. no "ProxyPreserveHost on" is in my httpd.conf file.. I was
actually trying to follow a document that
was suggested here (see link below) last year (if I recall) for getting
a reverse proxy up and running to allow
Seaside to appear on an Apache served page/virtual host.. It looks like
you're using mod-rewrite as
opposed to mod_proxy.. What's the general consensus on which is
better/easier?  I'll argue that mod-proxy
is not very easy to setup in my opinion, but that may be due to the fact
that I know as little Apache crud
as I need to know to get by.  If you don't mind, can you enlighten me
(and hopefully others) on what settings
should be used to get Apache to serve Seaside pages with working
self-referential links?

Thanks!

-- Rick


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> It looks like you're using mod-rewrite as opposed to mod_proxy..
> What's the general consensus on which is better/easier?  I'll argue
> that mod-proxy is not very easy to setup in my opinion,

I never used mod_proxy, so I can comment on this. However the rewrite
rule I gave as an example is also doing a proxying (i even think
internally it is using mod_proxy):

RewriteRule ^/(.*)$ http://localhost:8080/seaside/app/$1 [P,L]

^/(.*)$ is a regular expression matching the incoming request-url, in
this case it matches everything.

http://localhost:8080/seaside/app/$1 tells apache how to rewrite the
url, in this case it simply takes everything after the slash $1 and
appends it to http://localhost:8080/seaside/app/.

[P,L] tells apache what to do with the rewritten url. P(roxy) means it
should proxy the request to the generated url. L(ast) means it should
not try to apply any other rule, if this one matched.

For this example you need to go to the config-interface of your
application and set the base-path to "/". That's all.

This was a very simple example, where everything was passed to one
Seaside application in one Squeak image. You can also think of
something that passes different paths to different applications and
images (note the different ports):

RewriteRule ^/foo/(.*)$ http://localhost:8080/seaside/foo/$1 [P,L]
RewriteRule ^/bar/(.*)$ http://localhost:8080/seaside/bar/$1 [P,L]
RewriteRule ^/(.*)$ http://localhost:9090/seaside/zork/$1 [P,L]

For the above applications you need to set the base paths to "/foo",
"/bar" and "/".

You might also want to serve static files for certain sub-directories,
e.g. the first rule matches any URL starting with /resources/, leaves
it unmodifies - and is the last applied rule. So only request not
starting with /resources/ will be passed to the seaside application,
else they are handled by apache internally.

RewriteRule ^/resources/.*$ - [L]
RewriteRule ^/(.*)$ http://localhost:9090/seaside/zork/$1 [P,L]

Tell me if you need more examples.

Actually I prefer programming in Squeak than writing rewrite-scripts,
but it can be fun from time to time: as an example rewrite-maps can be
fun for mass-seaside-app hosting ;-)

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lukas Renggli wrote:
> [ ... ]
> RewriteRule ^/foo/(.*)$ http://localhost:8080/seaside/foo/$1 [P,L]
> RewriteRule ^/bar/(.*)$ http://localhost:8080/seaside/bar/$1 [P,L]
> RewriteRule ^/(.*)$ http://localhost:9090/seaside/zork/$1 [P,L]
>  
Lukas,

Is it safe to assume that using the above rewrite rules won't get you
past a setup where the Seaside webserver
(aka squeak) is hidden behind a firewall and not directly accessible to
the public, and that is when you'd use a
reverse proxy setup which does the extra steps to be the go-between the
user's browser session and the "other"
web server (in this case squeak's).. I believe that's ultimately the
decision maker here (and perhaps slightly off topic)
on whether to use a reverse proxy or just rewriting rules like those
above.  Please correct me if I'm wrong.. In the meantime
I'll continue looking for ways to fix my reverse proxy setup so it works
for all links..

-- Rick


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Feb 21, 2006, at 1:57 AM, Lukas Renggli wrote:

>
> I don't get it. If you want to do load balancing you need 1
> application running on multiple images, else I wouldn't call it load
> balancing, right?

I mean, I will use multiple servers (hardware, maybe order of 100  
servers, current existing service uses almost 400 server cluster).  
Per server, I asked which is better configuration. Multiple Image/
single server or Single Image/Single server. Sorry for my poor  
english. T_T

>
>> What I want to write in Seaside is actually not for performance. But
>> I want to know general guideline for performance in seaside  
>> application.
>
> What is your question then? I don't understand? Can you give an  
> example?

For example, general database based PHP application can process  
several thousand of request per second(on linux with modern server  
hardware) if properly configured(content caching middleware for  
database and etc). I just want to know this kind of empirical  
guideline for Seaside application. Maybe actual deployment case study  
will help me very much.

Thanks in advance.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Is it safe to assume that using the above rewrite rules won't get you
> past a setup where the Seaside webserver
> (aka squeak) is hidden behind a firewall and not directly accessible to
> the public, and that is when you'd use a
> reverse proxy setup which does the extra steps to be the go-between the
> user's browser session and the "other"
> web server (in this case squeak's)..

Yes, that's the case, if your rewrite rules are not buggy and we
assume that there are no security holes in Apache. I mean the rewrite
rule hardcodes the target port, there is no way to change that from
the URL.

If have your firewall is blocking access to all ports except 80, your
images shouldn't be accessible directly but only trough apache.

> I believe that's ultimately the
> decision maker here (and perhaps slightly off topic)
> on whether to use a reverse proxy or just rewriting rules like those
> above.  Please correct me if I'm wrong.. In the meantime
> I'll continue looking for ways to fix my reverse proxy setup so it works
> for all links..

I don't see an advantage of not using rewrite rules, not even security
wise. However that question should maybe be answered by an Apache
expert (not an Apache user like I am).

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside