lsapi on remote hosts? / load balancing

#1
I'm getting a second application/web server soon for my rails project, and I'd like lsws to send some of the requests to it, while handling some locally.

1) Is this a reverse proxy? I get so confused about reverse vs. normal.

2) My plan was to run dispatch.lsapi manually on the second host, and add it to the "external applications" list, Then add a 'load balancer' in the external applications with each lsapi name

3) What would I call the "rails context"'s lsapi? It doesn't seem to have a name. The php one for the admin site seems to be uds://tmp/lshttpd/lsphp.sock, so I could try and figure out where the socket is placed. Can it be used with a remote address?

4) Or would it be better to just add a second installation of lsws on the 2nd server, and add an external 'web server' to my main installation, and a load balancer to somehow send half the traffic there. What do I use to reference the current server in the load balancer?

Thanks for a great product! I'm especially excited about the web-based config.
 

mistwang

LiteSpeed Staff
#2
Thank you for your praise. :)

Anaswers to your questions:
1) Yes, it is a reverse proxy.
2) You can do that, but you cannot use the easy configuration, have to do the step by step manually configuration.
3) "rails context"'s lsapi configuration is added behind the scene, you cannot reference it directly, or uses a remote address.
4) We think it is better to do it this way, ruby lsapi processes will be taken care of by LSWS, one less thing to worry about. There are a few options to reference the current server.

One is to access the local server as a web server through the reverse proxy. you need 2 vhosts define, one is bind to the public IP, handled by load balancer, another one is bind to local IP like "localhost", handled by the Rails application. Tell the load balancer load balancing to local server and the second server.

Second approach is a little bit more efficient, but requires you to configure Rails application manually on the server acting as load balancer, not using the easy "Rails" context. You can mix different kind of external applications in our load balancer implementation, so, the local LSAPI application and the external 'web server' can be used in a load balancer. Load balancer external application should be configured as the handler to the rails application. This approach requires you to put all static file on the first server, and no page caching on the second server, the second server just handle the dynamic pages.
 
#3
> Load balancer external application should be configured as the handler to the rails application.

How do I do this?

> This approach requires you to put all static file on the first server, and no page caching on the second server, the second server just handle the dynamic pages.

I see, because it only does the if-local-file-exists on the first server.

Thanks!
 

mistwang

LiteSpeed Staff
#6
I perfer LSWS (Load balancer) + LSWS with LSAPI on each cluster node over litespeed + mongrel culster, configuration is a little easier and performance should be better as well. :)
 
#7
I perfer LSWS (Load balancer) + LSWS with LSAPI on each cluster node over litespeed + mongrel culster, configuration is a little easier and performance should be better as well. :)
I think maybe it's a little overload to have a feature rich web server like a litespeed on every node. mongrel acts mostly like an APPLICATION server, and all proxing/static files serving happends on the balancer with lsws.

btw, i'm interesed how is rails caching/sessions handled in your config - like where the *.html pages produced by rails caching in production mode will be kept, need you memcached for the sessions etc.
 

mistwang

LiteSpeed Staff
#8
I think maybe it's a little overload to have a feature rich web server like a litespeed on every node.
LSWS + LSAPI should be faster than mongrel cluster on each node for rails request along, and pages cached in file system can be served by LSWS directly. And you don't need to worry about monitoring each Mongrel instance. That's true that LSWS is feature rich, seems overkill for this purpose, but it takes care of everything for you. :)


btw, i'm interesed how is rails caching/sessions handled in your config - like where the *.html pages produced by rails caching in production mode will be kept
That's why I recommend LSWS+LSAPI on each node, no need to worry about cached page this way.

need you memcached for the sessions etc.
It is completely a Rails configuration issue, not directly related to LSWS or Mongrel, same Rails configuration should be used.
 
Top