[Serdev] Group membership functions

[Greg Fausak]

Howdy,

I've been looking at the opposite, and wondered if there
is an easy way to do it?

What I'd like to do is completely eliminate the caching function
in SER for all database related lookups.  For instance,
lookup("location") and lookup("aliases").  Instead of using an
in memory cache I'd like the SER server to go to the database everytime.

The database itself does a good job with disk caching, indexing, etc.
The main reason for doing this is so that I can run many servers
*without*
the replication gear.

My overall plan is to use one of the swamp class C addresses I have.

1) Create linux boxes with zebra on it (zebra.org), advertise
   the class C to my internet provider.
2) Place these boxes all over the world, each of them has
   the same IP address (and a unique secondary address).
3) Create a centralized database server running with replication.
4) All related services would go on ip addresses in the advertised
   class C.  Like NAT translation, dns, etc..

Then, each operation hits the SER server, the central database is
consulted if necessary.  If any of the SER servers goes down the
UA is unaware, because BGP routing will deliver the request to the
next closest server.

I realize there are some issues with current transaction state
in the fail event, but overall this provides
redundancy and local servers.

Another thing you can do with this setup is place several
SER servers behind a load sharing switch.

---greg

> 
> 
> At 12:23 AM 7/24/2003, Gulherme Dal Pizzol wrote:
> >Hello all,
> >
> >I was looking at the group membership checking functions and 
> noticed that
> >it always make an access to the MySQL database. This could 
> be too slow if
> >the function "is_user_in" is used frequently, right? 
> 
> Yes, they potentialy could. We haven't measured the real 
> impact but it is
> a potential bottleneck.
> 
> >(mysql always access the disk, there is no cache)
> >So, I was wondering if these functions could use shared memory tables
> >(along with mysql tables) to speedup the access to the group 
> information,
> >just like in ursloc/registrar modules.
> 
> Yes, they could. It is on our long-term list of things which 
> would be nice 
> to have. I don't think though that the problem in existing 
> deployments 
> was stressing us to prioritize it now.
> 
> >If it is possible, should I try to extend usrloc/group 
> module or implement
> >shared memory tables directly in group module?
> 
> Reasonable contributions are always welcome. I think what it 
> really takes
> is some generic database-caching mechanism you could use to groups, 
> authentication database and whatsoever.
> 
> -Jiri 
> 
> _______________________________________________
> Serdev mailing list
> serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
>