perlbal use case question

Michael Engelhart mike.engelhart at gmail.com
Tue Jun 10 21:00:02 UTC 2008


On Jun 10, 2008, at 2:52 PM, Nathan Kurz wrote:

> On Tue, Jun 10, 2008 at 12:01 PM, Michael Engelhart
> <mike.engelhart at gmail.com> wrote:
>> If  we were using Java or something the
>> architecture would be much simpler but currently that's not an  
>> option on the
>> table.
>
> How would you approach this problem if you were doing it in Java?  I'm
> not really current on what's out there on that side of things.
>
Well its just that Java is threaded by nature so I wouldn't have the  
Rails issue of having to fork lots of backend processes to handle the  
requests so I could let the request block without as much resource  
contention.   In Rails+Mongrel the backend processes are memory hogs  
even if they're just sitting their doing nothing.
>>  I'm not  sure where to even start at this point.
>
> If you choose to take this route, probably just reading through the
> Perlbal source would be the best start   It's short and clear, and you
> can probably understand it fully in a couple hours.  But as Mike
> suggests, this might not be the easiest approach if you are unfamiliar
> with Perl.  While the Perlbal solution could be solid, it's not going
> to be trivial.
>
> If you get rid of the Apache layer, the approach you first described
> using Perlbal internal redirects doesn't seem that bad, and you might
> not have to modify Perlbal at all.  The only hard part of that is
> going to be coming up with processes lightweight enough to meet your
> needs and load requirements.  If you are handling more than a few user
> requests per second, and your external requests might take up to a
> minute, this might be hard to achieve.  What are your anticipated
> loads, by the way?


Well for the lightweight process I was going to write something simple  
in Rack which which is a minimalist interface to writing a web stack  
that seems to scale pretty well when using Mongrel or any of the other  
web servers out there.

Loads aren't huge by any stretch at this point - maybe 25-50 req/sec  
but enough that with Rails, it would require multiple servers to  
handle the load due to the blocking nature of all the requests.




More information about the perlbal mailing list