On Mon, Sep 11, 2006 at 01:21:14AM -0500, Mike Silbersack wrote: M> Ok, I started looking through the mess that is in_pcb.c, and I came up M> with a simpler idea than trying to improve upon my old heuristic. M> M> What if we just build upon what Gleb did in revision 1.256, and change the M> size of the tcptw zone? Instead of scaling it to maxsockets / 5, let's M> scale it to max((ipport_lastauto - ipport_firstauto)/2, 500). We'll have M> to rescale it whenever the port ranges are changed, but those sysctls are M> already handled by a function, so it'll be easy.
The UMA zone can't be made smaller than it is, while IP port ranges can vary in both directions. M> This means that we'll be keeping around fewer time_wait sockets than we do M> at present, but I don't think that's a big problem for anyone. On the M> positive side, it means that time_wait sockets can't starve out ephemeral M> ports unless you have more than 50% active connections. M> M> One slightly more complex solution would be to use one tcptw bucket for M> connections with local ports >= 1024 and a seperate bucket for connections M> with local ports < 1024. Assuming that our front end web proxy answers on M> ports < 1024, that would ensure that we keep one pool of time_wait sockets M> for our connections from clients and another pool for our connections to M> the backend web servers. I guess that would be slightly more "correct". M> M> What do you guys think? I think that your original commit should be rethought. It should free one tcptw entry, in a case of absolute match, and return NULL. Do not jump up and go on into cycle again. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
