Re: [go-nuts] Modeling a bounded cache with timeouts?

[Patrick Mylund Nielsen]

I'm not very familiar with it, but this almost exactly like what Vitess does:  http://code.google.com/p/vitess/ 

On Wed, Jul 18, 2012 at 2:01 PM, Andreas Bielk <andrea...@gmail.com> wrote:

I'm working on my first 'real' production code in Go, and so far it's working out great.

The project is a small authentication-proxy that sits in front of database-instances, in the realm of thousand(s) of clients and hundred(s) of db-backends.

The process is basicly

1) accept new connection

2) authenticate client and choose a backend

3) create connection to backend

4) proxy rest of session

A quick prototype seems to work very well with acceptable throughput etc.

However, the creation of new backend connections is somewhat costly in terms of latency (for various reasons), 

and most client connections is mostly very short-lived, so I would like to optimize for this and reuse connections. 

This would be very straightforward if not for the requirement that the window when a connections is allowed 

to be reused is small (a second or two), and should preferably be properly closed down if not re-used.

So I need a cache (Destination > Connection), that is bounded (let say less than 10 connections per destination) 

that supports some sort of reaper who closes and removes old connections.

My first pass at this quickly became a mess, especially the timeout part..

--

Would very much appriciate any pointers on how to implement this in idiomatic Go, 

or any pointer to existing code that solves similar problems.

Regards,

Andreas Bielk (@wallrat)

[roger peppe]

On 18 July 2012 13:01, Andreas Bielk <andrea...@gmail.com> wrote:
> I'm working on my first 'real' production code in Go, and so far it's
> working out great.
>
> The project is a small authentication-proxy that sits in front of
> database-instances, in the realm of thousand(s) of clients and hundred(s) of
> db-backends.
>
> The process is basicly
>
> 1) accept new connection
> 2) authenticate client and choose a backend
> 3) create connection to backend
> 4) proxy rest of session
>
> A quick prototype seems to work very well with acceptable throughput etc.
>
> However, the creation of new backend connections is somewhat costly in terms
> of latency (for various reasons),
> and most client connections is mostly very short-lived, so I would like to
> optimize for this and reuse connections.
>
> This would be very straightforward if not for the requirement that the
> window when a connections is allowed
> to be reused is small (a second or two), and should preferably be properly
> closed down if not re-used.
>
>
> So I need a cache (Destination > Connection), that is bounded (let say less
> than 10 connections per destination)
> that supports some sort of reaper who closes and removes old connections.
>
> My first pass at this quickly became a mess, especially the timeout part..

here's perhaps an idea for how you might structure this:
http://play.golang.org/p/r1OjypKIti

note the "share memory by communicating" idiom - there's no mutex necessary
on the Conn type because ownership is always evident.

this is actually the first time i've found a legitimate use for the
len operator on a channel.
the destination map could also be served by a goroutine, but
i think it's quite a bit more efficient and almost as easy to use a mutex
in this case.