Платформа для WWW сервера

Платформа для WWW сервера

 
  • Платформа для WWW сервера
  • Спецификации тестируемого сервера
  • Результаты тестов
  • Выводы
  • Оптимальная конфигурация WWW сервера

  • © Максим Мошков. Октябрь-декабрь 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 тысяч $) - НЕРЕНТАБЕЛЬНО и бессмыслено.

    Оптимальная конфигурация WWW сервера


    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


    Home | UK Shop Center |Contact | Buy Domain | Directory | Web Hosting | Resell Domains


    Copyleft 2005 ruslib.us