Re: [Dproxy-devel] memory cache for top 100?

[Andreas H. <hof...@in...>]

qu...@ba... wrote:
> 
> Hi all,
>         has anyone thought about implementing a memory cache for the top
> 100 or so dns lookups? This would definately be faster, especially for
> things like entries from /etc/hosts and deleteing timed out entries.
> 
> I think putting the whole thing in memory would be good as you could then
> setup another thread which would purge the timedout cache entries and
> rewrite the file (Less IO = good);

In the new 1.x series, the cache will be purged at a fixed time
interval. This will result in a better response time. 

With a memory cache there is a problem with the forking design of dproxy
- we can pass data in memory to the child but the child can not pass
back the result from an upstream query.

We consider a non forking design for the whole thing, but this would
make things much more complicated.

Another way to implement a mem cache was shared memory, but I never
tried that.

Or, as a last resort, we could cheat - fork of a child to do the
upstream query, write to the disk cache and read that new entry by the
parent on the next query for this host.

> 
> However, if the cache grows large this could be a downfall.
> Comments?

This depends on the size of your network. I run dproxy on my very small
net with 3 hosts and one user (me) in this seting, the cache is very
small. Most answers from the DNS have a ttl of 1-2 days, so in the usual
case, your cache will not become very large as long as you (+ your
users) won't contact some hundred hosts a day.

Well, there is that unusal case - some peopel run busy web servers and
want to resolve some thousend addresses from their logfiles in just one
hour ...

>
> Also, what's happening with getting dproxy working on the gateway machine.
> I know it means implenting the full dns protocol but I think it may be
> worth it.

Will be in 1.x (i have this already running on my gateway)


Ciao
  Andreas