Оцените этот текст:


© Максим Мошков. Октябрь-декабрь 1996.
---------------------------------------------------------------
                             Хороший дом, красивая жена,
                             что еще нужно человеку,
                             чтобы достойно встретить старость?
                                                Абдулла

     Уже  год  как  я  использовал  свой  домашний персональный
компъютер в качестве рабочего места WEB-мастера:  Netscape  для
просмотра  документов,  Emacs  для  редактирования  HTML, Apach
HTTPD сервер, Perl 5.0 - все в одном флаконе с Linux  -  и  все
это  на  одного  единственного пользователя. Как вдруг в голову
пришла  светлая,  но  слегка  запоздалая  мысль:  "а   скольких
клиентов сможет обслужить мой домашний WWW сервер?".

        Померить?   Сказано   -   сделано.  Пишем   простенький
perl-скрипт,  который  по  протоколу  HTTP  умеет   запрашивать
документ с сервера в пакетном режиме (действительно, не буду же
я сам мышкой щелкать десять тысяч раз)

       Обкладываем  его вечным циклом, и запускаем в нескольких
копиях фоном на одном терминале. Что-нибудь такое:

    while true
      do
      for document in document1 document2 ... documentN
      do
      wwwclient.pl http://localhost/$document > /dev/null
      date
      done
    done &

     Теперь  остается  только  изредка  поглядывать  на  экран,
наблюдая там примерно такую картину:

Wed Sep 11 23:00:22 MSD 1996
Wed Sep 11 23:00:23 MSD 1996
Wed Sep 11 23:00:24 MSD 1996
Wed Sep 11 23:00:26 MSD 1996
Wed Sep 11 23:00:27 MSD 1996
     . . .



IBM PC 486dx2/80 20Mb RAM, 1.6Gb IDE
Unix:  Linux 1.2.13,
httpd: Apach 1.1.1
Perl:  5.0
Squid: 1.1.beta27   (proxy-cashe, http-acselerator)



      Все скрипты (в первом и третьем тесте 10, во втором 20) я
запустил фоном с одного терминала -  поэтому  считать  скорость
обслуживания  было  легко: за сколько времени отрабатывается 23
запроса (ровно один терминал)

       Вывод  1. Среднее время МЕЖДУ обслуживаниями запросов НЕ
ЗАВИСИТ от числа одновременно запущенных  клиентов,  т.е.  если
один  клиент в монопольном режиме обслуживался за 1 секунду, то
20 одновременно пришедших клиентов обслуживались за  20  секунд
каждый.

       В  первом  тесте  я запрашивал одновременно по 10 URLей,
являющихся перловскими CGI-скриптами, генерящими от 10  до  400
Кб  HTML,  во  втором  -  по 20 обычных HTML-файлов аналогичных
размеров.  В  третьем  тесте  я   сконфигурировал   на   машине
http-акселератор и запрашивал 10 CGI-скриптов сквозь него.

       10 perl-CGI-скриптов

Темп обслуживания:           Один скрипт в 2.6 сек
                             (1,000,000 файл-запросов в месяц)
Скорость обслуживания:       26 секунд на один/10 документ
Загрузка виртуальной памяти: 25 Мб

       20 HTML документов

Темп обслуживания:           Один документ в 0.65 сек
                             (4,000,000 файл-запросов в месяц)
Скорость обслуживания:       13 секунд на один/20 документ
Загрузка виртуальной памяти: 15 Мб

       10 HTML-документов через HTTP-акселератор

Темп обслуживания:           Один скрипт в 0.73 сек
                             (3,700,000 файл-запросов в месяц)
Скорость обслуживания:       14 секунд на один/10 документ
Загрузка виртуальной памяти: 10 Мб

        Замечу,   что   при   работе  CGI-скриптов  машина  еще
удовлетворительно  откликалась  на  внешние   раздражители,   и
достаточно  сносно  отрабатывала команды редактирвания в Emacs,
но  гонять  в  это  время  Netscape  было  уже  нереально.   20
одновременных  клиентов  съели машину на 100% - ни на что кроме
WWW оба уже была неспособна - мышка по экрану прыгала  скачками
по 10 сантиметров, а фокус в окошко переключался с задержкой от
5  до  30  секунд.  Загрузка  процессора  в  третьем  тесте   с
ускорителем была 50%.



     CGI-скрипты  потребляют  примерно  в  2 раза больше памяти
компьютера и создают примерно в 5  раз  большую  вычислительную
нагрузку.   Ввиду   этого   рекомендуется   по  возможности  не
использовать их слишком широко на сильно загруженных  серверах,
обходясь обычными HTML-файлами.
       Использование  http-акселератора  оказалось  оптимальным
решением    проблемы     CGI-скриптов.     Скорость     отклика
прокэшированного CGI-скрипта практически равна скорости отклика
обычного html-документа, а загрузка компьютера даже меньше, чем
при работе штатного http-сервера.
       Интенсивно  нагруженный WWW сервер НЕ СТОИТ использовать
еще и как посадочное графическое место.

       В  настоящее  время  (осень  1996) даже самые крупнейшие
WWW-сервера  в  России   имеют   загрузку   порядка   1-2   млн
файл-запросов  в месяц (и пересчитать их можно по пальцам одной
руки), остальные - и того меньше. Как  видно  из  тестов,  даже
дешевенький (1000$) 486 компьютер в состоянии потянуть нагрузку
самых  популярных  WEB-серверов  России.   Покупать   под   WWW
дорогостоящие UNIX-серверы (SUN, HP, DEC... стоимостью от 10 до
40 тысяч $) - НЕРЕНТАБЕЛЬНО и бессмыслено.



IBM PC Pentium 100-133 Mhz,
               32-64 Mb RAM,
               1-2 Gb HD (SCSI или IDE)
               монитор, видеокарта - любые, самые дешевые
Операционая система:  FreeBSD, Linux, 
HTTPD сервер:         Apach 1.2.*
HTTP-акселератор:     Squid 1.1.*

     Такая  конфигурация  обойдется в 1.5-2 тысячи $ и выдержит
среднюю загрузку 1-5  млн  запросов  в  месяц  с  5-20  кратным
запасом прочности на вырост.
      Для сервера средней  руки вполне хватит даже 486dx4/100 с
16 Mb RAM
					

Last-modified: Mon, 01 Sep 1997 05:39:30 GMT
Оцените этот текст: