Справочник от Автор24
Поделись лекцией за скидку на Автор24

Понятие веб-сервера. Знакомство с lamp (Linux Apache MySQL PHP)

  • 👀 572 просмотра
  • 📌 494 загрузки
Выбери формат для чтения
Загружаем конспект в формате pdf
Это займет всего пару минут! А пока ты можешь прочитать работу в формате Word 👇
Конспект лекции по дисциплине «Понятие веб-сервера. Знакомство с lamp (Linux Apache MySQL PHP)» pdf
ЛЕКЦИЯ Понятие веб-сервера. Знакомство с lamp (Linux Apache MySQL PHP) Понятие веб-сервера. Знакомство с Архитектурой LAMP (LINUX APACHE MYSQL PHP). 1 1 ПОНЯТИЕ ВЕБ-СЕРВЕРА Веб-сервером называют как программное обеспечение, выполняющее эти функции, так и непосредственно компьютер, на котором это программное обеспечение работает. Веб-сервер — это сервер, обслуживающий запросы к одному или нескольким сайтам Всемирной паутины. Веб-сервер — программа, обрабатывающая сообщения, которые приходят на 80-й порт, и работающая с протоколом HTTP (Hypertext Transfer Protocol). Кто (или что) может обращаться к веб-серверам в качестве клиента? В качестве клиентов для обращения к веб-серверам могут использоваться различные программы и устройства: − веб-браузер, работающий на настольном компьютере или переносном устройстве (например, карманном ПК); − разнообразные программы, самостоятельно обращающиеся к веб- серверам для получения обновлений или другой информации (например, антивирус может периодически запрашивать у определённого веб-сервера обновления своих баз данных); − мобильный телефон, получающий доступ к ресурсам веб-сервера при помощи протокола WAP; − другие интеллектуальные устройства или бытовая техника. На какие четыре группы можно условно разбить основные функции веб-сервера? − управление передачей документов; − ведение журнала активности клиентов; − поддержание безопасности данных; − обеспечение работы средств интерактивной работы с клиентом. 2 3 2 ЗНАКОМСТВО С АРХИТЕКТУРОЙ LAMP (LINUX APACHE MYSQL PHP) Приложения, использующие архитектуру LAMP (Linux®, Apache, MySQL, PHP/Perl), постоянно совершенствуются и все шире используются. Но системный администратор часто не имеет полного контроля за самими приложениями, поскольку они написаны кем-то другим. В этой серии из трех статей обсуждается множество моментов, связанных с конфигурированием сервера, которые могут влиять на производительность приложений. Эта первая статья описывает архитектуру LAMP, некоторые методики замеров и некоторые основные сведения, касающиеся ядра Linux, дисков и наладки файловой системы. Последующие статьи рассматривают настройку компонентов Apache, MySQL и PHP. Архитектура LAMP Первый шаг в настройке любой системы — понимание того, как система работает. В простейшем случае приложения на базе LAMP написаны на скриптовом языке, например PHP, который работает как часть Webсервера Apache, запущенного на Linux-хосте. Для того чтобы определить дальнейшие действия, приложения PHP получают информацию от клиента через запрашиваемый URL, из любых данных формы, независимо от того, какая информация о сессии была получена. Если необходимо, сервер извлекает информацию из базы данных MySQL (также работающей под Linux), комбинирует информацию с какимито шаблонами HTML (Hypertext Markup Language) и возвращает результат клиенту. Этот процесс повторяется, поскольку пользователь работает с приложением, а также выполняется параллельно, поскольку множество пользователей получает доступ к системе. Однако поток данных не является односторонним, потому что база данных может быть обновлена 4 информацией, полученной от пользователя в форме данных сеанса, статистической подборкой (включая голосование) и содержимым, предоставленным пользователю, например, комментарии или обновление сайта. Вдобавок к динамическим элементам существуют также статические элементы, такие как изображения, коды JavaScript и CSS (Cascading Style Sheets). Посмотрев на поток запросов через систему LAMP, вы можете увидеть места, где могут произойти замедления. База данных предоставляет большое количество динамической информации, так что клиент замечает любую задержку реакции на запрос. Web-сервер должен быть доступен для быстрого выполнения скриптов, а также управления множеством конкурирующих запросов. Наконец, для поддержки приложений базовая операционная система должна быть в добром здравии. Другие настройки, распределяющие файлы между различными серверами по сети, также могут являться узким местом. Измерение производительности Постоянное измерение производительности помогает в двух случаях. Первое - измерение помогает выявлять тенденции, как хорошие, так и плохие. Вот простой пример: наблюдая за использованием центрального процессора (CPU) на Web-сервере, вы можете заметить его чрезмерную загрузку. Подобным образом, наблюдение за использованием общей пропускной способности в прошлом и экстраполяция на будущее помогает выявлять моменты, когда необходимо обновление сети. Эти измерения взаимосвязаны с другими измерениями и наблюдениями. Например, вы можете решить, что когда пользователи жалуются на медленную работу приложений, диски работают с максимальной нагрузкой. 5 Другое применение измерений производительности -- определение, помогла ли настройка решению ситуации или ухудшила положение. Вы делаете это, сравнивая результаты измерений до и после произведенных изменений. Однако, чтобы это принесло результат, для определения эффекта от изменений одновременно должен меняться только один критерий, и должны сравниваться соответствующие показатели. Причина одновременного изменения только одного компонента должна быть очевидна. Ведь вполне возможно, что два одновременно произведенных изменения могли нейтрализовать друг друга. Причина для выбора измерений является гораздо более тонкой. Решающим является то, что измерения, которые вы выбираете для исследования, должны отражать интенсивность использования приложения. Если цель изменения состоит в уменьшении объема памяти, используемой базой данных, устранение различных буферов, конечно, поможет за счет скорости запроса и производительности приложения. Взамен одно из измерений должно быть временем отклика приложения, что позволит обнаружить возможности настройки других показателей, не только использования памяти базой данных. Вы можете измерить время отклика приложения разными способами. Возможно, самый простой способ -- использовать команду curl, как показано в Листинге 1. Листинг 1. Использование curl для измерения времени отклика Web-сайта $ curl -o /dev/null -s -w %{time_connect}:%{time_starttransfer}:%{time_total}\ http://www.canada.com 0.081:0.272:0.779 6 В Листинге 1 показана команда curl, используемая для поиска популярных новостных сайтов. Вывод, который обычно был бы HTMLкодом, направлен при помощи опции -o в /dev/null, а также использована опция -s, отключающая вывод информации о ходе процесса. Опция -w дает указание вывести некоторые данные о ходе процесса, например, показанные в Таблице 1 таймеры. Таблица 1. Таймеры, используемые curl Таймер time_connect Описание Время, необходимое для установки TCP-соединения с сервером time_starttransfer Время, необходимое Web-серверу для возврата первого байта после того как произведен запрос time_total Время, необходимое для полного выполнения запроса Все эти таймеры ведут отсчет от старта транзакции, даже перед обращением к Domain Name Service (DNS). Таким образом, после того как был сделан запрос, требуется 0.272 - 0.081 = 0.191 секунды, чтобы Webсервер обработал запрос и начал возвращать данные. Клиент затратил 0.779 0.272 = 0.507 секунды, загружая данные с сервера. Наблюдение за данными curl и временной тренд позволят вам получить представление, насколько быстро реагирует сайт на запросы пользователей. Конечно, Web-сайт -- больше чем просто отдельная страница. Он содержит изображения, код JavaScript, CSS и cookies. Команда curlспособна получать время отклика для одного элемента, но иногда вам необходимо видеть, как быстро загружается целая страница. 7 Рисунок 1 - Схема организации запросов для загрузки домашней страницы developerWorks Каждая строка описывает загрузку одного элемента. Показаны разнообразные данные, например, время отправки запроса, как долго он загружается, размер и результаты. Колонка Duration (Продолжительность) показывает время, которое требуется на загрузку элемента, в то время как колонка Total Duration (Общая продолжительность) показывает, сколько времени занимает загрузка всех суб-элементов. На Рисунке 1 видно, что на загрузку главной страницы затрачено 516 миллисекунд (мсек), но потребовалось 5101 мсек, прежде чем все было загружено, и могла быть показана вся страница. Другой полезный вариант использования расширения Tamper Data -изображение данных о загрузке страницы в виде графика. Щелкните правой кнопкой в верхней части окна Ongoing requests и выберите Graph all. На Рисунке 2 показано графическое изображение данных из Рисунка 1. 8 Рисунок 2. Графическое изображение запросов для загрузки домашней страницы developerWorks На Рисунке 2 продолжительность каждого запроса показана темносиним цветом и показывается относительно начала загрузки страницы. Таким образом, вы можете видеть, какие запросы замедляют загрузку всей страницы. Несмотря на то, что внимание сосредоточено на времени загрузки страницы и опыте пользователя, важно не упускать из виду основные показатели системы, такие как диск, память, CPU и сеть. Для получения этой информации имеется множество утилит; возможно, наиболее полезные из них -- sar, vmstat и iostat. Настройки базовой системы Прежде чем вы настроите компоненты системы Apache, PHP и MySQL, вы должны потратить некоторое время на то, чтобы убедиться, что основные компоненты Linux функционируют правильно. Разумеется, вы уже 9 отобрали из списка запущенных сервисов только те, которые вам необходимы. Помимо того, что это является хорошей практикой обеспечения безопасности, это экономит память и циклы CPU. Листинг 2. Демонстрация наиболее радикальных сетевых настроек в /etc/sysctl.conf # Использовать, когда необходимо, TCP syncookies net.ipv4.tcp_syncookies = 1 # Разрешить масштабирование окна TCP net.ipv4.tcp_window_scaling: = 1 # Увеличить максимальный размер буфера TCP net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 # Увеличить максимальное значение самонастраиваемого буфера TCP в Linux net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 # Увеличить количество доступных портов net.ipv4.ip_local_port_range = 1024 65000 Добавьте эти настройки к тому, что уже имеется в файле /etc/sysctl.conf. Эта первая настройка разрешит TCP SYN cookies. Когда клиент устанавливает новое TCP-соединение при помощи пакета с установленным битом SYN, сервер создает запись для наполовину открытого соединения и отвечает пакетом SYN-ACK. При нормальной работе удаленный клиент отвечает пакетом ACK, что меняет соединение с наполовину открытого на полностью открытое. Следующие четыре элемента конфигурации увеличивают буферы TCP для отправки и приема. Это позволяет приложениям быстрее избавиться от их информации, так что они могут обслужить другой запрос, и это также повышает возможность удаленного клиента отправлять данные, когда сервер занят. 10 Последний элемент конфигурации увеличивает количество разрешенных для использования локальных портов, что увеличивает максимальное количество соединений, которые могут быть обслужены одновременно. Эти настройки вступят в силу при следующей загрузке или при следующем запуске sysctl -p /etc/sysctl.conf. Конфигурирование дисков для достижения максимальной производительности В архитектуре LAMP диски играют существенную роль. Статические файлы, шаблоны и коды обслуживаются диском, как таблицы данных и индексы, составляющие базу данных. Большинство настроек, особенно те, которые имеют отношение к базе данных, сфокусированы на том, чтобы обойтись без доступа к диску, поскольку это влечет относительно высокую задержку. Поэтому имеет смысл затратить некоторое время на оптимизацию дисковой подсистемы. Первым делом необходимо убедиться, что журналирование atime в файловых системах отключено. Atime -- время последнего доступа к файлу, и при каждом обращении к файлу основная файловая система должна записывать эту отметку времени. Поскольку atime редко используется системными администраторами, ее отключение снизит нагрузку на диск. Это достигается путем добавления опции noatime в четвертой колонке файла /etc/fstab. В Листинге 3 показан пример конфигурации. Листинг 3. Образец файла fstab, показывающий, как разрешить noatime /dev/VolGroup00/LogVol00 / LABEL=/boot /boot devpts /dev/pts tmpfs /dev/shm proc /proc sysfs /sys ext3 defaults,noatime 11 ext3 defaults,noatime 12 devpts gid=5,mode=620 0 0 tmpfs defaults 00 proc defaults 00 sysfs defaults 00 11 LABEL=SWAP-hdb2 LABEL=SWAP-hda3 swap swap swap defaults swap defaults 00 00 В Листинге 3 изменения сделаны только для файловых систем типа ext3, поскольку опция noatime полезна только для файловых систем, расположенных на диске. Чтобы изменения вступили в силу, перезагрузка не нужна; вам только необходимо вновь подмонтировать каждую файловую систему, выполнив mount / -o remount. Возможны разнообразные комбинации жестких дисков, и Linux не всегда верно определяет оптимальный метод доступа к жесткому диску. Команда hdparm используется для получения и установки методов, используемых для доступа к дискам IDE (integrated development environment, интегрированная среда разработки). hdparm -t /path/to/device выполняет тест скорости, который вы можете использовать в качестве точки отсчета. Для получения более достоверных результатов при запуске этой команды система должна быть незанята. В Листинге 4 показан тест скорости, выполняемый на hda. Листинг 4. Тест скорости, выполняемый на /dev/hda # hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 182 MB in 3.02 seconds = 60.31 MB/sec Как видно из теста, диски читают данные со скоростью около 60 мегабайт (Мбайт) в секунду. В Таблице 2 перечислены некоторые часто используемые опции. Таблица 2. Часто используемые опции hdparm Опция Описание -vi Опрашивает устройство с целью определения, какие настройки оно поддерживает и какие использует. 12 Запрос/включение -c поддержки 32-битного (E)IDE ввода/вывода. hdparm -c 1 /dev/hda включает. Запрос/установка нескольких секторов в режиме прерывания. Если -m значение параметра больше нуля, повышение до такого количества секторов может быть передано через прерывание. -d 1 - Включение передач DMA (direct memory access, прямой доступ к X памяти) и установка режима передачи IDE. Страница справки man команды hdparm уточняет число, которое может стоять после -X. Вы должны использовать эту опцию, только если -vi показывает, что вы не используете самый быстрый режим. К сожалению, для систем Fiber Channel и Small Computer Systems Interface (SCSI) настройка зависит от конкретного устройства. Вы должны добавить в ваш стартовый скрипт, например, rc.local, те настройки, которые считаете полезными. Настройка NFS NFS (network file system, сетевая файловая система) -- способ предоставления доступа к томам диска по сети. Использовать NFS полезно, чтобы гарантировать, что каждый хост имеет одну и ту же копию данных и что изменения отражены на всех узлах. Тем не менее по умолчанию NFS не сконфигурирована для массового использования. Каждый клиент должен подмонтировать удаленную файловую систему при помощи rsize=32768,wsize=32768,intr,noatime, чтобы гарантировать следующее: Используются большие размеры блоков чтения/записи (до определенного размера, в данном случае 32Кбайт). Операции NFS могут быть прерваны в случае зависания. Atime не будет постоянно обновляться. 13 Вы можете поместить эти настройки в файл /etc/fstab, как показано в Листинге 3. Если вы используете автомонтирование, они входят в соответствующий файл /etc/auto.*. В Листинге 5 показаны статистические данные клиента для Webсервера. Листинг 5. Демонстрация статистических данных RPC при использовании NFS-клиента # nfsstat -rc Client rpc stats: calls retrans authrefrsh 1465903813 0 Во второй колонке, retrans, стоит ноль, что показывает, что, начиная с последней перезагрузки, не было необходимости ни в каких передачах. Если это число растет, вы должны подумать о добавлении большего количества NFS kernel thread'ов. Это делается путем передачи желаемого числа thread'ов rpc.nfsd, например, rpc.nfsd 128 запускает 128 thread'ов. Вы можете сделать это в любое время. Thread'ы запускаются или уничтожаются по мере необходимости. Кроме того, это должно войти в ваши стартовые скрипты, предпочтительно в скрипт, который стартует NFS на вашей системе. Настройка Apache Apache -- часть программного обеспечения, легко поддающаяся настройке. Он имеет множество функций, но каждая является ценной. Настройка Apache отчасти состоит в надлежащем распределении ресурсов и подразумевает отключение ненужных настроек. Конфигурирование мультипроцессорных модулей 14 Приложение Apache является модульным, в том смысле, что вы легко можете добавлять и удалять его элементы. Эту модульную функциональность в ядре Apache -- управление сетевыми соединениями и отправку запросов -- обеспечивают мультипроцессорные модули (MultiProcessing Modules, MPM). Модули позволяют вам использовать thread'ы или даже перемещать Apache в другую операционную систему. Одновременно может быть активен только один мультипроцессорный модуль, и он должен быть скомпилирован статически при помощи--withmpm=(worker|prefork|event). Традиционная модель "один процесс на запрос" назвается prefork. Более новая, модель с thread'ами, называемая worker, использует несколько процессов, каждый с несколькими thread'ами, для получения более высокой производительности при более низких накладных расходах. Наконец, event -экспериментальный модуль, который содержит особые группы thread'ов для различных задач. Чтобы определить, какой мультипроцессорный модуль вы сейчас используете, выполните httpd -l. Выбор мультипроцессорного модуля зависит от многих факторов. Отключение модуля event до тех пор, пока он имеет экспериментальный статус, -- это выбор между thread'ами и их отсутствием. В Листинге 1 показаны важные опции конфигурирования модуля prefork. Листинг 1. Конфигурирование мультипроцессорного модуля prefork StartServers 50 MinSpareServers 15 MaxSpareServers 30 MaxClients 225 MaxRequestsPerChild 4000 15 В модуле prefork новый процесс создан при помощи запроса. Резервные процессы простаивают, чтобы общаться с поступающими запросами, что уменьшает время ожидания запуска. Предыдущая конфигурация запускает 50 процессов, как только стартует Web-сервер, и старается поддерживать в наличии от 10 до 20 простаивающих запущенных серверов. Жесткий лимит процессов определяется при помощи MaxClients. Даже если процесс может общаться с множеством последовательных запросов, Apache убивает процессы после 4,000 соединений, что уменьшает риск утечки памяти. Конфигурирование мультипроцессорных модулей с поддержкой thread'ов производится подобным образом, за исключением того, что вы должны определить, сколько thread'ов и процессов должно использоваться. Документация Apache дает разъяснения по всем параметрам и необходимым расчетам. Выбор используемых значений подразумевает некий метод проб и ошибок. Наиболее важное значение -- MaxClients. Цель состоит в том, чтобы разрешить достаточное количество процессов worker или thread'ов, чтобы сервер не занимался исключительно свопингом. Если поступает больше запросов, чем может быть обработано, то по крайней мере те, которые поступили, обрабатываются; другие блокируются. Если MaxClients слишком высок, все клиенты получают недостаточно высокий уровень сервиса, поскольку Web-сервер пробует выгрузить один процесс, чтобы позволить выполняться другому. Установка слишком низкого значения приводит к тому, что вы можете необоснованно отказать в обслуживании. Проверка количества процессов, запущенных в момент повышенной нагрузки, и анализ объема памяти, используемой всеми процессами Apache, дает вам хорошую идею относительно установки этого значения. Если вы устанавливаете значение MaxClients выше 256, вы должны 16 установить то же значение для ServerLimit; внимательно прочтите документацию по мультипроцессорным модулям, чтобы узнать о соответствующих предостережениях. Настройка числа запускаемых серверов и наличие запасных зависит от роли сервера. Если на сервере выполняется только Apache, вы можете использовать невысокое значение, как показано в Листинге 1, поскольку вы можете использовать машину в полной мере. Если система используется еще и базой данных или другим сервером, вы должны ограничить число запасных запущенных серверов. Эффективное применение опций и переопределений Каждый запрос, который обрабатывает Apache, проходит через сложный набор правил, которые диктуют любые ограничения или специальные инструкции, которым должен следовать Web-сервер. Доступ к папке может быть ограничен IP-адресом для определенной папки, или могут быть сконфигурированы имя пользователя и пароль. Эти конфигурации имеют вид контейнеров в httpd.conf, например, определяет, что конфигурация обращается к местоположению на диске, или задает отсылку на путь, указанный в URL. В Листинге 2 показан контейнер Directory в действии. Листинг 2. Контейнер Directory, применяемый к каталогу root AllowOverride None Options FollowSymLinks В Листинге 2 конфигурация, ограниченная тегами Directory и /Directory, применяется к данному каталогу и его содержимому -- в этом случае к каталогу root. Здесь тег AllowOverride определяет, что 17 пользователям не разрешается отменять любые опции (более подробно об этом позже). Опция FollowSymLinks разрешена, что позволяет Apache видеть прошлые символьные линки для обслуживания запроса, даже если файл не входит в каталог, содержащий Web-файлы. Это означает, что если файл в вашем Web-каталоге является символьным линком на /etc/passwd, Webсервер успешно обслужит файл, если поступит запрос. Использование FollowSymLinks отключит эту возможность, и тот же самый запрос будет причиной возврата ошибки клиенту. Последний сценарий - повод для беспокойства на двух фронтах. Первый - вопрос производительности. Если FollowSymLinks отключен, Apache должен проверять каждый компонент имени файла (каталоги и собственно файл), чтобы убедиться, что они не являются символьными линками. Это влечет дополнительные накладные расходы в форме нагрузки на диск. Сопутствующая опцияFollowSymLinksIfOwnerMatch следует за символьным линком, если владелец файла тот же, что и владелец линка. Это оказывает такое же воздействие на производительность, как и отключение следования символьным линкам. Для наилучшей производительности используйте опции из Листинга 2. Читатели, которых волнуют вопросы безопасности, уже должны быть обеспокоены. Безопасность -- всегда компромисс между функциональностью и риском. В этом случае функциональность -- это скорость, и риск предполагает неавторизованный доступ к файлам системы. Смягчающим фактором является то, что серверы приложений LAMP обычно предназначены для определенной функции, и пользователи не могут создавать потенциально опасные символьные линки. Если жизненно необходимо разрешить проверку символьной ссылки, вы можете разрешить это только в определенной области файловой системы, как показано в Листинге 3. 18 Листинг 3. Ограничение FollowSymLinks для каталога пользователя Options FollowSymLinks Options -FollowSymLinks В Листинге 3 любой каталог public_html в домашнем каталоге пользователя имеет опцию FollowSymLinks, отключенную для этого и всех вложенных каталогов. Как вы видели, опции могут конфигурироваться на покаталожной основе через конфигурацию главного сервера. Пользователи могут самостоятельно отменить конфигурацию сервера (если администратором разрешено AllowOverrides), исключив из каталога файл .htaccess. Этот файл содержит дополнительные директивы сервера, которые загружаются и применяются к каждому запросу каталога, в котором содержится файл .htaccess. Несмотря на прежние рассуждения об отсутствии в системе пользователей, многие приложения LAMP используют эту функциональность для осуществления контроля доступа и для перезаписи URL, так что это целесообразно для понимания того, как это работает. Несмотря на то, что утверждение AllowOverrides препятствует пользователям в совершении тех действий, которые вы хотите им запретить, Apache по-прежнему должен искать файл .htaccess, чтобы выяснить, нужно ли что-нибудь сделать. Родительский каталог может определить директивы, которые должны быть обработаны запросом дочернего каталога, что означает, что Apache должен также исследовать каждый компонент дерева 19 каталогов, ведущий к запрашиваемому файлу. По понятным причинам это является причиной высокой дисковой активности по каждому запросу. В Листинге 4 показано, что нужно добавить в httpd.conf, чтобы позволить проверку пароля для пользовательского каталога project, вместо того чтобы помещать информацию в файл .htaccess и надеяться на AllowOverrides. Листинг 4. Перемещение конфигурации .htaccess в httpd.conf AuthUserFile /home/user/.htpasswd AuthName "uber secret project" AuthType basic Require valid-user Если конфигурация помещена в httpd.conf и AllowOverrides отключен, интенсивность использования диска может уменьшиться. Каталог пользователя project может не привлечь большого количества обращений, но учитывайте мощь этого метода применительно к сайту, работающему с большой нагрузкой. Иногда невозможно исключить использование файлов .htaccess. Например, в Листинге 5, где выбор ограничен определенной частью файловой системы, возможность отмены также может быть ограничена. Листинг 5. Ограничение проверки .htaccess AllowOverrides None AllowOverrides AuthConfig 20 После того как вы выполните операции из Листинга 5, Apache все же ищет файлы .htaccess в родительском каталоге, но прекращает поиск в каталоге public_html, поскольку становится невозможным функционирование остальной части файловой системы. Например, если запрашивается файл /home/user/public_html/project/notes.html, то его успешное отображение произойдет только в том случае, если каталоги public_html и project будут найдены. Постоянные соединения Когда клиент соединяется с Web-сервером, разрешается порождение множественных запросов по одному и тому же TCP-соединению, что уменьшает время ожидания, связанное с многократными соединениями. Это полезно, когда Web-страница содержит несколько изображений: клиент может запросить страницу и затем все изображения в течение одного соединения. Обратная сторона состоит в том, что процесс worker на сервере должен ожидать закрытия сеанса клиентом, прежде чем он сможет перейти к следующему запросу. Apache позволяет вам определять, как будут обработаны постоянные соединения, называемые keepalives. KeepAlive 5 на глобальном уровне httpd.conf позволяет серверу обработать 5 запросов на соединение, прежде чем соединение будет насильственно прервано. Установка этого числа в 0 запретит использование постоянных соединений. KeepAliveTimeout, тоже на глобальном уровне, определяет, как долго Apache будет ожидать другого запроса, прежде чем сессия закроется. Сжатие Web-сервер может сжимать вывод, прежде чем он возвратить его клиенту. В результате уменьшается объем страницы, посылаемой по 21 Интернету, за счет циклов CPU на Web-сервере. Для тех серверов, которые могут позволить себе высокую нагрузку на CPU, это отличный способ создания быстро загружаемых страниц — размер страницы может после сжатия уменьшиться втрое. Изображения обычно уже сжаты, поэтому необходимо сжимать только текстовый вывод. Apache предусматривает сжатие при помощиmod_deflate. Несмотря на то, что mod_deflate может быть просто отключен, он содержит множество сложных моментов, которые руководство стремится объяснить. Эта статья не касается темы конфигурирования сжатия, за исключением предоставления ссылки на соответствующую документацию. Настройка PHP PHP -- движок, который запускает код приложений. Вы должны установить только модули, которые планируете использовать, и сконфигурировать ваш Web-сервер для использования PHP только для файлов скриптов (обычно те файлы, названия которых заканчиваются на .php) а не всех статических файлов. 22
«Понятие веб-сервера. Знакомство с lamp (Linux Apache MySQL PHP)» 👇
Готовые курсовые работы и рефераты
Купить от 250 ₽
Решение задач от ИИ за 2 минуты
Решить задачу
Помощь с рефератом от нейросети
Написать ИИ

Тебе могут подойти лекции

Смотреть все 462 лекции
Все самое важное и интересное в Telegram

Все сервисы Справочника в твоем телефоне! Просто напиши Боту, что ты ищешь и он быстро найдет нужную статью, лекцию или пособие для тебя!

Перейти в Telegram Bot