Предисловие
Началась эта история из-за того, что мне не понравился SQUID. Рискуя быть оплеванным сквидофилами все равно скажу - для меня это крайне неудобная софтина.
Прежде всего в администрировании. Также мне не понравилась скорость работы SQUID'a, но это обстоятельство вытекает из его "неродной" для OS/2 природы.
Юниксоиды (и им сочувствующие:), конечно же, со мной не согласятся, но их можно понять. У них ведь, по большому счету, ничего функионально подобного
SQUID'у в качестве кеширующего прокси нет, так что им волей-неволей приходится восхищаться SQUID'ом. В OS/2 же, к счастью, ситуация не такая безвыходная.
В природе есть нативные ОСевые кеширующие прокси! Одному из них и посвящен данный обзор.
Кто есть кто
Сразу же хочу сказать, что IBM WEB Traffic Express (в дальнейшем - WTE) не единственный нативный кеширующий прокси.
Есть еще IBM Internet Connection Server, IBM Internet Connection Secure Server, а так же Lotus GO WEB Server. Если последний является практически 100%
функциональным аналогом WTE, то два первых - это довольно древние программы, хотя тоже вполне работоспособные. WTE занимает в этом ряду как бы среднюю
позицию. Он старше ICS(S)'ов, но моложе Lotus GO WEB Server'a. Хотя, как я уже говорил ранее, IBM WTE - функционально практически аналогичен Lotus GO WEB
Server'у. Мой выбор WTE для этого обзора обусловлен только практическими соображениями. У меня сейчас есть в распоряжении OS/2 интранет-сервер, на котором
в качестве кэширующего прокси работает WTE v1.1.2. Забегая немного вперед скажу, что и SQUID там тоже имеется :). Есть у нас сквидофилы, которым нравится
ходить в инет именно через SQUID. :)
Что из себя представляет IBM WEB Traffic Express ?
Это прежде всего полнофункциональный WEB-сервер с поддержкой CGI, JSP, авторизацией пользователей и т.д. Тем, кому интересны все его возможности, я
рекомендую почитать документацию идущую в пакете с дистрибутивом. Данный же обзор посвящен одной из возможностей WTE - умение работать как кеширующий
прокси сервер. Причем он может работать в цепочке других прокси-серверов. Наш WTE именно так и настроен. Есть главный кеширующий прокси (у провайдера) и
наш WTE выходит в инет через него. Думаю, что сторонникам командной строки, T-Shell, detach, а также тем, кто любит после установки отдирать от серверов
клавиатуры, мониторы и вообще все, что только можно отодрать оставив голую коробку системного блока лучше дальше не читать ибо это просто "ужасно"!
У WTE PM интерфейс! (в зале слышны плевки, улюлюканья и хлопанье дверями). Ну, что ж, любителям "гнуть пальцы" - скатертью дорога...
Для тех, кто остался, я продолжаю свое повествование. Итак, у WTE графический интерфейс.
Вот его внешний вид:
На примере приведенного скриншота хорошо видно, что администратор может наблюдать в реальном времени количество активных соединений, число открытых тредов,
размер входящего и исходящего траффика, а открыв лог-закладки можно увидеть кто и что делает в настоящий момент. На самом деле если
WTE активно используется, то Вы не будете успевать отслеживать быстро меняющуюся информацию на лог-закладках. Скажу даже, что в этом случае ее вывод
лучше вообще отключить так как это создает лишнюю нагрузку на сервер. Всю эту информацию Вы сможете получить из лог-файлов. Лог-файлы разделены по функциональному
назначению. Их количество, а также формат можно настраивать.
Инсталляция и настройка параметров WTE
Насколько мне известно в виде отдельных дистрибутивов существуют 3 версии WTE: 1.0, 1.1.1 и 1.1.2.
На самом деле их, конечно же, больше. Могу сказать, что WTE является составной частью IBM WEB Sphere серверов, а они существуют не только для OS/2 платформы,
но давайте остановимся на последней "одиночной" версии WTE - 1.1.2.
Процесс инсталляции не должен вызвать у Вас сложностей. Там все очень просто и понятно. Единственное, что я хочу сказать в плане перевода WTE "на рельсы"
кешируюшего прокси (а не HTTP-сервера) - указание порта отличного от стандартного 80 порта для HTTP протокола при соответствующем запросе инсталлятора.
У меня, к примеру, WTE "сидит" на 8080 порту (3128-й порт занят сквидом). В принципе, все эти настройки можно спокойно внести и после инсталляции, так
что не огорчайтесь если "упустили момент".
Если Вы не меняли путей, предлагаемых инсталлятором, WTE установится в каталог \WWW на Вашем диске.
Исполняемые файлы лежат в \WWW\BIN, лог-файлы - в \WWW\LOGS и т.д. Учитывая то обстоятельство, что кеширующий прокси сервер много работает с диском,
а также наличия файлов с длинными именами я настоятельно рекомендовал бы Вам устанавливать WTE на HPFS раздел. Для увеличения производительности можно установить
HPFS386 драйвер. Поверьте мне - не пожалеете!
Итак, инсталляция завершена и Вам предлагается перегрузиться. Это требование связано с добавлением путей и переменных в CONFIG.SYS. Перегружайтесь.
После перезагрузки можно приступать к конфигурированию WTE. Это, пожалуй, самый главный этап всей работы и он потребует от Вас внимания и понимания того, что Вы
делаете. Конфигурирование само по себе не представляет технической сложности. Конфигурационный файл WTE называется httpd.cnf и располагается там, куда
указывает системная переменная %ETC% - обычно это \MPTN\ETC каталог. HTTPD.CNF является обычным текстовым файлом в котором для каждого параметра
присутствует целый блок комментариев (правда на английском). Т.е Вы можете редактировать этот файл из любого текстового редактора, а чтобы WTE воспринял изменения
необходимо его перезапустить. Те, кто уже знаком с настройкой параметров SQUID'a, ничего нового пока не узнали, однако у WTE есть очень удобная возможность настройки
с удаленного компьютера. Нет, не телнетом, хотя можно и им, но это было бы слишком "в лоб". Оставим телнет сквидофилам. :)
Хочу напомнить, что WTE является в первую очередь полноценным WWW-сервером и неудивительно, что IBM предусмотрела возможность редактирования параметров в HTTPD.CNF
из любого WWW-броузера, с любой машины в сети. Потребуется только пройти авторизацию. Указать имя и пароль администратора. Подобное конфигурирование может и несколько
медленнее, но гораздо более информативно и удобно (особенно для начинающих администраторов). Если для задействования изменененных параметров необходим перезапуск
WTE, то WWW-интерфейс Вам нарисует кнопочку "Restart" нажав которую на WTE отправится команда о перезапуске. Обратите внимание - в этом случае задача WTE не
закрывается! Просто сервер останавливается и стартует снова. Этот процесс наглядно отображается в его PM окошке.
Раз уж мы заговорили о наглядности PM окошка и удаленном WWW управлении было бы неплохо это PM окошко наблюдать на той машине, с которой осуществляется управление.
WTE и это позволяет сделать. Естественно графический вид окошка не передается. Передаются только основные параметры отображаемые в нем. Любознательные админы сами найдут
как добраться до этой возможности, а для ленивых админов :) я укажу конкретную ссылку: "Server Activity Monitor" = http://WTE_host_address:порт/Usage/Initial
На страничке мониторинга 4 ссылки: "Basic status", "Network status", "Access log" и "Proxy log", а также кнопка "Refresh now" для
обновления вывода.
Рассказывать про удаленное управление WTE через WWW-интерфейс можно очень долго и много, но так как там все понятно даже на интуитивном уровне я ограничусь темой данного
обзора. Итак, давайте рассмотрим...
Параметры отвечающие за работу WTE в качестве кеширующего прокси
Для перевода WTE в режим кеширующего прокси сервера необходимо установить значение параметра "Port" в отличное от 80.
Например:
# Port directive:
#
# Port used by the server.
# NOTE: If you are not root, you have to use a port above 1024;
# good defaults are 8000, 8001, 8080.
#
# Default: 80
# Syntax: Port {num}
Port 8080
Следующий блок параметров отвечает за количество лог-файлов, которые будут вестись сервером:
# If you want logging, specify locations for your logs:
#
# AccessLog - used for logging local document requests
# AgentLog - used for logging browser requests
# RefererLog - used for logging requests which are refered
# ErrorLog - used for logging any errors
# CgiErrorLog - used for logging any CGI errors
# ProxyAccessLog - used for logging proxy requests
# CacheAccessLog - used for logging hits on proxy cache
# (only valid if server running as proxy)
#
# NOTE: To enable logging of requests to the proxy cache, the
# following must be defined:
#
# Caching MUST be turned ON (default is OFF)
# CacheRoot MUST be defined (by default, no CacheRoot is defined)
# CacheAccessLog MUST be defined
#
# Defaults: AccessLog d:\www\logs\httpd-log
# AgentLog d:\www\logs\agent-log
# RefererLog d:\www\logs\referer-log
# ErrorLog d:\www\logs\httpd-errors
# CgiErrorLog d:\www\logs\cgi-error
# Syntax: {directive} {fullpath-filename}
# Example:
ProxyAccessLog C:\WWW\LOGS\proxy-access
CacheAccessLog C:\WWW\LOGS\cache
ErrorLog C:\WWW\LOGS\error
AccessLog C:\WWW\LOGS\access
AgentLog C:\WWW\LOGS\agent
RefererLog C:\WWW\LOGS\referer
CgiErrorLog C:\WWW\LOGS\cgi-error
Хочу обратить Ваше внимание, что в качестве extension для данных файлов WTE ставит дату их создания.
Т.е полные имена лог-файлов будут, например, такими:
proxy-access.Aug312001
cache.Aug312001
error.Aug312001
access.Aug312001
agent.Aug312001
referer.Aug312001
cgi-error.Aug312001
Это очень удобно для администратора в плане организации выборки за определенный период.
Для анализа лог-файлов и составления красивых отчетов я настоятельно рекомендую использовать анализатор логов компании WEB Trends.
К сожалению это Win32 приложение и оно не бесплатное, но ничего удобнее и лучше для подобной работы Вы просто не найдете. Я перепробовал несколько
анализаторов и остановил свой выбор именно на "WEB Trends Log Analizer".
Тем, кому он тоже понравится, я могу рассказать как умерить его меркантильный пыл. :)
Далее идут несколько блоков параметров также посвященных лог-файлам (формат логов, размер, вывод в PM-окно WTE и т.д.). Думаю Вы сами разберетесь какие параметры за
что отвечают. Каждый блок параметров снабжен достаточными комментариями.
Следующий блок параметров (Mapping rules) является, пожалуй, самым интересным. Он отвечает за перенаправление(маппирование) запроса пользователя на определенный ресурс
если запрос совпал с неким шаблоном. Как многие уже догадались - это тот самый фильтр баннеров, рекламы и порнографии, который будет вырезать все то, извиняюсь за
выражение, информационное дерьмо, которым в последнее время буквально кишит интернет. Для организации фильтра контента достаточно всего двух директив: Pass и Fail.
В качестве примера приведу часть своего фильтра контента:
Pass http://ad*.*.*/* C:\WWW\ICONS\empty.gif
Fail http://ad*.*.*/*
Pass http://az.yandex.ru/* C:\WWW\ICONS\empty.gif
Fail http://az.yandex.ru/*
Pass http://banne*.*.*/* C:\WWW\ICONS\empty.gif
Fail http://banne*.*.*/*
Pass http://www.penilesecrets.com/* C:\WWW\ICONS\empty.gif
Fail http://www.penilesecrets.com/*
Pass http://ww*.yandex.ru/cgi-bin/* C:\WWW\ICONS\empty.gif
Fail http://ww*.yandex.ru/cgi-bin/*
Pass http://*.linkexchange.*/* C:\WWW\ICONS\empty.gif
Fail http://*.linkexchange.*/*
Pass http://ww*.reklama.ru/* C:\WWW\ICONS\empty.gif
Fail http://ww*.reklama.ru/*
Pass http://affiliate.km.ru/img/* C:\WWW\ICONS\empty.gif
Fail http://affiliate.km.ru/img/*
Как Вы видите каждое правило представлено парой директив. Первая директива - Pass указывает прокси серверу к какому ресурсу он должен обратиться при совпадении запроса
пользователя с шаблоном указанным в качестве параметра этой директивы, а вторая - Fail собственно и является фильтром. Она запрещает обращение к ресурсу указанному в
качестве ее параметра. Рассмотрим действия WTE на нашем примере фильтров контента. Если броузер пользователя попытается обратиться к ресурсу, к примеру,
http://ads.firma.com/banner.gif, то сработают 2 директивы:
Pass с параметром "http://ad*.*.*/* C:\WWW\ICONS\empty.gif"
и
Fail с параметром "http://ad*.*.*/*"
Первая директива перенаправит данный запрос на локально расположенную (для WTE) картинку empty.gif, а вторая - запретит обращение к любым ресурсам сайта http://ads.firma.com/
В принципе для организации фильтра достаточно одной директивы Fail, но тогда на тех местах страничек, на которых должны "красоваться" реламно-порнушные баннеры, Вы бы
наблюдали "дырки" с надписями "403 Forbidden by rule.", что, согласитесь, в плане эстетичности выглядит не очень привлекательно. Исправляет положение директива Pass,
выполняющая подстановку катринки из файла empty.gif, на место того самого вырезанного баннера.
Что представляет из себя эта картинка? Да что угодно! Конкретно мой empty.gif представляет из себя прозрачное изображение размером 1х1. Т.е это просто невидимая
картинка. Таким образом в окне броузера баннеры не только дезактивируются (с помощью Fail), но и становятся невидимыми (с помощью Pass).
К сожалению WTE не умеет налету залезать в поток данных для вырезания JavaScript выпоняющего открытие новых окон броузера (обычно рекламно-порнушного содержания), но все же можно попытаться
если и не предотвратить это, то хотя бы запретить броузеру обращаться по этим адресам. Для этого достаточно директивы Fail с самыми общими щаблонами.
У меня они имеют вид:
Fail http://*porn*/*
Fail http://*sex*/*
Fail http://*xxx*/*
Fail http://*erot*/*
Fail http://*fuck*/*
Fail http://*hardcore*/*
Т.е. если в имени запрашиваемого URL встречается группа символов совпадающая с шаблоном - в открываемом новом окне броузера Вы увидите всего одну надпись "403 Forbidden by rule."
Применение правил фильтрации контента способствует не только ощутимому сокращению ненужного траффика, но и улучшению чисто эстетического вида страниц. Мне, например, очень неприятно наличие на экране
дергающихся картинок слепленных какими-то козлами-"уеб дизайнерами" и необходимых (как они думают) для увеличения посещаемости их козлиных узлов...
По-моему мнению эта дрянь может вызвать желание нажимать на нее только у абсолютных дебилов или т.п. контингента, а у нормальных людей она вызывает только чувство раздражения.
Следующие блоки параметров (Performance directives) отвечают за настройку производительности прокси сервера. Как и в любой другой области деятельности производительность чего либо будет
максимальной только в случае индивидуального подхода к типу решаемых задач. Давайте рассмотрим блоки параметров отвечающие за производительность прокси сервера WTE. Итак:
# MaxActiveThreads directive:
#
# Defines the maximum number of threads in system thread pool.
#
# Default: 40
# Syntax: MaxActiveThreads {num}
MaxActiveThreads 32
Этот параметр указывает максимально допустимое количество одновременно открытых нитей (тредов). Я рекомендую подбирать его основываясь на пиковом числе одновременно поступающих к WTE пользовательских
запросов. Каждому пользователю, в среднем, выделяется по 2 треда. Вы, конечно же, можете сразу влепить сюда 200 или более тредов, но дело в том, что чем больше тредов зарезервировано, тем больше памяти
будет отъедать WTE и тем медленнее будет он работать. Многие скажут, ну и что? У меня вот памяти 1000Гб и процессор PXXXXX-10000000. Ну, что ж, ставьте тогда сколько хотите тредов, а для тех у кого нет
в наличии такого железа я еще раз повторю, что "все хорошо лишь в меру"(с). Если действовать по-уму, то можно будет обойтись и 486-м процессором с 32Мб памяти. У меня самого PII-400, да и памяти 256Мб,
но тем не менее для оптимального быстродействия мне хватает всего 32-х тредов. Я установил это число экспериментально. Постепенно понижал его со 100.
А вот тут у меня стоит число в 2 раза превышающее значение по-умолчанию.
# MaxPersistRequest directive:
#
# Maximum number of request to receive on a persistent connection.
#
# Default: 100
# Syntax: MaxPersistRequest {num}
MaxPersistRequest 200
Дело в том, что у нас народ любит качать файлы разными FlashGet'ами и GetRight'ами, которые в свою очередь очень любят открывать
неcколько download-ниток. В результате получается, что некоторым клиентам надо выделить несколько соединений на один и тот же URL. Возможно мое число 200 является немного завышенным (я просто его как
следует не отлаживал с целью выяснения оптимального значения).
# ServerPriority directive:
#
# Default: 1
# Syntax: ServerPriority {0 | 1 | 2}
#
# Note: This is the priority on your system you want your server to run.
# 0 - background process (no priority)
# 1 - maximum priority as a background process
# 2 - maximum priority as a foreground process.
ServerPriority 1
Здесь - как по умолчанию. Приоритет = 1. Его вполне хватает для работы без задержек. Но это у меня, а у Вас его может оказаться недостаточно. Особенно если существуют ограничения по аппаратной части.
Поэтому еще раз напомню - подбирайте параметры исходя из своей конкретной ситуации.
Тайм-аут параметры (Timeout directives) тоже можно отнести к параметрам связанным с производительностью.
#
# Use these directives to:
# * limit the time to wait for the client to send a request
# after connecting to the server before cancelling the connection.
# * limit the time to allow for sending output to the client.
# * limit the time to allow for server scripts to finish.
# (If the program does not finish within allotted time, the server
# will send a TERM signal and then a KILL signal 5 seconds later
# to stop the program.)
# * limit the time to wait for the client to send a request
# after establishing a persistent connection to the server
# before cancelling the connection.
#
# Default: InputTimeout 2 minutes
# Default: OutputTimeout 20 minutes
# Default: ScriptTimeout 5 minutes
# Default: PersistTimeout 10 secs
# Syntax: {directive} {time-spec}
InputTimeout 30 secs
OutputTimeout 20 minutes
ScriptTimeout 5 minutes
PersistTimeout 10 secs
У нас, к примеру, довольно дохлый канал в интернет и ждать 2 минуты на "InputTimeout" просто нет смысла. Если URL не загрузился в течение 30 сек. это значит, что запрос просто "повис" и необходимо его
еще раз принудительно "пнуть" чтобы ожил. :)
Теперь рассмотрим несколько блоков параметров управляющих прокси-сервером в цепочке других прокси.
#
# Specify the protocols that this proxy server will forward:
#
Proxy http:*
Proxy ftp:*
#Proxy gopher:*
Здесь указаны протоколы которые будут перенаправляться нашим WTE на следующий прокси сервер в цепочке.
Честно говоря мне никогда не доводилось сталкивался на практике с протоколом "gopher" посему я его просто
закомментировал.
А в этом блоке параметров Вы указываете адрес следующего прокси сервера, причем хочу обратить Ваше внимание,
что для разных протоколов можно указать разные прокси сервера!
#
# Proxy-to-Proxy directives:
#
# Pass requests for a particular protocol to another (proxy) Web Server
# instead of contacting the the system named in the URL.
#
# Default: {none}
# Syntax: {request_proxy} {URL}
#
# Example:
http_proxy http://192.168.1.15:3128/
ftp_proxy http://192.168.1.15:3128/
# gopher_proxy gopher://other.proxy.name/
Т.е в моем случае запись "ftp_proxy http://192.168.1.15:3128/" не ошибка! На нашем следующем прокси в цепочке запрещен FTP протокол. Обрабатываются только HTTP запросы.
Следующий блок параметров отвечает за "хождение напрямую". Т.е можно указать WTE, что запросы определенных адресов не надо проксировать.
#
# no_proxy directive:
#
# Specify the domains to which the server should directly connect.
# Specify the value as a string of domain names or domain name
# templates. Separate each entry in the string with a comma.
#
# Do NOT put any spaces in the string.
# You CANNOT use the wildcard character (*).
# You CAN specify a template by including only the last part of a domain name.
#
# Default: {none}
# Syntax: no_proxy {non-proxy domain specification}
#
# Example:
no_proxy .ourdomain.ru,.ourdomain.net,192.168,10.10
Теперь давайте рассмотрим какие параметры у WTE отвечают за кеширование информации.
Ну, для начала, было бы неплохо включить саму возможность кеширования:
#
# Turn on proxy caching here.
#
# NOTE: You MUST also specify the CacheRoot directive.
#
# Default: off
# Syntax: Caching {on | off}
Caching on
Потом надо указать где, собственно, Вы собираетесь хранить кеш:
#
# CacheRoot directive:
#
# Specify the directory that the server will use for caching files.
# If this directory is not specified, the proxy server will not attempt
# to cache documents.
#
# NOTE: If this directive is specified using the Configuration and
# Administration forms, the directory will be created automatically.
# If you define the directory by manually editing the configuration
# file, you need to create the directory with the appropriate
# permissions to enable the server to cache documents in it.
#
# NOTE: You MUST also turn "on" the Caching directive.
#
# Default: {none}
# Syntax: CacheRoot {directory}
#
# Example:
CacheRoot c:\www\cache
Хочу повторить еще раз, что я очень рекомендую использовать HPFS386 драйвер, так как работа
WTE с кешем, особенно при большом количестве пользовательских запросов, требует очень
хорошей отдачи от дисковой подсистемы компьютера. HPFS386 служит для облегчения нагрузки на
дисковую подсистему так как умеет поддерживать размеры дискового кеша больше "стандартных" 2 Мб.
Следующий блок параметров отвечает за установку срока хранения информации в кеше.
#
# CacheDefaultExpiry directive:
#
# Specify the expiry date for files which do not include an explicit
# expiry date and do not have a last-modified date that would allow us
# to compute an expiry based on the CacheLastModifiedFactor. This is
# most useful for protocols that do not have any way to transmit this
# information, such as FTP or Gopher.
#
# NOTE: The default expiration for HTTP is 0. HTTP should be kept at 0
# because many script programs don't give an expiration date, yet
# their output expires immediately. A value other than zero may
# cause problems.
#
# Defaults: http:* 0 days
# ftp:* 1 day
# gopher:* 2 days
# Syntax: CacheDefaultExpiry {URL pattern} {time period}
#
# Example:
# CacheDefaultExpiry ftp:* 1 hour
CacheDefaultExpiry http:* 0 days
CacheDefaultExpiry ftp:* 1 day
# CacheDefaultExpiry gopher:* 2 days
Для HTTP запросов установлен нулевой период истечения, из-за наличия на страничках скриптов динамически генерирующих контент,
и если Вы установите сюда значение отличное от нуля, то можете получить проблемы с отображением информации с некоторых сайтов.
А вот этот блок отвечает за настройку временного промежутка хранения неиспользующихся файлов в кеше WTE. Забегая немного
вперед скажу, что процесс автоматического удаления неиспользуемых файлов из кеша называется Garbage Collection.
#
# CacheUnused directive:
#
# Specify how long the proxy cache should keep files which have not
# been used (requested by a client). Unused files which have been in
# the cache longer than this will be removed during garbage collection.
#
# Default: {none}
# Syntax: CacheUnused {URL pattern} {time period}
#
# Example:
CacheUnused ftp:* 1 day
CacheUnused http:* 2 days
# CacheUnused gopher:* 1 day
Следующий блок параметров отвечает за установку верхнего и нижнего лимитов на размер кешируемых файлов:
#
# CacheLimit_1 and CacheLimit_2 directives:
#
# The caching system has two limits for filesizes. The upper limit
# (CacheLimit_2) specifies the maximum size for any file that will be
# cached. The lower limit (CacheLimit_1) is used by the garbage-collection
# algorithm to decide what pages to remove from the cache. Any files smaller
# than the lower limit will not have their size considered when the server
# decides what files to remove from the cache; files larger than the
# lower limit are progressively more likely to be removed from the cache.
# The value for CacheLimit_1 and CacheLimit_2 can be specified in
# bytes (B), kilobytes (K), megabytes (M), or gigabytes (G).
#
# Default: CacheLimit_1 20 K
# CacheLimit_2 400 K
# Syntax: CacheLimit_1 {bytes} {B|K|M|G}
# CacheLimit_2 {bytes} {B|K|M|G}
#
# Example:
# CacheLimit_1 4 K
# CacheLimit_2 64 K
CacheLimit_1 20 K
CacheLimit_2 400 K
При выполнении процедуры очистки кеша (Garbage Collection) файлы размером меньше нижнего лимита (CacheLimit_1)
не участвуют в отборе выполняемом правилами этого процесса. В этом оборе участвуют файлы размер которых лежит
между CacheLimit_1 и CacheLimit_2 значениями. Верхний лимит (CacheLimit_2) также служит для указания WTE максимально
допустимого размера кешируемого файла. Т.е в данном случае файлы размером более 400Кб не будут помещаться в кеш.
А вот этот блок параметров отвечает за установку периода в течении которого кешированный файл будет заблокирован
для изменения:
#
# CacheLockTimeOut directives:
#
# Specify how long a file being cached can remain locked.
#
# NOTE: Set CacheLockTimeOut to a value equal to
# or greater than OutputTimeOut.
#
# Default: 20 Mins
# Syntax: CacheLockTimeout {num} Mins
#
CacheLockTimeOut 20 Mins
Т.е даже если на сайте, с которого Вы скачивали этот файл, изменился его размер(но не имя), при Ваших повторных попытках
скачать этот файл в течении 20 минут Вы будете получать его не с сайта, а из кеша WTE. С одной стороны можно подумать, а
зачем же тогда вообще ввели этот дурацкий параметр? Но если подумать получше, то можно понять, что это сделано с целью
увеличения производительности сервера так как вероятность Вашего попадания на изменение содержимого файла при сохранении
его имени гораздо ниже, чем вероятность запроса этого же файла другим пользователем WTE.
Данный блок параметров отвечает за указание URL с которых только либо надо кешировать, либо вообще не надо кешировать.
Чаще всего этот блок параметров закомментирован, так как редко кому нужны подобные крайности, но все же он есть и этот
факт только добавляет WTE функциональности:
#
# CacheOnly and NoCaching directives:
#
# The server allows control over the files to be cached in two ways.
#
# CacheOnly - specifies a set of URLs which will be considered for
# caching (URLs not in that list will never be cached)
# NoCaching - specifies a set of URLs which must never be cached,
# (all other URLs are candidates for caching)
#
# Default: {none} (for both CacheOnly and NoCaching)
# Syntax: CacheOnly {URL pattern}
# NoCaching {URL pattern}
#
# Example:
# CacheOnly http://www.ibm.com/*
# NoCaching http://www.ourdomain.ru/*
Следующий блок отвечает за установку размера кеша (в мегабайтах) на диске компьютера. Это весьма важный и
полезный параметр и его, как и остальные параметры, надо устанавливать хорошенько поразмыслив над вопросом о
достаточности не в ущерб производительности:
#
# CacheSize directive:
#
# Specify the size of the proxy server's cache (in megabytes).
#
# Default: 5 M (5 megabytes)
# Syntax: CacheSize {size} M
#
# Example:
# CacheSize 20 M
CacheSize 500 M
Ну, вот мы и добрались до той самой загадочной "мусорной коллекции", которая призвана очищать кеш от "ненужных"
файлов. Итак, основной управляющий параметр - это разрешение или запрещение этого процесса в принципе:
#
# Gc (Garbage Collection) directive:
#
# In order for a caching proxy server to function efficiently, it needs to
# sweep through the cache and remove out-of-date files on a regular basis.
# This is called 'garbage collection'. It should only be turned "off" in
# special circumstances, such as during an extended network outage.
#
# Default: on
# Syntax: Gc {on | off}
Gc on
В данном случае GC разрешена. И в дело вступают дополнительные блоки параметров. Первый из которых указывает WTE когда
он должен выполнять этот процесс. Подразумевается, что GC должна выполняться ежедневно.
#
# GcDailyGc directive:
#
# Because garbage collection can take a significant amount of CPU resources,
# it should be scheduled to take place when the load on the proxy server is
# low. Use this directive to specify the time for garbage collection, using
# a 24-hour clock; this will be assumed to be local time (not GMT).
#
# Default: 03:00
# Syntax: GcDailyGc {hh:mm}
#
# Example:
GcDailyGc 03:00
В данном случае я согласился со значением по умолчанию и установил время запуска в 3 часа ночи.
Как и любому процессу GC нужна оперативная память для ее выполнения. Следующий блок параметров как раз
отвечает за это:
#
# GcMemUsage directive:
#
# Used to restrict the amount of memory used by the garbage collection
# process. Memory usage is specified in Kbytes (only). Setting this to
# a small value will cause garbage collection to be extremely inefficient.
# The minimum value is 20.
#
# Default: 1000
# Syntax: GcMemUsage {Kbytes}
#
# Example:
GcMemUsage 32000
Как я уже говорил выше та машина, на которой установлен наш WTE, имеет 256Мб памяти, поэтому я спокойно
могу выделять 32Мб на выполнение процедуры очистки кеша.
На этом мой обзор WTE, как кеширующего прокси сервера, завершен. Я надеюсь, что смог доходчиво и в полной
мере рассказать как использовать этот продукт в данном качестве и с помощью этого обзора Вы сможете настроить
WTE для решения Ваших задач. Но если вдруг Вам все же что-то непонятно или же Вы считаете, что некоторые
вопросы недостаточно полно освещены в этой статье, то я настоятельно рекомендую Вам прежде чем обращаться с
расспросами к автору или в различные конференции - почитайте документацию. Она у WTE очень полная и там все
очень подробно изложено. Думаю Вам удастся найти ответы на Ваши вопросы в первую очередь именно там.
Также хочу сказать: не бойтесь экспериментировать с параметрами! (естественно не наобум, а сознательно)
Ничего плохого не случится. Максимум что может быть - просто неработоспособный прокси, но, с другой стороны,
если Вам удастся его настроить под свои задачи, Вы получите ни с чем не сравнимый практический опыт, который
поможет Вам же в дальнейшей работе.
К сожалению я знаю только одну ссылку на файл с дистрибутивом
WTE версии 1.1.2 и DLL отучающую данный WTE от триальности, но в
принципе все вышесказанное применимо и к другим версиям WTE, а также Lotus Go WEB Server (который вообще freeware). Так что
если Вам не удастся достать именно WTE 1.1.2 - у Вас в запасе есть еще несколько вариантов. :)
PS: Хочу попросить прощения у владельца сервера ftp://ftp.kot.spb.ru за то, что без его разрешения опубликовал ссылку на его
ресурсы, но так как она была получена абсолютно легальным образом (через www.filesearch.ru) я думаю, что моя вина не очень уж
велика.
|
