Changing Cherokee for a Smalltalk based web server?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Changing Cherokee for a Smalltalk based web server?

Offray
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

Reply | Threaded
Open this post in threaded view
|

Re: Changing Cherokee for a Smalltalk based web server?

fstephany
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

Reply | Threaded
Open this post in threaded view
|

Re: Changing Cherokee for a Smalltalk based web server?

Stéphane Ducasse
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
>


Reply | Threaded
Open this post in threaded view
|

Re: Changing Cherokee for a Smalltalk based web server?

Sven Van Caekenberghe

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




Reply | Threaded
Open this post in threaded view
|

Re: Changing Cherokee for a Smalltalk based web server?

Offray
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
>
>
>
>
>