Разделы учебника
- Скачать Apache
- Компиляция источника
- Используя Apache
- Знай свои директивы
- Серверная часть Включает
- Сделай работу этих CGI
- Документы об ошибках
- Согласование контента
- Один файл конфигурации
- Вращающиеся журналы
- Получить некоторые дополнительные
- Купить книгу
- Поиск файлов
- Поиск имени хоста
- Согласование контента
- аппаратные средства
- Серверные процессы
Давайте начнем тогда, не так ли?
Вступление
У большинства людей качество и популярность ассоциируются с ценой. В Интернете, однако, это не так. Какой самый популярный веб-сервер самого высокого качества доступен?
- Сервер Netscape-Enterprise? Неправильно.
- Microsoft-IIS? Опять не так
- Apache? Бинго, и ошеломляющим количеством.
Согласно опросу Netcraft, проведенному в декабре 1999 года компанией Netcraft ( Slashdot , TheFinancial Times , Linux.com и JavaSoft, не говоря уже о множестве других сайтов).
Проект Apache ( http://www.apache.org/ ) начался в 1995 году, когда группа веб-мастеров решила, что им нужен стабильный, мощный сервер для будущего сайта (одним из этих сайтов был http: //www.hotwired. ком / ). В то время самое популярное серверное программное обеспечение, доступное в Интернете, было разработано Национальным центром приложений для суперкомпьютеров (NCSA). Разработчик, Роб МакКул, покинул организацию, и все разработки застопорились. В то время веб-мастера создавали свои собственные расширения и исправления ошибок для сервера, но они не распространялись никоим образом. Группа веб-мастеров решила координировать изменения на сервере, который позже стал известен как «патчи». Вот как сервер Apache получил свое имя: A-Patchy Server. Через год после выпуска Apache Server небольшая группа хакеров создала сервер № 1 в Интернете.
Возможность просмотра исходного кода для сервера является одним из его самых больших преимуществ. Вы можете не только самостоятельно изменять и добавлять функции на сервер (если вы знаете C ++ или Perl, если используете mod_perl), но и огромное количество разработчиков создали модули для добавления на сервер.
В связи с его популярностью мы решили создать группу советов и руководств, которые помогут вам установить, настроить / настроить и оптимизировать сервер Apache. Поскольку Apache доступен для Unix и Windows, мы укажем, является ли совет для конкретной платформы.
Начиная с
Установка Apache и его запуск обычно считаются изнурительной задачей, чего не должно быть. На самом деле, с этими советами и уроками, это должно быть довольно легко для всех. Установка Unix-версии Apache аналогична установке большинства других приложений, вы скачиваете исходный код, компилируете его и вуаля! Версия для Windows также делает это легким; используя мастер установки, это похоже на установку любого другого приложения Windows.
Во всяком случае, сначала нам нужно скачать копию Apache. Поскольку он относительно небольшой (размер варьируется от 1 до 3 МБ, в зависимости от платформы), это должна быть безболезненная процедура. После этого нужно просто установить его. Следующие советы сделают эту процедуру максимально безболезненной.
Скачать Apache
Чтобы получить Apache, очевидно, вы должны перейти на их сайт по адресу http://www.apache.org/ . Перейдите в раздел загрузок ( http://www.apache.org/dist/ ) или найдите ближайшее к вам зеркало Apache ( http://www.apache.org/dyn/closer.cgi ), чтобы получить свою копию.
Если вам нужна версия Apache для Unix, просмотрите список файлов с хорошими именами и возьмите сжатую копию (apache_1.3.9.tar.gz). Для версии Windows загрузите двоичный установочный файл Windows (apache_1_3_9_win32.exe).
Поскольку установка версии для Windows является самой простой, я сначала расскажу об этом. После загрузки файла просто откройте его как обычно, и мастер установки откроет и установит сервер для вас. Поскольку Apache только начал создавать версии для Windows, код не так стабилен, как для Unix. Поддержка Windows является полностью экспериментальной и рекомендуется только для опытных пользователей. Apache Group не гарантирует, что это программное обеспечение будет работать в соответствии с документацией или даже вообще. Во время установки вам будет предложено
- каталог для установки Apache в
- название меню «Пуск»
- тип установки
Обычно устанавливает все, кроме исходного кода. Minimum не устанавливает руководства или исходный код, а Custom позволяет вам «настроить» то, что установлено.
Теперь к версии Unix. Поскольку вы скачали дистрибутив «tarball», вы должны распаковать его. Просто введите tar -zxf apache_1.3.9.tar.gz . Будет создан каталог с именем apache_1.3.9 . Вам нужно будет перейти в этот каталог, чтобы перейти к следующему шагу и скомпилировать исходный код.
Компиляция источника
Когда весь исходный код аккуратно размещен в этом каталоге (и его подкаталогах), вам придется скомпилировать его, чтобы он работал. Здесь мы будем использовать компилятор GNU cc (gcc is the shortform) для компиляции исходного кода. Это бесплатно и распространяется с большинством операционных систем Unix. Если его нет на вашем компьютере, загрузите и установите его с http://www.fsf.org/software/gcc/gcc.html .
В любом случае, один раз в каталоге apache_1.3.9 из типа приглашения
./configure
Это создаст make-файл с конфигурацией по умолчанию. Чтобы изменить конфигурацию, вы должны отредактировать apache_1.3.9 / src / Configuration.tmpl перед запуском configure. Вы можете добавлять / удалять модули из списка и настраивать многие другие параметры. Обычно, однако, вы должны просто позволить ему использовать значения по умолчанию, особенно если вы впервые устанавливаете Apache.
Для получения дополнительной информации о редактировании файла конфигурации, проверьте файл README.configure, включенный в дистрибутив.
Еще две команды командной строки для выполнения. Тип
сделать
скомпилировать сервер и
сделать установку
положить его в соответствующие каталоги. По умолчанию это / usr / local / apache /, хотя это можно изменить в Configuration.tmpl. Теперь, когда ваши двоичные файлы Apache наконец установлены, мы можем приступить к изучению их использования.
Используя Apache
После всей этой работы мы теперь готовы запустить Apache. Очевидно, есть два метода для его запуска, один для Windows, а другой для Unix.
Windows
Поскольку Apache — это просто другое приложение Windows, просто перейдите в меню «Пуск», а затем в группу программ Apache Web Server. Если вы не используете Windows NT, просто выберите «Запустить Apache как консольное приложение». Если вы используете Apache в NT, вы можете выбрать опцию «Установить Apache как службу (только NT)», и Apache будет установлен на ваш компьютер в качестве службы. Это означает, что он будет автоматически запускаться каждый раз при загрузке NT.
Для выключения сервера в меню «Пуск» доступны еще две опции, которые не требуют пояснений.
Юникс
Для запуска Apache в Unix все, что вам нужно сделать, это запустить httpd. Это будет выглядеть примерно так
/ USR / местные / Apache / HTTPD
но это также зависит от того, где вы установили бинарный файл. Он автоматически использует файл конфигурации, созданный при компиляции, с именем httpd.conf . Если вы хотите использовать другой файл конфигурации, вы можете использовать аргумент -f .
Ex. / usr / local / apache / httpd -f /usr/local/apache/conf/httpd.conf
Дистрибутив Apache поставляется с другим методом запуска, остановки и перезапуска Apache. Сценарий называется apachectl. В каталоге Apache src ( apache_1.3.9 / src ) введите в командной строке make. Вы увидите еще несколько скомпилированных файлов. После того, как make сделан, перейдите в каталог поддержки ( apache_1.3.9 / src / support ), где вы найдете кучу новых созданных файлов. Среди них вы найдете несколько вспомогательных скриптов, в том числе apachectl, htpasswd (используется для создания паролей Apache для защищенных каталогов) и rotatelogs (его использование будет объяснено позже). Есть несколько других файлов, но они являются наиболее важными.
Сделайте копию этих трех файлов в ваш двоичный каталог Apache. Если вы не изменили настройки по умолчанию, они будут расположены в / usr / local / apache / bin /.
Чтобы запустить сервер, используйте
/ usr / local / apache / bin / apachectl start
А также есть
/ usr / local / apache / bin / apachectl stop
и
/ usr / local / apache / bin / apachectl restart
доступно, очевидно, чтобы остановить или перезапустить сервер.
Чтобы Apache запускался после загрузки вашей системы, сделайте копию apachectl в вашем каталоге запуска (обычно это /etc/rc.d/init.d или /etc/rc3.d/…. )
Проверьте все это, чтобы убедиться, что все работает. Из вашего браузера проверьте http: // localhost / сразу после этого. Вы узнаете, сработало ли это или нет, если вы увидите что-нибудь …
Уф! Теперь, когда все работает, пришло время настроить наш сервер.
Настройка Apache
Хотя обычно считается, что редактировать файл конфигурации для чего-либо страшно, для Apache это не обязательно. Конфигурация может быть найдена в каталоге apache_1.3.9 / conf / , и, хотя доступно несколько файлов, вам действительно нужны только три из них.
Во-первых, есть httpd.conf , который содержит директивы и конфигурации, относящиеся к работе сервера в целом. Например, журналы сервера и управление сервером.
Далее в списке находится srm.conf . Этот файл содержит конфигурации для управления ресурсами в файловой системе, такими как псевдонимы, индексы каталогов и т. Д.
Наконец, access.conf . Этот файл содержит информацию об управлении доступом в любых нужных вам каталогах. Все остальные файлы, ну вы можете просто оставить их.
Когда вы впервые устанавливаете Apache, файлы не имеют таких имен , как кажется, они называются name.conf-dist . Это означает, что это дистрибутивная копия файла. Поскольку нам нравится иметь резервные копии всего и вся, просто используйте команду, подобную этой (из unix)
cp httpd.conf-dist httpd.conf
Или для Windows просто скопируйте файл и переименуйте его.
Еще одно замечание, прежде чем мы начнем, вы должны перезапустить Apache, прежде чем любые изменения в файлах конфигурации вступят в силу. Это потому, что файлы загружаются при инициации, поэтому эти изменения не будут загружены в противном случае.
Знай свои директивы
Документация Apache может быть чрезвычайно полезна для пользователей, которые только начинают настраивать свой сервер.
На http://www.apache.org/docs-1.2/mod/directives.html вы можете найти список доступных директив (конфигураций) для вашего сервера, а также пояснения. Следует отметить, что перечисленные директивы относятся к версии 1.2, а не к новой версии 1.3. Большинство из них должны быть одинаковыми, но некоторые могут исчезнуть, и могут появиться новые.
Не похоже на чаевые? Что ж, трудно настроить что-то именно для ваших нужд, не зная точно, что это может сделать. Итак, с учетом сказанного, это, безусловно, важный совет.
Существует также книга, содержащая директивы. Руководство по установке и администрированию веб-сервера Apache, в котором подробно описывается процесс установки и администрирования веб-сервера Apache, является удобным дополнением к рабочему столу. Он также включает в себя печатную версию части документации Apache по установке и общему администрированию.
Знание ваших директив также может сделать вашу жизнь более удобной. Если вам не нравится, где Apache установил ваш DocumentRoot (куда вы помещаете HTML и другие файлы), вы можете легко изменить его в httpd.conf с помощью этой директивы:
DocumentRoot / где / вы / хотите / чтобы / положить / ваши / документы
Или, если вы хотите указать, куда будут отправляться электронные письма, если есть проблемы с сервером, просто используйте эту директиву:
ServerAdmin [email protected]
Теперь это должно быть оправданием, чтобы выйти и узнать больше … это облегчит вашу жизнь.
Использовать на стороне сервера
Если вы не хотите просто обслуживать своих пользователей простым старым HTML, но у вас еще нет опыта в написании некоторых CGI-сценариев (или они просто ленивы), попробуйте серверные версии Apache (SSI).
Так что же такое SSI?
По сути, это HTML-документ, содержащий специальные команды внутри. Если он назван соответствующим образом, Apache предварительно проанализирует документ, когда он будет запрошен, и отправит полученный документ. SSI контролируется модулем с именем mod_include .
С помощью SSI вы можете выполнять различные действия, такие как отображение некоторых переменных среды, отображение даты или даже включение внешних файлов в ваш документ.
Прежде чем вы сможете использовать SSI, вы должны убедиться, что модуль mod_include был скомпилирован с остальной частью Apache. Он включен по умолчанию, но вы могли прокомментировать его при редактировании Configuration.tmpl ранее. Если это так, раскомментируйте строку и перекомпилируйте Apache. Как только это будет сделано, откройте файл httpd.conf .
Чтобы использовать анализируемые сервером HTML-файлы, найдите раздел, приведенный ниже:
AddType text / html .shtml
AddHandler-серверный .shtml
Убедитесь, что вы избавились от комментариев перед строками (#), поскольку они комментируются по умолчанию. Обратите внимание, как они используют .shtml? Вы можете изменить это на любое расширение, которое вам действительно нужно, вы просто должны не забыть назвать ваши файлы SSI позже с этими расширениями.
После того, как вы измените эти директивы в файлах конфигурации, перезапустите Apache, и давайте создадим тестовый файл SSI. Поскольку мы используем .shtml в качестве расширения SSI, мы назовем наш файл test.shtml.
<! DOCTYPE HTML PUBLIC «- // W3C // DTD HTML 3.2 Final // EN»>
<HTML>
<HEAD> <TITLE> Тестирование на стороне сервера включает в себя </ TITLE> </ HEAD>
<BODY BGCOLOR = «# FFFFFF»>
Текущая дата: <! — # echo var = «DATE_LOCAL» ->
<P> Имя документа: <! — # echo var = «DOCUMENT_NAME» ->
<P> Экологические переменные: <BR>
<PRE> <! — # printenv -> </ PRE>
</ BODY>
</ HTML>
Если все выглядит правильно и все ваши пробелы заполнены, SSI правильно включен на вашем сервере. Поздравляем!
Для получения дополнительной информации о SSI, посетите раздел SSI TheScripts.com по адресу http://ssi.thescripts.com/ .
Сделай работу этих CGI
После того, как вы закончили SSI, пришло время настроить ваш сервер для использования CGI. CGI расшифровывается как Common Gateway Interface, но по некоторым причинам люди всегда путают его с Perl, наиболее популярным языком, используемым для CGI. Фактически CGI может быть любым языком, таким как C / C ++, Java, TCL или Perl, а также многими другими.
Модуль управления CGI в Apache называется mod_cgi и компилируется по умолчанию. Если вы удалили его из Configuration.tmpl , вы должны добавить его обратно и перекомпилировать Apache, прежде чем продолжить.
Первым методом включения CGI является создание определенного каталога, который содержит сценарии. ScriptAlias подобен обычному псевдониму, за исключением того, что документы обрабатываются как приложения и не обрабатываются как документы по запросу клиента.
Типичная настройка ScriptAlias выглядит так
ScriptAlias / cgi-bin / «@@ ServerRoot @@ / cgi-bin /»
Это делает / cgi-bin / псевдонимом вашего корневого каталога / cgi-bin / . @@ ServerRoot @@ отражает переменную ServerRoot, которую вы установили в верхней части файла конфигурации. Вы можете написать это любым способом, например,
ScriptAlias / cgi-bin / «/ usr / local / apache / cgi-bin /»
или где вы хотите разместить каталог cgi-bin. Вы должны следовать приведенной выше конфигурации со следующими
<Directory «/ usr / local / apache / cgi-bin /»>
Опции ExecCGI
AddHandler cgi-скрипт .cgi .pl
</ Directory>
Часть AddHandler позволяет вам иметь CGI-скрипты с расширениями .cgi и .pl в этом случае. Вот другой метод. Этот метод позволяет использовать CGI вне каталогов ScriptAliased. Вы бы использовали следующую конфигурацию;
AddHandler cgi-скрипт .cgi .pl
Заметьте, что он не найден внутри контейнера Directory? Таким образом, директива AddHandler применяется ко всем документам, а не только к документам, найденным в определенном каталоге. Здесь мы снова разрешаем расширения .cgi и .pl для наших CGI-скриптов. Вы можете использовать что угодно.
Приложения CGI при запуске запускаются под тем же именем, что и пользователь, которому принадлежит серверный процесс Apache. По умолчанию пользователь называется «никто» , как указано в директиве «Пользователь и группа». Эти директивы могут работать, только если сервер Apache запущен пользователем root.
Пользователь никто
Группа 1
В большинстве случаев вам не придется ничего менять здесь. Это не всегда подходит, так как, если в вашей системе несколько пользователей, вы можете захотеть, чтобы CGI запускались под именем пользователя. Это отлично подходит для систем виртуального хостинга, поскольку вы можете запустить CGI под именем клиента и получить доступ к его файлам.
Чтобы противостоять этой проблеме, Apache создал программу suEXEC, включенную в сервер Apache. Чтобы узнать больше о том, как использовать его для вашей системы, посетите http://www.apache.org/docs-1.2/suexec.html .
Документы об ошибках
Когда-нибудь замечали, как некоторые сайты имеют свои собственные документы об ошибках? Например, попробуйте зайти сюда ( http://www.thescripts.com/nopage.html ). Вы получаете ошибку 404, но не просто ошибку 404, у нас есть настроенная страница ошибки 404. Вы можете сделать это для любой другой ошибки, которую вы можете получить (у нас также есть страница с ошибкой 403). К вашему сведению, 404 ошибки означают, что страница не была найдена, а 403 означает, что у вас нет доступа к определенному документу.
Так как нам это сделать? Это на самом деле довольно просто. Вместо того, чтобы использовать стандартные / неприятные страницы ошибок Apache, вы можете указать определенные файлы, которые будут возвращаться при определенных ошибках. Используемая здесь директива называется ErrorDocument, и ниже мы находим пример
ErrorDocument 404 /fourohfour.html
Это, как вы уже поняли, страница с ошибкой 404. В этом случае он находится в каталоге htdocs и называется fourohfour.html . Если вы получили к нему доступ из браузера, он был бы на http://www.yoursite.com/fourohfour.html
Чтобы добавить документ об ошибке другого типа, например, 403, вам нужно просто сделать следующее;
ErrorDocument 403 /fourohthree.html
Итак, как вы можете видеть, первый аргумент в директиве ErrorDocument — это номер ошибки. Второе — это расположение страницы.
Просто примечание, было бы лучше использовать полное изображение и пути ссылки в документе об ошибке. Это потому, что использование относительных ссылок / путей к изображениям было бы неточным. Например, если вы перешли на http://www.thescripts.com/nothere/nothere.html , страница fourohfour.html будет обслуживаться так, как если бы она находилась в каталоге nothere, но на самом деле она находится в корневом каталоге ваши HTML документы. Для получения дополнительной информации о директиве ErrorDocument посетите страницу http://www.apache.org/docs/mod/core.html.
Согласование контента
Я знаю, что вы думаете, что такое переговоры по содержанию? Ну, во-первых, это часто пропускаемая особенность Apache. Он более точно известен как выбор контента и представляет собой выбор документов, которые лучше всего соответствуют возможностям браузера клиента, из одного из нескольких доступных документов.
Зачем тебе это?
Ну, вы не… но если вы нацеливаете свой веб-сайт на многоязычный регион, то его использование будет очень полезным для вас. Мало того, что ваши документы будут правильно предоставлены посетителям, но это также улучшит их пребывание на вашем сайте.
По умолчанию согласование содержимого компилируется с вашим сервером, так как оно поддерживается mod_negotiation. Если по какой-то причине вы не скомпилировали эту функцию в Apache, вы должны вернуться к файлу Configuration.tmpl и вставить его обратно.
Хорошо, что тебе сейчас нужно?
Ну, вы должны выбрать, какие языки вы собираетесь использовать, и иметь контент, доступный для обоих языков. На самом деле мы можем использовать два метода: с помощью файла вариантов, который можно найти здесь ( http://www.apacheweek.com/features/negotiation ), или с помощью расширений файлов.
В этом примере мы будем использовать три разных языка: английский, французский и немецкий.
Теперь откройте файл access.conf и начнем. Во-первых, нам нужно будет указать каталог, который мы будем называть международным, и иметь его так, чтобы он был настроен для согласования контента. Международный каталог будет расположен рядом с корневым каталогом документов, который в нашем случае является / usr / local / apache / htdocs / .
<Directory / usr / local / apache / htdocs / international>
Опции MultiViews
</ Directory>
Параметры MultiViews устанавливают каталог так, что сервер выполняет сопоставление с шаблоном имени файла для выбора среди результатов. Теперь откройте httpd.conf, чтобы мы могли добавить наши языки для поиска и то, как сервер будет их идентифицировать. Мы будем использовать директиву AddLanguage
AddLanguage en .en
AddLanguage fr .fr
AddLanguage de .de
Здесь мы добавили английский, французский и немецкий, все идентифицированные с расширением, найденным справа от них.
По умолчанию довольно много языков уже установлено. Вы можете комментировать их и добавлять к ним по мере необходимости.
Директива LanguagePriority позволяет вам отдавать предпочтение некоторым языкам в случае связи во время согласования контента. Языки перечислены в порядке убывания или предпочтения.
LanguagePriority en fr de
Итак, как вы называете ваши файлы сейчас? Лучший способ — сделать что-то вроде test.html.en для документа на английском языке, test.html.fr для документа на французском языке и test.html.de для документа на немецком языке. Если вы хотите сослаться на этот документ, вы просто используете test.html .
Для получения дополнительной информации о согласовании содержимого см. Http://www.apache.org/docs/content-negotiation.html .
Один файл конфигурации
Боже, почему это поможет?
Ну, это поместило бы все ваши опции в один файл, что облегчает жизнь, когда вы хотите что-то редактировать. В этом случае мы будем использовать httpd.conf для хранения всех наших директив. Некоторые комментарии к трем файлам конфигурации см. По адресу http://www.apache.org/info/three-config-files.html .
В любом случае, вернемся к проблеме с одним файлом конфигурации. Прямо сейчас вы используете три файла конфигурации: httpd.conf , access.conf и srm.conf . Вам не нужно. Просто очистите важные файлы из последних двух файлов в httpd.conf , а затем добавьте эти две строки:
AccessConfig / dev / null
ResourceConfig / dev / null
Это сообщит Apache, что httpd.conf является единственным файлом конфигурации. Имея это в виду , вы можете просто удалить файлы srm.conf и access.conf и продолжить с улыбкой на лице.
Вращающиеся журналы
Так что же это за файлы журнала, о которых вы постоянно слышите?
Каждый раз, когда пользователь запрашивает документ с вашего сайта, сервер «записывает» запись этого запроса в файл журнала. Файлы журнала содержат важную статистику о пользователях, такую как их хост, дата / время и строка запроса, которая содержит информацию браузера.
Если ваш сайт даже удаленно занят, или прошло много времени с тех пор, как вы что-то сделали с журналами, они, вероятно, будут довольно большими. Как правило, они могут достичь многих МБ за короткий период времени. Поскольку лучшим приложением для файлов журналов является анализ журналов с помощью другого программного обеспечения, большие файлы журналов могут замедлить этот процесс до сканирования.
Итак, что вы можете с этим поделать? Использовать ротацию логов.
Ротация журнала — это процедура, которая берет файл журнала, помещает его содержимое в новый файл, а затем очищает его собственное содержимое. Поскольку это довольно скучная процедура, есть несколько сценариев, которые помогут вам сделать это, в том числе один из самой группы Apache.
Например, один скрипт — это небольшая утилита, написанная для быстрого разделения и обработки файлов журнала. Эта утилита создаст новый файл журнала для каждого дня с датой в качестве расширения. После создания нового файла журнала старый файл можно сжать или переместить в новое место. Утилита называется logbox и доступна по адресу ftp://ftp.lemuria.org/pub/Code/logbox.tar.gz . Вы должны скомпилировать его на своем сервере, прежде чем сможете его использовать.
Другой метод разделения файлов сделан группой Apache. Ранее вы его скомпилировали, что также было при компиляции apachectl и htpasswd. Если вы использовали настройки по умолчанию, вы также скопировали их в / usr / local / apache / bin / . Эта программа называется rotatelogs (как гениально!), И она используется с директивой TransferLog в Apache.
В httpd.conf добавьте что-то вроде этого:
LogFormat «% h% l% u% t»% r «% s% b»% {Referer} i «»% {User-agent} i «»
ErrorLog / usr / local / apache / logs / error_log
TransferLog «| / usr / local / apache / bin / rotatelogs / usr / local / apache / logs / access_log 86400»
Позвольте мне объяснить это …
Директива LogFormat действительно не о чем беспокоиться. Он просто определяет формат шаблона для того, как будут выглядеть журналы доступа и ошибок. Для получения дополнительной информации о параметрах, которые предоставляет LogFormat, см. Http://www.apache.org/docs-1.2/mod/mod_log_config.html .
ErrorLog устанавливает имя файла, в который сервер будет регистрировать любые ошибки, с которыми он сталкивается. Это важно время от времени просматривать, чтобы увидеть, что может быть не так с вашим сайтом / сервером.
Теперь о той части, которую вы ждали.
Директива TransferLog. Здесь мы смешиваем его с программой rotatelogs одновременно. Технически, здесь есть один аргумент для TransferLog, но его можно разбить. Первая часть — это местоположение нашей программы rotatelogs (в данном случае это / usr / local / apache / bin / rotatelogs ).
Вторая часть — это расположение нашего файла access_log (файл, в который мы записываем запросы нашего сервера, находится по адресу / usr / local / apache / logs / access_log ). Последняя часть устанавливает количество времени до вращения файлов журнала. Это в секундах, и так как 86400 секунд равняется 1 дню (24 часа), мы вращаем файл каждый день. Вы можете установить это на любой период времени, который вы хотите. Сгенерированное имя старого файла журнала (после каждой ротации) будет в этом случае /usr/local/apache/logs/access_log.nnnn , где nnnn — системное время, с которого был запущен журнал. После каждого времени ротации запускается новый пустой журнал.
Получить некоторые дополнительные
Поскольку Apache является открытым исходным кодом, для него построено множество дополнений. Эти дополнения могут значительно повысить производительность вашего сервера и даже дать вам больше возможностей с вашим сайтом. Два наиболее заметных дополнения включают mod_perl и mod_php
mod_perl — отличное связывание веб-сервера Apache и Perl ( http://www.perl.com/ ), популярного языка сценариев CGI. Модуль берет копию интерпретатора Perl и встраивает ее в сам Apache. Это не только ускоряет существующие CGI, но также позволяет писать больше модулей на самом Perl. Сценарии Perl компилируются один раз таким образом, в отличие от обычного метода. Обычно скрипты компилируются во время выполнения интерпретатором, что заставляет их работать немного медленнее с самого начала. Если они уже скомпилированы, они запускаются мгновенно, что делает этот модуль отличным дополнением к веб-сайту с высоким уровнем трафика.
mod_php — еще одно замечательное дополнение к Apache. Мощный серверный язык сценариев PHP ( http://www.php.net/ ), который также является открытым исходным кодом / свободен, может быть легко связан с сервером после компиляции. Сценарии PHP могут выполняться как обычные CGI, но этот метод позволяет запускать их с гораздо большей скоростью.
Обе эти надстройки должны быть скомпилированы с Apache с самого начала, так как они являются модулями. Если вы хотите использовать их, просто загрузите их, отредактируйте файл Configuration.tmpl, запустите configure и скомпилируйте как обычно.
Есть инструкции для этих модулей, так как они немного сложнее. Вы можете документацию на http://perl.apache.org/ и http://www.php.net/ соответственно.
Купить книгу
Надо сказать, это самое простое место, где можно найти отличные советы. Мало того, что они всегда доступны для вас (как это должно быть рядом с вами), но если у вас нет портативного компьютера в туалете, вы можете просто прочитать его там же.
Есть несколько хороших книг, и, как обычно, мои любимые книги публикуются О’Рейли.
Эта книга может похвастаться одним из членов команды разработчиков Apache. Он начинается с академической дискуссии о том, что делают веб-серверы, а затем знакомит читателя с процессом установки Apache. Установке Apache уделяется много внимания, и вы узнаете о безопасности веб-сайта и других предпочтениях.
Библия сервера Apache — это отличное руководство по администрированию вашего веб-сервера Apache, которое предназначено для тех, у кого нет опыта веб-администрирования. Темы включают компиляцию исходного кода, установку, проблемы конфигурации.
Apache Server для Windows Маленькая черная книга: Маленькая черная книга
Эта книга покажет вам, как использовать возможности Apache. Книга даже переходит к таким вещам, как CGI, управление базами данных, шифрование и многое другое.
Оптимизируйте свой сервер Apache
Как только ваш веб-сайт станет популярным, вам придется начать беспокоиться о другой проблеме: как максимально эффективно использовать свой сервер. С постоянно растущей нагрузкой трафика вам придется найти способ оптимизировать его, чтобы немного лучше справляться с трафиком.
Вот где эта часть учебника вступает в игру. Прежде чем начать, я должен заявить, что все эти советы будут нацелены на серверы Unix, так как Apache вообще не оптимизирован для Windows.
Рассматривая проблемы со скоростью и Apache, мы должны посмотреть на оборудование / операционную систему, ваши файлы конфигурации и то, как вы скомпилировали сервер с самого начала. Для тех из вас, кто хочет прочитать все ваши параметры производительности, посетите http://www.apache.org/docs/misc/perf-tuning.html и http://www.apache.org/docs/misc/ perf.html . Также вы можете проверить книгу О’Рейли «Настройка производительности в сети».
Поиск файлов
Это то, о чем вы даже не подумали. Здесь два виновника — просто файлы .htaccess и символические ссылки. Для тех из вас, кто смотрит на страницу забавно, файлы .htaccess — это тип файла контроля доступа. Они могут содержать директивы Apache и применяться к каталогу, в котором они находятся, и всему, что находится под ним, переопределяются только другими файлами .htaccess .
По умолчанию директива Apache AccessFileName установлена в .htaccess , поэтому она известна, если вы ее не изменили. Таким образом, вы можете думать об этом как о другом файле конфигурации Apache, хотя это и необязательно.
При возврате документа клиенту сервер ищет файл контроля доступа с этим именем в каждом каталоге пути к документу, если для этого каталога включены файлы контроля доступа. Например, скажем, я получил документ, найденный по адресу http://www.mysite.com/test/test2/test3/test4.html, и моя директива DocumentRoot была установлена в / usr / local / apache / htdocs . Apache будет искать файл .htaccess в следующих каталогах;
/
/ USR
/ USR / местные
/ USR / местные / Apache
/ USR / местные / Apache / HTDOCS
/ USR / местные / Apache / HTDOCS / тест
/ USR / местные / Apache / HTDOCS / тест / test2
/ USR / местные / Apache / HTDOCS / тест / test2 / test3
Ты видишь, к чему я клоню?
При включенных файлах контроля доступа Apache должен довольно часто проверять наличие ненужных файлов, что лишает вас некоторой производительности.
Итак, как мы можем решить эту проблему?
Мы можем использовать контейнер Справочника, чтобы указать, что переопределения в контейнере недопустимы. В этом случае мы используем корневой каталог.
<Directory />
AllowOverride Нет
</ Directory>
После этого мы можем захотеть использовать файлы .htaccess. Если это так, вы можете включить их снова,
<Directory / usr / local / apache / htdocs>
AllowOverride All
</ Directory>
И вот, пожалуйста. На самом деле директива AllowOverride имеет несколько параметров, чтобы увидеть их, ознакомьтесь с http://www.apache.org/docs-1.2/mod/core.html .
Символьные ссылки имеют похожую проблему, и исправление почти такое же, за исключением того, что используются разные директивы.
<Directory />
Опции FollowSymLinks
</ Directory>
С последующим
<Directory / usr / local / apache / htdocs>
Опции -FollowSymLinks + SymLinksIfOwnerMatch
</ Directory>
Теперь мы избавились от проблемы поиска файлов, так как нет ненужных проверок файлов.
Поиск имени хоста
По умолчанию в Apache отключена директива HostnameLookups. Это хорошо, так как при этом каждый клиентский запрос к вашему серверу будет приводить к запросу поиска к серверу имен.
Это также проблема, если вы ограничиваете доступ к определенным разделам вашего сайта с помощью директивы заказа, сопровождаемой разрешением и отказом. В этом случае лучше использовать IP-адреса, так как в противном случае вам придется искать другой сервер имен.
При этом ваш сервер Apache не должен выполнять никаких ненужных действий с DNS и может выполнять свою работу. Если ваш CGI, PHP или что-то еще может потребовать использования поиска имени хоста, вы можете использовать контейнер файлов, чтобы указать это.
<Files ~ «. (Php3 | cgi) $>
HostnameLookups on
</ Files>
Согласование контента
Здесь я снова иду с моими причудливыми словами, содержанием переговоров. Я знаю, что предложил использовать его раньше, но только в том случае, если это принесет пользу вам. В противном случае вы должны держаться подальше от этого. Почему?Поскольку он требует поиска определенных файлов, а не точных имен, поисковая часть создает немного большую нагрузку на сервер, что замедляет его работу. Кроме того, для директив, которые запрашивают у вас файлы, такие как DirectoryIndex, вместо простого указания индекса, укажите фактическое имя файла. Пример ниже;
Индекс DirectoryIndex
Индекс — это подстановочный знак, так как расширение не указано, и он должен снова выполнить поиск, чтобы найти файл. Размещение списка имен будет гораздо более быстрым и эффективным методом. Поставьте наиболее распространенное имя первым и в порядке убывания.
DirectoryIndex index.html index.shtml index.cgi
аппаратные средства
Как и большинству программного обеспечения, Apache требуется оперативная память, особенно если вы получаете много трафика. Если доходит до того, что ваша операционная система должна начать замену памяти с жесткого диска, вы должны либо получить больше оперативной памяти, либо установить директиву MaxClients немного ниже.
Обмен памяти не обязательно медленный, но для клиента это так. Они будут раздражены, несколько раз нажмете стоп-перезагрузку и увеличат нагрузку на ваш сервер. Не очень хорошая вещь.
Кроме того, с достаточно быстрым жестким диском, сетевой картой и процессором ваш сервер должен работать довольно хорошо (по крайней мере, аппаратно). Немного поэкспериментировав, вы сможете найти оптимальную конфигурацию.
Серверные процессы
Такие настройки, как MinSpareServers, MaxSpareServers, StartServers и KeepAliveTimeout (если для KeepAlive установлено значение «On»). Директивы SpareServers указывают серверу, сколько «дочерних» процессов создать. Apache использует эти директивы для определения нагрузки, к которой он должен адаптироваться.
Если на вашем сервере есть дочерние объекты, ожидающие запросов, а количество превышает параметр MaxSpareServers, некоторые из этих дочерних процессов будут уничтожены. Если сумма меньше, чем MinSpareServers, будут созданы некоторые дочерние процессы.
Настройки этих директив будут напрямую связаны с производительностью вашего сервера. Если у вас недостаточно дочерних процессов для обработки текущей нагрузки на сервер, некоторые запросы будут отложены, из-за чего ваш сервер будет работать медленнее. Слишком много процессов также замедлит работу вашего сервера, если у вас недостаточно оперативной памяти и мощности процессора для его обработки.