Re: Possible problem with ACCEPT/CONNECT in

From: Peter Zaitsev (pz@spylog.ru)
Date: Fri Apr 07 2000 - 04:53:52 EST


> You're using localhost, which is the loopback interface,
> AFAIK, there is actually a know slowdown problem with loopback
> on recents 2.3 kernels, so maybe the slowdown come from here.

This is just to repeat this problem more easy without need to modify source
somehow.
I found this problem in network enviroment so it is not limited to loopback
interface.
Originaly I discovered this problem for 2.2.14 kernel and redhat 2.2.12-20
kernel.

>
> > for(t=0;t<PROCESSES;t++)
> > if (fork()==0)
>
> Hummm, so you fork() 200 time, which isn't a really good thing,
> ever heard of non blocking connect() then select() on a set of fd ?

Yes. This is to simulate many clients doing conect at the same time, also I
want to have the soures simple. That's wy it forks much. The problem also
repeated on 20 processes...

>
>
> > {
> > // Here we have the process forked.
> > for(c=0;c<CONNECTS;c++)
> > {
> [...]
> > res=connect(i,&serv_addr,sizeof(serv_addr));
> > if (res==-1)
>
> Then you start connecting 10000 time for each fork()...
> I can understand the time it make to connect...

Yes ! I have a number of processes trying to connect a server in a loop -
just normal situation for my working server. The problem is then this is
run other network no client nor server are loaded by CPU, network is not
loaded much eather but connects take significant time sometims.

>
> you're making a total of 2 000 000 of connections, what do you expect ?
> with 200 simultaneous connection attempt at the same time, on the loopback
> interface ( so there isn't much latency between you're connect() )...

Well. This is just an example. In real work I start to getting this problem
then I have just only 100 requests (so connects) per second.

>
> Your benchmark ( which i think is very similar to a m$ windows one )
> do not mean anything, you're actually benchmarking BS.

I'm not benchmurking anything. I'm just trying to reproduce a problem.
Why I have this timeouts: 3,9,21,45 seconds ONLY ? No 5 seconds timeout or
15 ?

>
> Your client program itself make the machine slow because it is badly
> written, and you're benchmarking client & server on the same machine !
> What did you expect ?
>
> Please do not blame the kernel for being a bad programmer.

:) Could you please better read comments befor watching the source.

>
> * Now for the server part :
>
> [...]
>
> > if(listen(sockfd,100)<0)printf("error listen\n");
> > for(i=0;i<PROCESSES;i++)
> > if (fork()==0)
> > for(;;){
> > bzero(&clnt_addr,sizeof(clnt_addr));
> > caddrlen=sizeof(clnt_addr);
> > sockfd1=accept(sockfd,(struct sockaddr*)&clnt_addr,&caddrlen);
> > if(sockfd1<0) continue;
> > close(sockfd1);
> > }
> > }
>
> Please,
> before blowing the list up with such thing, know what you do !
> You're currently starting one accept by process.
>
> It could be a good idea for you to learn how to correctly code a
> server process...
> It should be like that :
>
> while ( 1 ) {
> clnt_sock = accept(sock, (struct sockaddr *) addr, &len);
> if ( clnt_sock < 0 ) {
> perror("accept");
> return -1;
> }
>
> ret = fork();
> if ( ret < 0 ) {
> perror("fork");
> return -1;
> } else if ( ret == 0 ) {
> /*
> * Child
> */
>
> /* Close duplicated server FD which we do not in the client */
> close(sock);
>
> /* Do whatever */
> ret = HandleConnection(clnt_sock);
>
> /* close the client socket */
> close(clnt_sock);
>
> /* Exit this server child */
> exit(ret);
> }
> /* We do not need the client socket in the parent process */
> close(clnt_sock);
> }

I do not serve anything So I do not need to fork as only thing I do is to
cliose the socket..

Thanks a lot but originally I discovered this problem then palying with
apache server which is not coded by me.
I didn't want to post anything then the simplest thing which could reproduce
the problem.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:18 EST