c сокетами таинственное замедление на ноутбуке Linux с воздушным зазором - PullRequest
0 голосов
/ 10 октября 2018

Я кодировал простой эхо-сервер (из http://gnosis.cx/publish/programming/sockets.html) в C, и все работало хорошо на localhost. Затем я решил попробовать подключиться к серверу в тесном цикле из 10 000 «клиентских» обращений.что я открыл слишком много файлов. Поэтому я сократил до 1022, и это сработало (1022 подключений сделано, данные отправлены и получены). Я также обнаружил, что могу переопределить верхний предел (который также работал, 4094 в непривилегированных, много- 1M? - в привилегированном режиме.) Я чувствовал себя довольно хорошо, но прежде чем заняться такими вещами, как select() или epoll(), я решил провести стресс-тестирование непривилегированного прогона. Я могу подключиться и отправить 4000 (Я избегал около 4096 раз за 0,5 секунды (без регистрации printf()). Я могу сделать это три раза подряд с почти одинаковыми временами. Четвертый раз занимает около 6,0 секунд. А потом я получаю время около 11,0секунд. Та же самая клиентская программа (отправка 4000 5-буквенных слов) НЕИЗМЕННАЯ серверная программа (с значением FIVE только для MAXPENDING) ... Примерно через 3или четыре запуска, где я жду 11.2097 секунд, он возвращается к 0.5 секундам (для трех), затем к 6 секундам, а затем к 11 секундам снова.- Чувствуется, что я использую какой-то пул (около 12 или 13 000?), Который есть для того, чтобы взять, а потом нужно собирать мусор ... медленно ... Я бы с радостью поступил бы по-другому,но я не знаю в чем проблема или ее решение.Я также перенес сервер на виртуальную машину с собственным IP addr с абсолютно идентичными результатами.Может кто-нибудь сказать мне, что может происходить за кулисами и как лучше всего управлять этим?

Я думал, что это может быть решено с помощью setsockopt(TCP_NODELAY), чтобы подавить алгоритм Нейгла, но результаты идентичны:.5, .5, .5, 6, 11, 11, 11 Если сервер повторится как можно быстрее, он временно «рухнет» на несколько секунд.Но в конечном итоге («сбой» или отсутствие «сбой») мы возвращаемся к циклическому отключению 4000 «эхо» за 0,5 секунды.

запуск gcc на 64-битной Ubuntu 18.04 ... gcc -vдает мне:

Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10) 


for(i=0; i<CLIENT; i++)
{
    if (connect(sock[i], (struct sockaddr *) &echoserver[i], sizeof(echoserver[i])) < 0) Die("Failed to connect with server");

    echolen = strlen(argv[2]);
    if (send(sock[i], argv[2], echolen, 0) != echolen) Die("!");

    while (received < echolen) {
      int bytes = 0;
      if ((bytes = recv(sock[i], buffer[i], BUFFSIZE-1, 0)) < 1) Die("!rcv");
      received += bytes;
      buffer[i][bytes] = '\0';
    }
    close(sock[i]);
}

1 Ответ

0 голосов
/ 11 октября 2018

Netstat выигрывает день.Спасибо комментатор Джереми Фризнер.Проблема была в том, что розетки оставались открытыми в состоянии TIME_WAIT.Конечно, я буду продолжать пытаться обойти это.Кажется, TIME_WAIT - это неизбежность.Если это так, я хотел бы иметь возможность поднять MAX_OPEN системы до значения, превышающего 16384. Комментарии по этому поводу более чем приветствуются.Если я решу это, я сам прокомментирую.TIME_WAIT длится ровно 60 секунд на моем ноутбуке.Откуда я это знаю?date; netstat | wc ... Я буду честен, я никогда не был большим поклонником netstat, netcat, nc или других systools, которые извергают объемы информации.Но это был глупый, просвещенный мной.нетстать хорошо.Спасибо другим комментаторам, которые также подтолкнули меня в правильном направлении.Спасибо, парень по имени Тэд ... Спасибо, просто алк ...

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...