Re: MAXMEMB

I'll give more insight to why I did this.  It is almost impossible for
me to gain access to my consoles over a firewall.   You see the the main
process offers me port 1024 then adds 1 each new connection.  I can not
open up 1024 - 1096 or whatever on my firewall.  What we've done is made
it simple.  Now the process only uses 783 and 782 ports and no more. 
This may not be an issue for some but was for us.  Maybe this behavior
is something that can be looked at in 8.0 version.  Having 2 possible
ports are okay but having a  N number of possible ports, IMHO are not.  



On Sun, 2003-01-12 at 15:08, Bryan Stansell wrote:
> On Wed, Jan 08, 2003 at 03:11:48PM -0500, cfowler wrote:
> > Is there a technical reason that MAXMEMB's is limited to 16?  I've
> > changed mine to 96.
> 
> the big reason (and a main reason for multiple processes) is the
> maximum number of open files a process can have.  each console can have
> a few file descriptors associated with it (device, logfile, connected
> users, and socket).  so, off the top of my head that would be ( 2 *
> consoles + users + 1 ).
> 
> you also have the speed of your conserver host vs the rates at which
> data could be streaming to it.  go back a decade and this was probably
> more of an issue than today, but it's still something to think about.
> 
> and then you have the problem recently mentioned about delays.  if any
> of the 96 console connections "lock up", it'll delay all activity on
> the 96 consoles.  with 16, there's less of an impact (but, obviously
> there is an impact, based on the outstanding question of the delays).
> this can be an issue once the server comes up or during startup - with
> 16 per process you get a bit of parallelization during startup.
> 
> so, is there any reason not to up the number to 96?  no.  assuming you
> know the risks and weigh things appropriately.  if i remember right,
> i've upped the number to 48 at some sites.  but that was mainly to
> reduce the memory footprint in older versions of the code which had
> staticly allocated buffers.  no need to worry about that with the
> current code.  personally, i wouldn't change from 16 unless there was a
> really good reason (like wanting to only have one child process for
> firewall rules or some such reason).
> 
> Bryan
> _______________________________________________
> users mailing list
> users@conserver.com
> https://www.conserver.com/mailman/listinfo/users