Re: IRC-Problem

[Kurt Roeckx <Q@xxxxxxx>]

On Thu, Apr 06, 2000 at 05:36:09PM +0100, Thomas Hagen Trocha wrote:
> Or do you know how to be good prepared for such a huge amount of people?

I can't say I did that before, maybe someone can help you better.
I think the easiest solution is to use multiple ircd's (on
different hosts) connected to each other, but that might not be a real
option.

You need to make sure your OS can handle it, not all of them handle alot
connections with data in the buffers good. IRCD will first make a
sendqueue, and then try to send that to the OS, which keeps it how
sendqueue. This means that the OS itself needs alot RAM too, to be able to
work properly. I think this is what you set with mbuf under FreeBSD, and
maybe others.

> Maybe there is a option to increase the "waiting"-queue.

What you mean with waiting queue? You mean the connection attempts to the
ircd? Connecting 10K clients in a short time will give you alot problems.

The OS will not like it, I don't know anything about solaris, but there is
probably a way to alow more connections in a short time.

Ircd itself could give problems too, specially if compiled with
CLONE_CHECK or SLOW_ACCEPT. I would make sure SLOW_ACCEPT is not defined.
If they connect from the same ip, CLONE_CHECK will give you problems too.
config.h doesn't allow you to turn both of, and will then define
CLONE_CHECK. Make sure you remove that part if you really want both to be
off.

> What is the meaning of the other lines in icrd.tune??

It should contain 6 lines:
- ww_size: The size of the whowas array
- lk_size: locked size. This keeps a list of split clients, to prevent
  nick collisions.
- _HASHSIZE: This is the size of the hash table for clients, it should be
  bigger then the max number of clients.
- _CHANNELHASHSIZE: Same thing but for channels.
- _SERVERSIZE: for servers ...
- poolsize: max of data hold in send queue's

Most of those are adjusted as needed, it's usefull for the preallocation.
Having to rehash during a netjoin can cost alot cpu time.

It could help to put a big number for the _HASHSIZE. It should be a prime,
but the ircd will change it to the first bigger prime if you don't put on
in it.

I don't think you shouldn't worry about ww_size, lk_size. _CHANNELHASHSIZE
and _SERVERSIZE aren't a problem for you either.

I guess poolsize would be your biggest problem, if you want to send 1
message to 10K clients, and it's let's say 100 bytes long, you already
need 1 MB to hold that. I guess something around 10 MB would be a good
start. If you have plenty of RAM you could make it bigger ofcourse.

If you only get a message every second (very slow), you already need 8
mbit/s. Doing that over alot different sockets isn't going to be easy, and
I highly doubt that a 10 mbit will be able to handle it.

I think an avg client will take about 2 K of RAM, so that would be atleast
an other 20 MB.


Q