|
Hello,
On Fri, 5 Jul 2002, Damien CLERMONTE wrote:
> > Hm, why you need persistence when LBLC* are used? Can
> > you explain why LBLC* without persistence does not work for you?
>
> As I said, lblc* works perfectly without persistence for me.
ok
> I just point out that lblc doesn't work with persistence.
Yes, I thought it was a known issue.
> As lblc has it's own hash/cache, persistence isn't really needed
> (although it might speedup cache lookups)
The persistence works more closely with clients, it forgets
the connections very soon. OTOH, LBLC* keeps the knowledge for
more time. We should keep the persistence as is, I can't see how
the persistence can help LBLC* to work faster. May be the caching
gurus can help.
> But other people might have the same problem I had, lblc*&fw should be
> maked as incompatible with persistence.
Yes, we have to mark it explicitly if not already done.
> > The proposed from you persistence can return RS that is already
> > scheduled from LBLC, so it works as a L2 cache considering the
> > LBLC as L1 cache. In this case your persistence will return
> > the same RS that LBLC* can return. LBLC* guarantee that for one
> > target the same RS is used. How you plan to use the both features,
> > I still can't see the trick? It seems you are trying to replace
> > LBLC* with the proposed persistence and to avoid using LBLC*.
> > Because 0/0->TARGET_VIP->RS is similar to LBLC*. Note that there
> > are other schedulers that you can consider.
>
> well, I really want destination based balancing, not source based :)
I mean DH scheduler. But I'm not sure that there is anything
better than LBLCR.
> Regards,
>
> Damien
Regards
--
Julian Anastasov <ja@xxxxxx>
|
