Рейтинг@Mail.ru

Наши друзья и партнеры

UnixForum
купить дешевый 
компьютер родом из Dhgate.com




Библиотека сайта rus-linux.net

Назад Сервер TCP/IP ... много серверов хороших и разных Вперед

Сервер с предварительным созданием копий процесса

Так что же получается: для серверов, работающих на высоко интенсивных потоках запросов, с традиционным fork-методом всё так плохо? Отнюдь! Нужно только поменять вызовы fork() и accept() местами – создать заранее некоторый пул обслуживающих процессов, каждый из которых до прихода клиентского запроса будет заблокирован на accept() (кстати, все accept() на одном и том же прослушиваемом сокете, что не предусмотрено спецификацией, но работает!). А после отработки клиентского запроса заблаговременно создать новый обслуживающий процесс. Эта техника известна как «предварительный fork» или pre-fork. Меняем текст сервера (файл ech11.cc):

#include "common.h" 
#include <sys/wait.h> 
const int NUMPROC = 3; 
// ретранслятор c предварительным fork (pefork) 
int main( int argc, char *argv[] ) { 
   int ls = getsocket( PREFORK_PORT ), rs; 
   setv( argc, argv ); 
   for( int i = 0; i < NUMPROC; i++ ) { 
      if( fork() == 0 ) { 
         int rs; 
         while( true ) { 
            if( ( rs = accept( ls, NULL, NULL ) ) < 0 ) errx( "accept error" ); 
            retrans( rs ); 
            close( rs ); 
            if( debug ) cout << i << flush; 
            delay( 250 ); // пауза 250 usec. 
         }; 
      }; 
   }; 
   for( int i = 0; i < NUMPROC; i++ ) wait( NULL ); 
   exit( EXIT_SUCCESS ); 
}; 

Результаты:

$ sudo nice -n19 ./ech11 -v 
waiting on port 51003 ... 
verbose mode 
00210210210210210210

$ ./cli -a 192.168.1.5 -p 51003 -n 20 
host: 192.168.1.5, TCP port = 51003, number of echoes = 20 
time of reply - Cycles [usec.] : 
555370[180]	542984[176]	539994[175]	451536[147]	456090[148]
446096[145]	470856[153]	448753[146]	451605[147]	473512[154]
491579[160]	463611[151]	523503[170]	459356[149]	476031[155]
470672[153]	464738[151]	447155[145]	460655[150]	445211[145]

Очень неплохо! Время реакции приближается к последовательному серверу, но сохраняется параллельность, привносимая fork().

При написании этого текста я несколько схитрил и упростил его логику в сравнении с предложенной выше моделью. Здесь три обслуживающих процесса сделаны циклическими и не завершаются по окончанию обслуживания, а снова блокируются на accept(), но для наблюдения эффектов этого вполне достаточно (а последняя строка примера нужна вообще только для блокировки родительского процесса, и сохранения за процессами управляющего терминала — для возможности прекращения всей группы по ^C):

$ ps -A | grep ech 
10783 pts/15   00:00:00 ech11 
10784 pts/15   00:00:00 ech11 
10785 pts/15   00:00:00 ech11 
10786 pts/15   00:00:00 ech11 

В этом варианте добавлен вывод идентификатора (i) обрабатывающего процесса для идентификации обрабатывающего в каждом случае процесса. Дополнительно добавлена и задержка переактивизации процесса delay(), чтоб заставить обрабатывающие процессы чередоваться. Сервер в примере выше запускался в режиме повышенного уровня диагностики (-v) и можно было наблюдать последовательность активизации обрабатывающих процессов: 00210210210210210210.

В принципе, не так и сложно в такой схеме сделать и динамический пул процессов, как будет обсуждено ниже это для потоков – с той лишь некоторой сложностью, что здесь каждый процесс выполняется в своём закрытом адресном пространстве, и для их взаимной синхронизации придётся использовать что-то из механизмов IPC.


Назад Сервер TCP/IP ... много серверов хороших и разных Вперед

Если вам понравилась статья, поделитесь ею с друзьями: