I guess that sven is using pharo to manage multiple servers using a rest like architecture. On Nov 11, 2011, at 5:58 PM, Francois Stephany wrote:

Hi Offray,

I'm afraid none of these would suite very well. The usual approach for a webserver in Pharo is to put it behind a Nginx/Apache/etc (as with your Rails or Zope).

I don't know anyone who is using a Pharo server to load balance other applications but I'm maybe wrong.

Cheers,

Francois

On 11/11/11 06:37, Offray Vladimir Luna Cárdenas wrote:

...

Hi all,

I'm getting random "504 gateway error" answers from several sites (using Zope and Rails) that are served by Cherokee using a reverse proxy setup. This error is an open issue in Cherokee and has been reported and not properly patched since 2009:

https://code.google.com/p/cherokee/issues/detail?id=504

I did choose Cherokee because of its easiness to setup and newbie friendly interface and character, but with this problem I'm thinking in testing another server, may be a Smalltalk based one that have similar characteristics and can serve sites in Zope or Rails also. I know about Comanche, Swazoo and Zinc, but I don't know which of them is better (making load balance and stuff like that) and have proper documentation about using it in combination with other software (Zope and Rails in my case).

Any advice on this matter is greatly appreciated,

Offray

-- http://tulipemoutarde.be BE: +32 (0)65 709 131 CA: +1 778 558 3225

Hi, Thanks Stéphane and Sven. I think that I will opt for lighttpd or Nginx as a front end for Zope/Rails/Seaside-Pier inmy attempts to solve the "504 gateway error" unsolved in Cherokee. Cheers, Offray On 11/13/11 04:42, Sven Van Caekenberghe wrote:

On 12 Nov 2011, at 23:44, Stéphane Ducasse wrote:

...

I guess that sven is using pharo to manage multiple servers using a rest like architecture.

I am using multiple Smalltalk server instances/images behind a non-Smalltalk (Apache 2 in my case) load balancer.

Current VMs are single core, so to use the multiple cores on modern machines, this is useful.

Given the amount of memory you get today, you can better use it, and Smalltalk is very efficient compared to say Java.

This kind of setup also allows for a more resilient system since requests can be routed around a crash in a worker.

There exist server tools (like monit) that monitor your workers and restart them automatically when needed.

The challenge is of course to build a system that is either stateless or where the shared state lives efficiently outsite each worker.

Sven