|
On Tuesday 08 October 2002 11:38, Roberto Nibali wrote:
> > However, most modern web sites use sessions for all kinds of reasons, and
> > sessions are usually stored on a single machine. It's possible for both
> > Apache and IIS to store the session state on a shared storage device or in
> > a database, but this is rather slow. Especially for IIS, because IIS
> > normally stores session state in RAM for fastest access.
>
> Agreed, except with the speed issue. A session state cannot be the
> bottleneck or you have commited a serious design crime to your whole
> application.
I have never measured it myself, but it seems to me that fetching data from
shared storage or a database is by definition slower than fetching it from
RAM. And our database is already a bit heavily loaded, so I'm not too happy
with adding extra load to it for session state storage...
> > Now I'm wondering if it's possible for LVS to 'prefer' the realserver to
> > which it connected a client before if that realserver is not completely
> > overloaded
>
> LVS doesn't connect ???
s/connected/directed/
> > or removed from the cluster, but otherwise (and only then) reassign the
> > client to another realserver.
>
> WLC.
WLC reassigns per HTTP request for non-persistent connections or per IP
address for persistent connections. What I was thinking about is that as long
as all servers are available and have a similar load that LVS keeps
redirecting you to the same realserver and only reassigns when needed to
restore the balance or handle a failover condition.
This all with the idea that session storage is faster from RAM so you want to
stick with one realserver if possible. If that point is moot (that's what I
understand from you, but I don't understand why) this is obviously no longer
an issue and you can disregard my entire mail ;-)
> > This way the overhead of fetching session state from slow storage on the
> > realservers is kept to the minimum required, and you still get the full
> > failover capability from ldirectord.
>
> I don't understand, sorry. Can you please explain a little bit further as to
> why you think you can minimise the overhead of fetching the session state?
> Also I don't think you need session state if you don't have other DB queries
> to do for your website and those are that most of the time account for the
> worst load imbalance.
If you have 3 realservers one of them sets up a session and keeps the session
state in RAM. It's most efficient to return to that realserver because the
other realservers don't have the session state yet. They can fetch it from
the database, but that's slower than simply fetching it from RAM.
> > If it's only for failover this can also be achieved using the sysctl flags
> > that Joseph now finally documented in the HOWTO (thanks!), if it's also
> > for
>
> Where did he document new sysctrl flags for failover or do I misunderstand
> you again?
> http://www.linuxvirtualserver.org/docs/sysctl.html, expire_nodest_conn. Set
it to non-zero and at least you get proper failover reassignments from LVS
AFAICS. My LVS doesn't have this option yet, but that's what I read from the
docs.
> > equalizing overloaded realservers I am much less sure the current LVS can
> > do this.
>
> The WLC scheduler does kind of an equalizing functionality. Please read [1]
> and tell me if this doesn't satisfy you. If we have a serious overload
> caused by session state fetching or replication on a server we will see this
> kind of time shifted in the amount of active connections per RS. The WLC
> scheduler takes care of this with a very simple but effective (I have MRTG
> graphs and numbers proving this) formula.
Well, WLC is either per-request or per-ip. Per-request is too often and per-ip
is too little, because it doesn't reassign even if the balance is completely
skewed, nor does it cope with failover.
Again, I'm only assuming that session state transition is as expensive as the
site developers are trying to tell me, I haven't measured it myself yet.
--
Martijn
|
