Что такое apache.exe?
Процесс Apache.exe в диспетчере задач WindowsПроцесс, известный как Apache HTTP Server или NVIDIA ForceWare Network Access Manager, принадлежит программному обеспечению NVIDIA ForceWare Network Access Manager или Apache HTTP Server или NVIDIA ForceWare Network Access или драйверам NVIDIA или NVIDIA ForceWare Network или Marvell MRU или Vembu StoreGrid от Apache Software Foundation (www. apache.org).
Описание: Apache.exe не является необходимым для ОС Windows и вызывает относительно мало проблем. Файл apache.exe находится в подпапке «C: \ Program Files (x86)» (в основном C: \ Program Files \ Apache Group \ Apache2 \ bin \ или C: \ Program Files \ Apache Software Foundation \ Apache2.5 \ bin ) Известные размеры файлов в Windows 10/8/7 / XP составляют 20 543 байта (52% всех вхождений), 20 539 байтов и еще 12 вариантов. Процесс запускается как фоновый сервис MRUWebService.
Программа не видна. Файл не является системным файлом Windows. Программное обеспечение использует порты для подключения к локальной сети или Интернету. Поэтому технический рейтинг надежности
Удаление этого варианта: Если у вас есть какие-либо проблемы с apache.exe, вы можете сделать следующее:
- Если apache.exe находится в подпапках диска C: \, тогда рейтинг надежности 66% опасности . Размер файла составляет 20 480 байт. Там нет описания программы. Программа не видна. Это не файл ядра Windows. Приложение прослушивает или отправляет данные об открытых портах в локальную сеть или Интернет.
- Если apache.exe находится в подпапках «C: \ Users \ USERNAME», тогда рейтинг надежности
Важно: некоторые вредоносные программы маскируют себя как apache.exe, особенно если они находятся в папке C: \ Windows или C: \ Windows \ System32. Таким образом, вы должны проверить файл apache.exe на вашем ПК, чтобы убедиться, что это угроза. Мы рекомендуем Security Task Manager для проверки безопасности вашего компьютера. Это был один из лучших вариантов загрузки The Washington Post и PC World .
Аккуратный и опрятный компьютер — это главное требование для избежания проблем с apache. Это означает запуск сканирования на наличие вредоносных программ, очистку жесткого диска с использованием 1 cleanmgr и 2 sfc / scannow, 3 удаления ненужных программ, проверку программ автозапуска (с использованием 4 msconfig) и включение автоматического обновления Windows 5. Всегда не забывайте выполнять периодическое резервное копирование или, по крайней мере, устанавливать точки восстановления.
Если вы столкнулись с реальной проблемой, попробуйте вспомнить последнее, что вы сделали, или последнее, что вы установили до того, как проблема появилась впервые. Используйте команду 6 resmon, чтобы определить процессы, которые вызывают вашу проблему. Даже для серьезных проблем, вместо переустановки Windows, лучше восстановить вашу установку или, для Windows 8 и более поздних версий, выполнить команду 7 DISM.exe / Online / Cleanup-image / Restorehealth. Это позволяет восстанавливать операционную систему без потери данных.
Чтобы помочь вам проанализировать процесс apache.exe на вашем компьютере, оказались полезными следующие программы: Менеджер задач безопасности отображает все запущенные задачи Windows, включая встроенные скрытые процессы, такие как мониторинг клавиатуры и браузера или записи автозапуска. Уникальная оценка риска безопасности указывает на вероятность того, что процесс является потенциальным шпионским ПО, вредоносным ПО или трояном. B Malwarebytes Anti-Malware обнаруживает и удаляет с вашего жесткого диска спящие шпионские, рекламные программы, трояны, кейлоггеры, вредоносные программы и трекеры.
Связанный файл:
originwebhelperservice.exe drvspace.exe esrv.exe apache.exe unchecky_bg.exe maxthon.exe captlib.dll mcthookkey.dll cdakeymonitor.dll searchhelper.dll bittorrentantivirus.exe
$config[ads_text6] not foundПОХОЖИЕ СТАТЬИ
Apache Kafka – Аналитическая платформа – КОРУС Консалтинг
Основные отличия Apache Kafka от традиционных систем обмена сообщениями:
- Apache Kafka – распределенная система, поэтому она приспособлена к масштабированию
- Высокая производительность как в случае публикации сообщений, так и в случае подписки на них
- Apache Kafka сохраняет сообщения на диске, поэтому может использоваться для пакетной передачи данных (например, для ETL-процессов: извлечение, трансформация и загрузка данных)
Компоненты архитектуры Apache Kafka:
- Поток сообщений определенного типа называется темой (Topic). Сообщение – это полезный для происходящего процесса комплект данных, а тема – это категория, в соответствии с которой публикуется то или иное сообщение.
- Производитель (Producer) – это любой процесс, публикующий сообщения в соответствующей теме.
- Опубликованные сообщения отправляются на хранение на кластер серверов (brokers или кластеры Apache Kafka). Брокер – это диспетчер очереди, которая принимает и отдает сообщения между отдельными приложениями внутри системы, где приложения должны пересылать данные друг другу.
- Потребитель (Consumer) может подписаться на одну или несколько тем и использовать сообщения, забирая данные от брокеров.
Поскольку Apache Kafka является распределенной системой, то кластер состоит из нескольких брокеров, а каждый брокер отвечает за хранение одной или нескольких секций. Это дает возможность множеству производителей и потребителей публиковать и использовать сообщения для своих целей одновременно.
Преимущества Apache Kafka:
- Aрхитектура Apache Kafka позволяет потребителям самим регулировать скорость, с которой они будут получать данные, а в случае отказа системы или другой нестандартной ситуации, потребитель всегда имеет возможность получить сообщение повторно.
- Apache Kafka полностью интегрирована со службой ZooKeeper, которая обладает всей необходимой функциональностью для обеспечения безопасности данных и отказоустойчивости.
PHP: Если PHP установлен как модуль Apache
Если PHP используется как модуль Apache, он
наследует права пользователя, с которыми был запущен веб-сервер
(обычно это пользователь «nobody»). Это влияет на обеспечение
безопасности и реализацию авторизации. Например, если вы
используете PHP для доступа к базе данных,
которая не имеет встроенного механизма разграничения доступа,
вам придётся обеспечить доступ к БД для пользователя ‘nobody’.
В таком случае вредоносный скрипт может получить доступ к базе
данных и модифицировать её, даже не зная логина и пароля.
Вполне возможна ситуация, при которой веб-паук неверными запросами
на страницу администратора базы данных может уничтожить все ваши
базы данных. Вы можете избежать такой ситуации при помощи авторизации Apache
или разработав собственную модель доступа, используя LDAP, файлы
Достаточно часто используются такие настройки безопасности, при которых PHP (имеется в виду пользователь, с правами которого выполняется Apache) имеет минимальные привилегии, например, отсутствует возможность записи в пользовательские директории с помощью PHP. Или, например, отсутствует возможность работать с базой данных. При этом система безопасности не позволяет записывать как «хорошие», так и «плохие» файлы, или провести «хорошие» или «плохие» транзакции.
Распространённой ошибкой является запуск Apache с правами суперпользователя или любое другое расширение полномочий веб-сервера.
Расширение привилегий веб-сервера до полномочий суперпользователя угрожает работоспособности всей системы, поэтому такие команды, как sudo, chroot и другие способы запуска с правами суперпользователя должны выполняться исключительно теми, кто профессионально разбирается в вопросах безопасности.
Существует несколько простых решений. Используя open_basedir, вы можете ограничить дерево доступных директорий для PHP. Вы так же можете определить область доступа Apache, ограничив все действия, совершаемые из веба не пользовательскими или несистемными файлами.
Повышение производительности Apache – Блог админа
Ни для кого не секрет что Apache это тяжелый веб-сервер, но бывает так, что от него не получается отказаться в силу ряда причин. И вот, когда ваша система начинает валиться от нагрузки создаваемой Apache, приходит время настройки повышающей производительность веб-сервера. Путей для оптимизации несколько и выбор однолго из них зависит от различных факторов. В этом посте я расскажу немного о паре способов.
По умолчанию Apache компилируют с mpm mod_prefork.c. Проверим с какими модулями он собран:
1 2 3 4 5 6 |
|
Перед установкой apache рассмотрим два варианта которые влияют на производительность и посмотрим как это работает:
Worker VS PreforkWorkerС этим MPM мы улучшаем нашу производительность за счет снижения потребления памяти. Apache запускается как одиночный процесс и запускает множество потоков серверного процесса. Мы можем ограничить количество потоков через директиву apache — ThreadsPerChild.
Преимущества:
- Сервер может обслуживать больше клиентов с меньшими ресурсами.
Недостатки:
- Крах одного процесса нарушит работу сразу ВСЕХ потоков принадлежащих процессу.
- Не совместимо с установкой php в виде модуля (mod_php), потребуется установить fastcgi (запуск PHP как независимого процесса).
- Требует больше конфигурирования.
Директивы влияющие на производительность модуля worker:
- MinSpareThreads: Минимальное количество запасных потоков. В зависимости от значения Apache сохраняет минимальное количество ресурсов для обработки запроса, таким образом новым пользователям не придется ожидать ответа сервера пока он выделит им ресурсы.
- MaxSpareThreads: Максимальное количество запасных потоков.
- ThreadsPerChild: Постояное число потоков создаваемых дочерним процессом.
- ThreadLimit: Максимальное число потоков сконфигурированных в ThreadsPerChild для всего процесса apache.
Основная настройка среднего вебсервера с 2-3 гигабайтами памяти:
1 2 3 4 5 6 7 8 |
|
С модулем prefork существует основной процесс и на каждый запрос apache создает еще один подпроцесс. Родительский процесс стартует от имени root, и каждый дочерний подпроцесс запускается от имени и группы согласно заданным директивам apache.
Таким образом получается изоляция для каждого запущенного процесса, так что проблема одиночного процесса не будет вам сниться в ночных кошмарах 😉
Плюсы:
- Не требуется специализированной настройки.
- Совместимо с mod_php.
- Изоляция проблемных запросов.
- Совместимость с непоточными возможностями.
Минусы:
- Большая нагрузка на процессор и память.
- Хуже масштабируемость.
Директивы влияющие на производительность модуля prefork:
- MinSpareServers: Минимальное число дочерних процессов находящихся в ожидании.
- MaxSpareServers: Максимальное число дочерних процессов в ожидании.
- MaxRequestPerChild: Устанаваливает предел запросов обрабатываемых дочерними процессами. После превышения лимита процесс умирает, что избавляет нас от утечек памяти.
Основная настройка среднего вебсервера с 2-3 гигабайтами памяти:
1 2 3 4 5 6 7 8 |
|
- MaxClients: максимальное количество запросов которое сервер будет обрабатывать одновремено. Все запросы превышающие это число будут поставлены в очередь на основе числа заданного в директиве ListenBacklog.
Оптимальное число может быть разным в зависимости от того сколько памяти у вашего сервера, посчитать его можно так:[(Всего памяти — Память используемая другими процессами) / размер памяти каждого процесса apache или его потока]
Для того чтобы узнать размер процесса :1
# ps -ylC httpd --sort rss - ServerLimit: Для модуля prefork устанавливает максимальное значение для MaxClients на весь процесс apache. При использовании модуля worker используется в сочетании с директивой ThreadLimit. Минумум этого значения должен быть таким же как и MaxClients, иначе эта директива не будет иметь эффекта.
- TimeOut: Время которое Apache ждет три вещи:
1- Полное время получения запроса GET.
2- Интервал времени между TCP пакета в POST или PUT запросах.
3- Интервал времени между ACK для ответных пакетов TCP. По хорошему это значение должно быть в районе 30 секунд до закрытия подключения, большее значение может повлиять на большее число выделеных, но не используемых ресурсов. - KeepAlive: Обеспечивает несколько ответов на запросы через одно TCP подключение.
- MaxKeepAliveRequests: количество запросов на одно подключение. Вы можете вычислить это значение по тому сколько запросов делает один посетитеть, число может оказаться огромным, но не выставляйте его слишком большим, одна атака может положить положить весь процесс в одной сессии.
- KeepAliveTimeout: Количество секунд в течении которых Apache ждет подзапрос до того как закроет подключение. Как только запрос будет получен значение таймаута изменится на то которое задано в директиве TimeOut.
- Отключение выполнения файла .htacess запрещает apache проверять существование файла .htaccess на каждом уровне переданного пути.
1
2
3
<directory />AllowOverride None</directory> - Включение символьных ссылок:
1
2
3
<directory />Options FollowSymLinks</directory> - Запрет апачу проверять кто является владельцем символьной ссылки.
1
2
3
<directory/document/path>Options +FollowSymLinks -SymLinksIfOwnerMatch</directory>
Если вы настроены решительно и хотите еще больше оттюнинговать ваш Apache то вам сюда: http://httpd.apache.org/docs/2.2/mod/#core
Логи в Apache | Apache
Каждому из нас хочется побыть «большим братом» и последить за своими посетителями. Это можно делать по-разному: поставить счетчик, например, HotLog, поставить особый скрипт, ну а некоторые делают это с помощью логов Apache. Да-да, вы не ослышались, Apache тоже ведет логи.
На практике необходимо понять значение всего двух директив: LogFormat и CustomLog. Есть еще директива ErrorLog, но лично я использую лог ошибок только для просмотра последних строчек, когда Apache не пускается. Все-таки скажу несколько слов о ErrorLog.
Сами разработчики считают лог ошибок сервера, создающийся директивой ErrorLog, и хранящий все сообщения об ошибках и всю диагностику, наиболее важным логом. Не верьте им. Еррор-лог создается так:
Практически никак не настраивается, однако есть важная директива LogLevel. Она дает указания серверу писать или не писать в лог ошибки различной степени тяжести. Например, директива
Заставит сервер жаловаться только на самые критические проблемы, когда сервер не запускается. Далее параметры по убывающей: alert, crit, error, warn, notice, info и, конечно же, мой любимый
При котором вам будет рассказано даже о том, что сервер все-таки открывает в данный момент файл конфигурации 🙂
Таким образом, если вам нужны логи ошибок, то в httpd.conf следует указать директиву ErrorLog с параметром «имя лога» (путь считается относительно ServerRoot) и LogLevel с параметром «степень точности». Далее все на вашей совести 🙂
Теперь о том, что считаю важным я: Combined Logs. Эти логи повествуют о том, кто, когда и зачем отправлял запросы к серверу. Правда, интересно? Здесь еще две директивы: LogFormat и CustomLog. Покопайтесь в каком-нибудь httpd.conf и вы обязательно увидите там что-нибудь типа
LogFormat "%h %l %u %t "%r" %>s %b" common CustomLog logs/access_log common
Хех, все понятно? Сейчас объясню что это значит. LogFormat принимает два параметра: описание формата лога и название этого формата. Как видите, лог, состоящий из «%h %l %u %t «%r» %>s %b» называется common. А что значат закорючки, читайте тут:
%h — IP клиента. Кстати, это запросто может быть и ип его прокси.
%l — это что-то непонятное, касающееся идентификации клиента по RFC 1413. Кстати, апач не пытается ее определить, если только директива IdentityCheck не установлена в On
%u — то, что было введено в качестве имени пользователя а HTTP-авторизации. То же самое, что и $HTTP_AUTH_USER 🙂
%t — время поступления запроса. В комментариях не нуждается.
%r — строка запроса клиента, например «GET /xxx.gif HTTP/1.1». Обычно заключается в кавычки, но поскольку кавычки — спецсимволы, они предваряются бэкслэшами — . Таким образом, то, что будет выглядеть в логе как строчка в кавычках, оформляется так: «%r»
%>s — код ответа сервера клиенту.
%b — размер ответа клиенту. В байтах.
%{Referer} — адрес страницы, откуда пришел посетитель.
%{User-agent} — тип браузера посетителя. Этот и предыдущий параметр тоже обычно указывают в кавычках, как и %r
Эти параметры можно комбинировать в любом порядке и в любом количестве. Захотите определять только IP посетителей — пишете так:
Вот и определен новый формат лога. В общем, комбинируйте как хотите. Но логи эта директива не создает. Чтобы сервер начал писать лог, надо потребовать этого директивой CustomLog, которая принимает два параметра: имя файла лога и его тип. Таким образом, чтобы записывать IP клиентов, надо добавить еще и такую строчку:
CustomLog logs/iponly.log iponly
И только после этого лог начнет нормально вестись. Кстати, популярным считается стандарт «combined log», описывающийся так:
LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combinedКак видите, довольно информативно. А теперь на минуту представьте себе, что ваш сервер обрабатывает около миллиона запросов в день. И вам охота вести несколько логов. Ну это обычное явление: сколько скажете раз CustomLog, столько логов и создастся, а ну как вам захочется всех поисковиков, ищущих robots.txt писать в отдельный лог? Ладно. Рассказываю.
Есть еще такая полезная директива SetEnvIf (или SetEnvIfNoCase — то же самое, но без учета больших/маленьких букв), она позволяет в зависимости от условия определять переменные среды.robots.txt$» crawler
После этого переменная env будет равняться «crawler». Но это еще не все! В зависимости от значения этой переменной вы можете делать запись в разные логи! Вот так:
CustomLog logs/crawlers combined env=crawler CustomLog logs/clients combined env=!crawler
Вот так, нашему апачу палец в рот не клади 🙂 Не буду рассказывать почему robots.txt так странно написано, называется это регулярные выражения, а почитать про них можно либо в учебнике, либо в странице мануала перла по имени perlre. Вот так: man perlre. Под юниксом, конечно 🙂
Уфф… Все, вроде? Нет, есть еще пипы. Пипы (pipes) позволяют предварительно (прежде чем чего-то в логи записать), что-нибудь эдакое с ними сотворить, например сжать. Стандартный значок пипы в юниксе — вертикальная палка, так что если вам приспичит логи сразу сжимать, делайте так:
CustomLog "|/usr/bin/gzip -c >> /var/log/access_log.gz" common
Все под юниксом 🙂 Просто потому, что если у вас апач на винде, то логи вести незачем — врядли она у вас сервером работает %)
P.S. Большая часть этого материала — вольный перевод соотвествующих статей из Apache Manual. Он лежит здесь: http://httpd.apache.org.
P.P.S. Счастья вам и радости!
P.P.P.S. Ах, да… удобно, если надо что-то проверить в работе сервера, следить за логом в «реальном времени», вот так:
$ tail -f /etc/httpd/logs/logfile
Apache vs Nginx — База знаний cPanel хостинг
Apache и Nginx — 2 самых широко распространенных веб-сервера с открытым исходным кодом в мире. Вместе они обслуживают более 50% трафика во всем интернете. Оба решения способны работать с разнообразными рабочими нагрузками и взаимодействовать с другими приложениями для реализации полного веб-стека.
Несмотря на то, что у Apache и Nginx много схожих качеств, их нельзя рассматривать как полностью взаимозаменямые решения. Каждый из них имеет собственные преимущества и важно понимать какой веб-сервер выбрать в какой ситуации. В этой статье описано то, как каждый из этих веб-серверов ведет себя при различных условиях.
Общий обзор
Прежде чем погрузиться в различия между Apache и Nginx давайте бегло взглянем на предысторию каждого из этих проектов.
Apache
Apache HTTP Server был разработан Робертом Маккулом в 1995 году, а с 1999 года разрабатывается под управлением Apache Software Foundation — фонда развития программного обеспечения Apache. Так как HTTP сервер это первый и самый популярный проект фонда его обычно называют просто Apache.
Веб-север Apache был самым популярным веб-сервером в интернете с 1996 года. Благодаря его популярности у Apache сильная документация и интеграция со сторонним софтом.
Администраторы часто выбирают Apache из-за его гибкости, мощности и широкой распространенности. Он может быть расширен с помощью системы динамически загружаемых модулей и исполнять программы на большом количестве интерпретируемых языков программирования без использования внешнего программного обеспечения.
Nginx
В 2002 году Игорь Сысоев начал работу над Nginx для того чтобы решить проблему C10K — требование к ПО работать с 10 тысячами одновременных соединений. Первый публичный релиз был выпущен в 2004 году, поставленная цель была достигнута благодаря асинхронной event-driven архитектуре.
Nginx начал набирать популярность с момента релиза благодаря своей легковесности (light-weight resource utilization) и возможности легко масштабироваться на минимальном железе. Nginx превосходен при отдаче статического контента и спроектирован так, чтобы передавать динамические запросы другому ПО предназначенному для их обработки.
Администраторы часто выбирают Nginx из-за его эффективного потребления ресурсов и отзывчивости под нагрузкой, а также из-за возможности использовать его и как веб-сервер, и как прокси.
Архитектура обработки соединений
Одно из самых существенных отличий между Apache и Nginx состоит в том как они обрабатывают соединения и отвечают на различные виды трафика.
Apache предоставляет несколько модулей мультипроцессинга (multi-processing modules, MPM), которые отвечают за то как запрос клиента будет обработан. Это позволет администраторам определять политику обработки соединений. Ниже представлен список MPM-модулей Apache:
- mpm_prefork — этот модуль создает по одному процессу с одним потоком на каждый запрос. Каждый процесс может обрабатывать только одно соединение в один момент времени. Пока число запросов меньше числа процессов этот MPM работает очень быстро. Однако производительность быстро падает когда число запросов начинает превосходить число процессов, поэтому в большинстве случаев это не самый лучший выбор. Каждый процесс потребляет значительный объем RAM, поэтому этот MPM сложно поддается масштабированию. Но он может быть использован вместе с компонентами, которые не созданы для работы в многопоточной среде. Например, PHP не является потокобезопасным, поэтому этот MPM рекомендуется использовать как безопасный метод работы с mod_php.
- mpm_worker — этот модуль создает процессы, каждый из которых может управлять несколькими потоками. Каждый поток может обрабтывать одно соединение. Потоки значительно более эффективны чем процессы, что означает что mpm_worker масштабируется значительно лучше чем mpm_prefork. Так как потоков больше чем процессов это означает, что новое соединение может быть сразу обработано свободным потоком, а не ждать пока освободится процесс.
- mpm_event — этот модуль похож на mpm_worker, но оптимизрован под работу с keep-alive соединениями. Когда используется mpm_worker соединение будет удерживать поток вне зависимости от того активное это соединение или keep-alive. Mpm_event выделяет отдельные потоки для keep-alive соединений и отдельные потоки для активных соединений. Это позволяет модулю не погрязнуть в keep-alive соединениях, что необходимо для быстрой работы. Этот модуль был отмечен как стабильный в Apache версии 2.4.
Как вы можете видеть Apache предлагает гибкие возможности для выбора различных алгоритмов обработки соединений и запросов.
Nginx
Nginx появился на сцене позднее Apache, по этой причине, его разработчик был лучше осведомлен о проблемах конкурентности, с которыми сталкиваются сайты при масштабировании. Благодаря этим знаниям Nginx изначально был спроектирован на базе асинхронных неблокирующих event-driven алгоритмов.
Nginx создает процессы-воркеры каждый из которых может обслуживать тысячи соединений. Воркеры достигают такого результата благодаря механизму основанному на быстром цикле, в котором проверяются и обрабатываются события. Отделение основной работы от обработки соединений позволяет каждому воркеру заниматься своей работой и отвлекаться на обработку соединений только тогда когда произошло новое событие.
Каждое соединение, обрабатываемое воркером, помещается в event loop вместе с другими соединениями. В этом цикле события обрабатываются асинхронно, позволяя обрабатывать задачи в неблокирующей манере. Когда соединение закрывается оно удаляется из цикла.
Этот подход к обработке соединений позволяет Nginx’у невероятно масштабироваться при ограниченных ресурсах. Поскольку сервер однопоточный и он не создает процессы под каждое соединение, использование памяти и CPU относительно равномерно, даже при высоких нагрузках.
Статический и динамический контент
Если рассматривать жизненные примеры, то основные различия между Apache и Nginx в том как они обрабатывают запросы к статическому и динамическому контенту.
Apache
Apache может раздавать статический контент используя стандартные file-based методы. Производительность таких операций зависит от выбранного MPM.
Apache также может раздавать динамический контент встраивая интерпретатор нужного языка в каждого воркера. Это позволяет обрабатывать запросы к динамическому содержимому средствами самого веб-сервера и не полагаться на внешние компоненты. Интерпретаторы языков могут быть подключены к Apache с помощью динамически загружаемых модулей.
Возможность обрабатывать динамический контент средствами самого Apache упрощает конфигурирование. Нет необходимости настраивать взаимодействие с дополнительным софтом, динамический модуль может быть легко отключен в случае изменившихся требований.
Nginx
Nginx не имеет возможности самостоятельно обрабатывать запросы к динамическому контенту. Для обработки запросов к PHP или другому динамическому контенту Nginx должен передать запрос внешнему процессору для исполнения, подождать пока ответ будет сгенерирован и получить его. Затем результат может быть отправлен клиенту.
Для администраторов это означает, что нужно настроить взаимодействие Nginx с таким процессором используя один из протоколов, который известен Nginx’у (http, FastCGI, SCGI, uWSGI, memcache). Это может немного усложнить процесс настройки, в особенности когда вы будете пытаться предугадать какое число соединений разрешить, так как будет использоваться дополнительное соединение с процессором на каждый пользовательский запрос.
Однако, этот метод имеет и свои преимущества. Так как интерпретатор не встроен в каждого воркера, то оверхед, связанный с этим, будет иметь место только при запросах к динамическому контенту. Статический контент будет возвращен клиенту простым способом и запросы к интерпретатору будут выполняться только тогда когда они нужны. Apache тоже может работать в такой манере, но тогда это лишит его всех преимуществ описанных в предыдущем разделе.
Распределенная конфигурация против централизованной
Для администраторов одним из очевидных отличий этих двух веб-серверов является наличие у Apache возможности задавать конфигурацию на уровне директории.
Apache
Apache имеет опцию, которая позволяет включить конфигурирование на уровне директорий. Если эта опция включена, то Apache будет искать конфигурационные директивы в директориях с контентом в специальных скрытых файлах, которые называются .htaccess.
Так как такие конфигурационные файлы находятся в директриях с контентом, Apache вынужден при обработке каждого запроса проверять не содержит ли каждый компонент запрашиваемого пути файл .htaccess и исполнять директивы в найденных файлах. Это позволяет децентрализовать конфигурирование веб-сервера, что позволяет реализовать на уровне директорий модификацию URL’ов (URL rewrite), ограничения доступа, авторизацию и аутентификацию и даже политики кеширования.
Несмотря на то, что все описанное выше может быть настроено и в основном конфигурационном файле Apache, файлы .htaccess имеют ряд преимуществ. Во-первых, эти файлы интерпретируются как только они найдены по запрашиваемому пути, что позволяет менять конфигурацию на лету не перезагружая веб-сервер. Во вторых, это позволяет дать возможность непривилегированным пользователям контролировать определынные аспекты собственных веб-приложений с помощью .htaccess.
Это дает простой способ таким приложениям как системы управления контентом (CMS) конфигурировать собственное окружение не имея доступа к конфигурационному файлу веб-сервера. Это также может быть использовано шаред хостингами, чтобы сохранить контроль над основным конфигурационным файлом и дать клиентам контроль над конфигурацией определенных директорий.
Nginx
Nginx не интерпретирует файлы .htaccess и не предоставляет механизм конфигурирования на уровне директорий за пределами основного конфигурационного файла. Этот подход может показаться менее гибким чем в случае с Apache, но он имеет свои преимущства.
Основное преимущество перед использованием .htaccess — это улучшенная производительность. Типичная установка Apache позволяет использовать файлы .htaccess в любой директории, поэтому веб-сервер при каждом запросе вынужден проверять наличие этого файла во всех родительских директориях запрошенного файла. Если найден один или более таких файлов, то все они должны быть прочитаны и интерпретированы.
Так как Nginx не позволяет переопределять конфиги на уровне директорий, он может обрабатывать запросы быстрее, ведь ему достаточно сделать один directory lookup и прочитать один конфигурационный файл на каждый запрос (предполагается, что файл найден там где он должен быть по соглашению).
Второе преимущество связано с безопасностью. Распределенная конфигурация на уровне директорий в Apache возлагает ответственность за безопасность на обычных пользователей, которые вряд ли способны решить эту задачу качественно. То что администратор контролирует весь сервер предотвращает ошибки безопасности, которые могут возникнуть если дать пользователям доступ к конфигурации.
Имейте ввиду, что вы можете отключить поддержку .htaccess в Apache, если сказанное выше произвело на вас впечатление.
Интерпретация базирующаяся на файлах и URI
То как веб-сервер интерпретирует запрос и сопоставляет его с ресурсом в системе это еще одна отличительная особенность в этих двух серверах.
Apache
Apache имеет возможность интерпретировать запрос как физический ресурс в файловой системе или как URI, который требует дополнительной обработки. Первый тип запросов использует конфигурационные блоки или , второй — блоки .
Так как Apache изначально был спроектирован как веб-сервер, он по умолчанию интерпретирует запросы как ресурсы в файловой системе. Он берет document root веб-сервера и дополняет его частью запроса, которая следует за именем хоста и номером порта, чтобы найти запрашиваемый файл. В общем случае, иерархия файловой системы представленная в вебе доступна как дерево документов.
Apache предоставляет ряд альтернатив на случай когда запрос не соответствует файлу в файловой системе. Использование блоков это метод работы с URI без отображения на файловую систему. Также возможно использовать регулярные выражения, которые позволяют задать более гибкие настройки для всей файловой системы.
Так как Apache может оперировать и c файловой системой, и с webspace, то он в основном опирается на методы работы с файловой системой. Это видно в некоторых решениях в дизайне архитектуры веб-сервера, например, в использовании файлов .htaccess для конфигурирования на уровне директорий. Документация к Apache не рекомендует использовать URI-блоки для ограничения доступа для запросов к файловой системе.
Nginx
Nginx создан, чтобы работать и в качестве веб-сервера, и в качестве прокси-сервера. По этой причине он работает в первую очередь с URI, транслируя их при необходимости в запросы к файловой системе.
Эта особенность прослеживается в том как для Nginx конструируются и интерпретируются конфигурационные файлы. В Nginx нет способа создать конфигурацию для заданной директории, вместо этого он парсит URI.
Например, основными конфигурационными блоками в Nginx являются и . В блоке определяется хост, который будет обслуживаться, блок отвечает за обработку части URI, которая идет после имени хоста и номера порта. Таким образом, запрос интерпретируется как URI, а не как путь в файловой системе.
В случае запросов к статическим файлам все запросы должны быть отображены (mapped) на путь в файловой системе. Сначала Nginx выбирает блоки server и location, которые будут использованы для обработки запроса и затем объединяет document root с URI, в соответствии с конфигурацией.
Эти подходы (интерпретация запроса как пути в файловой системе и как URI) могут показаться похожими, но тот факт что Nginx рассматривает запросы как URI, а не как пути в файловой системе позволяет ему легче справляться одновременно и с ролью веб-сервера, и с ролью прокси. Nginx конфигурируется так, чтобы отвечать на различные шаблоны запросов. Nginx не обращается к файловой системе до тех пор пока он не готов обслужить запрос, что объясняет почему он не реализует ничего похожего на файлы .htaccess.
Модули
И Apache, и Nginx могут быть расширены при помощи системы модулей, но способы реализации модульной системы принципиально отличаются.
Apache
Система модулей Apache позволяет динамически загружать и выгружать модули, чтобы удовлетворить ваши потребности, в то время как ваш сервер запущен. Ядро Apache всегда доступно, в то время как модули можно включать и выключать, чтобы добавить или удалить функциональность из основного сервера.
Apache использует эту функциональность для решения широкого круга задач. Благодаря зрелости платформы существует огромное множество модулей, которые могут изменять ключевые особенности сервера, например модуль mod_php позволяет включать PHP-интерпретатор в кажого воркера.
Использование модулей не ограничивается лишь обработкой динамических запросов. Среди других возможностей модулей: изменение URL’ов (URL rewrite), аутентификация клиентов, защита сервера, логгирование, кеширование, сжатие, проксирование, ограничение частоты запросов, шифрование. Динамические модули могут значительно расширить функцональность ядра.
Nginx
Nginx тоже имеет систему модулей, но она сильно отличается от подхода используемого в Apache. В Nginx модули загружаются не динамически, а должны быть выбраны и скомпилированы с ядром сервера.
Для многих пользователей по этой причине Nginx кажется менее гибким. Это особенно относится к пользователям, кто имеет мало опыта ручной сборки приложений и предпочитают использовать системы управления пакетами. Обычно разработчики дистрибутивов стремятся создать пакеты для всех часто используемых модулей, но если вам нужен какой-то нестандартный модуль вам придется собрать его из исходников самостоятельно.
Тем не менее, модули в Nginx очень полезны и востребованы, вы можете определить чего вы хотите от сервера и включить только те модули, что вам нужны. Некоторые пользователи считают такой подход более безопасным так как произвольные модули не могут быть подключены к серверу.
Модули Nginx реализуют те же возможности, что и модули Apache: проксирование, сжатие данных, ограничение частоты запросов, логгирование, модификация URL’ов, гео-локация, аутентификация, шифрование, потоковое вещание, почтовые функции.
Поддержка, совместимость, экосистема и документация
В процессе использования приложения важными являются экосистема созданная вокруг него и возможность получения поддержки.
Apache
Так как Apache пользуется популярностью такое длительное время с поддержкой у него нет проблем. Легко можно найти большое количество документации как от разработчиков Apache, так и от сторонних авторов. Эта документация покрывает все возможные сценарии использования Apache, включая взаимодействие с другими приложениями.
Существует много инструментов и веб-проектов идущих в комплекте со средствами запуска самих себя из под Apache. Это относится как к самим проектам, так и к системам управления пакетами.
В общем случае Apache будет иметь больше поддержки в сторонних проектах просто потому он доступен на рынке длительное время. Администраторы также обычно имеют больше опыта работы с Apache, так как большинство людей начинают работу с шаред-хостингов где Apache более популярен из-за поддержки файлов .htaccess.
Nginx
Nginx обычно используется там, где предъявляются повышенные требования к производительности и в некоторых областях он все еще является догоняющим.
В прошлом было сложно найти вменяемую поддержку по этому веб-серверу на английском языке, так как на ранних этапах разработка и документация велись на русском языке. Вместе с ростом интереса к проекту документация была переведена на английский и теперь можно найти достаточное количество документации и от разработчиков веб-сервера, и от сторонних авторов.
Разработчики стороннего ПО также начинают поддерживать работу с Nginx и некоторые из них уже предлагают на выбор пользователя конфиги для работы или с Apache, или с Nginx. И даже без поддержки приложением работы с Nginx не составляет большого труда написать свой конфиг для интеграции приложения с Nginx.
Совместное использование Apache и Nginx
После того как вы ознакомились с плюсами и минусами Apache и Nginx у вас должно появиться представление того, какой из серверов больше подходит под ваши задачи. Однако, можно достигнуть лучших результатов используя оба сервера вместе.
Распространенной схемой использования является размещение Nginx перед Apache в качестве реверс-прокси. В такой конфигурации Nginx называют фронтендом, а Apache — бэкендом. При таком подходе Nginx будет обслуживать все входящие запросы клиентов и мы получим выигрыш из-за его возможности обрабатывать множество конкурентных запросов.
Nginx будет самостоятельно обслуживать статический контент, а для динамического контента, например для запросов к PHP-страницам, будет передавать запрос к Apache, который будет рендерить страницу, возвращать ее Nginx’у, а тот в свою очередь будет передавать ее пользователю.
Такая конфигурация очень популярна, Nginx используется в ней для сортировки запросов. Он обрабатывает сам те запросы которые может и передает Apache только запросы, которые не может обслужить сам, снижая таким образом нагрузку на Apache.
Эта конфигурация позволяет горизонтально масштабировать приложение: вы можете установить несколько бэкенд серверов за одним фронтендом и Nginx будет распределять нагрузку между ними, увеличивая тем самым отказоустойчивость приложения.
Заключение
Как вы можете видеть и Apache, и Nginx — это мощные, гибкие и функциональные инструменты. Для того чтобы выбрать сервер под ваши задачи необходимо определиться с требованиями к нему и провести тесты на всех возможных паттернах использования вашего приложения.
Между этими проектами есть значительные различия, которые могут оказать влияние на производительность, возможности и время реализации необходимое для внедрения и запуска каждого из решений. Выбор является серией компромиссов и не стоит пренебрегать тестами. В конечном итоге, не существует одного универсального веб-сервера под все возможные задачи, поэтому важно найти решение максимально соответствующее вашем задачам и целям.
Источник: https://habr.com/ru/post/267721/
Вконтакте
Одноклассники
Мой мир
LiveJournal
Apache vs Nginx
Apache Bench — Краткое руководство
Тестирование производительности оказалось решающим для успеха бизнеса. Мало того, что плохо работающий сайт сталкивается с финансовыми потерями, он также может время от времени приводить к юридическим последствиям.
Никто не хочет мириться с медленным, ненадежным сайтом в важных онлайн-взаимодействиях, таких как покупки, онлайн-тестирование, оплата счетов и т. Д. Благодаря широкому доступу в Интернет диапазон альтернатив огромен. Проще потерять клиентуру, чем завоевать ее, и производительность играет ключевую роль в игре.
Необходим инструмент для нагрузочного тестирования
Если мы сможем понять, для чего нужен инструмент нагрузочного тестирования, это даст нам причину и мотивацию для его использования. Некоторые известные бизнес-сайты пострадали серьезные простоя, когда они получают большое количество посетителей. Сайты электронной коммерции вкладывают большие средства в рекламные кампании, но не в нагрузочное тестирование. Поэтому они не могут обеспечить оптимальную производительность системы, когда этот маркетинг приносит трафик.
Другим знакомым примером игнорирования нагрузочного тестирования является «ошибка при установлении соединения» на сайтах WordPress. Поэтому рекомендуется выполнить нагрузочное тестирование веб-сайта или приложения перед его внедрением в производство. Хорошо бы быстро создать наилучший сценарий для проекта, прежде чем проводить более подробные тесты в будущем.
Что такое Apache Bench?
Apache Bench (ab) — это инструмент организации Apache для тестирования веб-сервера по протоколу гипертекстовой передачи (HTTP). Хотя он предназначен для измерения производительности веб-сервера Apache, он также может использоваться для тестирования любого другого веб-сервера, который одинаково хорош. С помощью этого инструмента вы можете быстро узнать, сколько запросов в секунду способен обслуживать ваш веб-сервер.
Особенности Apache Bench
Давайте посмотрим на важные функции и ограничения Apache Bench. Функции и ограничения перечислены ниже —
Будучи программным обеспечением с открытым исходным кодом, оно свободно доступно.
Это простая компьютерная программа командной строки.
Это независимый от платформы инструмент. Это означает, что он может быть вызван на Linux / Unix или на сервере Windows одинаково хорошо.
Он может проводить нагрузку и тестирование производительности только для веб-сервера — HTTP или HTTPS.
Это не растяжимо.
Будучи программным обеспечением с открытым исходным кодом, оно свободно доступно.
Это простая компьютерная программа командной строки.
Это независимый от платформы инструмент. Это означает, что он может быть вызван на Linux / Unix или на сервере Windows одинаково хорошо.
Он может проводить нагрузку и тестирование производительности только для веб-сервера — HTTP или HTTPS.
Это не растяжимо.
Apache Bench использует только один поток операционной системы независимо от уровня параллелизма (указанного в флаге -c). Следовательно, при тестировании серверов большой емкости отдельный экземпляр Apache Bench может сам по себе стать узким местом. Чтобы полностью насытить целевой URL, лучше использовать дополнительные экземпляры Apache Bench параллельно, если ваш сервер имеет несколько процессорных ядер.
предосторожность
Вы должны знать, что в Apache Bench нет директивы для увеличения параллелизма в определенных интервалах во время выполнения тестов. Поэтому выполнение нагрузочных тестов с использованием ab эквивалентно атаке типа «отказ в обслуживании» (DOS). Рекомендуется сообщить и получить предварительное разрешение от поставщика услуг VPS, если вы собираетесь проводить тестирование с высокой нагрузкой в течение длительного периода времени. Они предоставят вам соответствующий интервал времени или сместят ваш узел для задачи нагрузочного тестирования.
Во-вторых, если вы тестируете веб-сайт третьего лица непрерывно и в течение длительного времени только для изучения Apache Bench с вашего VPS (который становится узлом тестирования), существует вероятность того, что ваш публичный IP-адрес VPS может быть заблокирован веб-сайтом третьего лица. постоянно. В этом случае вы не сможете подключиться к этому веб-сайту с тем же IP-адресом. Но если вы действительно хотите подключиться к сайту в будущем, единственным решением будет поговорить с системным администратором целевого сайта или создать новый экземпляр сервера с другим IP-адресом с помощью вашего поставщика услуг VPS.
Предупредив вас, позвольте мне заверить вас, что все тесты в этом учебном пособии достаточно безопасны и не соответствуют тому, что системные администраторы обычно называют практикой «злоупотребления системой».
В этой главе мы расскажем вам, как настроить вашу среду для Apache Bench на вашем VPS.
Системные требования
Память — 128 МБ
Дисковое пространство — нет минимальных требований
Операционная система — Нет минимальных требований
Память — 128 МБ
Дисковое пространство — нет минимальных требований
Операционная система — Нет минимальных требований
Установка Apache Bench
Apache Bench является автономным приложением и не зависит от установки веб-сервера Apache. Ниже приведен двухэтапный процесс установки Apache Bench.
Шаг 1 — Обновление базы данных пакетов.
# apt-get update
Обратите внимание, что символ # перед командой терминала означает, что пользователь root выполняет эту команду.
Шаг 2 — Установите пакет утилит apache2, чтобы получить доступ к Apache Bench.
# apt-get install apache2-utils
Apache Bench теперь установлен. Если вы хотите протестировать веб-приложение, размещенное на том же VPS, достаточно установить только веб-сервер Apache —
# apt-get install apache2
Будучи утилитой Apache, Apache Bench автоматически устанавливается при установке веб-сервера Apache.
Проверка установки Apache Bench
Давайте теперь посмотрим, как проверить установку Apache Bench. Следующий код поможет проверить установку —
# ab -V
Выход
This is ApacheBench, Version 2.3 <$Revision: 1604373 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/
Когда вы видите вышеупомянутый вывод терминала, это означает, что вы успешно установили Apache Bench.
Создание привилегированного пользователя Sudo
С точки зрения безопасности, для системного администратора считается хорошей практикой создавать пользователя sudo вместо того, чтобы работать от имени пользователя root. Мы создадим тестового пользователя с именем test для этой цели —
# useradd -m -d /home/test -g sudo test
Давайте установим пароль для нового пользователя —
# passwd test
Система запросит новый пароль для пользовательского теста. Вы можете ввести простой пароль, поскольку мы просто тестируем его, а не внедряем на рабочий сервер. Обычно команда sudo предлагает ввести пароль пользователя sudo; Рекомендуется не использовать сложный пароль, так как процесс становится громоздким.
Выход
Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully
Тестирование сайта Apache.org
В этом разделе мы протестируем веб-сайт Apache.org. Давайте сначала переключимся на пользовательский тест sudo —
# su test
Для начала мы проверим веб-сайт организации Apache, https://www.apache.org/ . Сначала мы запустим команду, а затем поймем вывод —
$ ab -n 100 -c 10 https://www.apache.org/
Здесь -n — количество запросов, которые нужно выполнить для сеанса бенчмаркинга. По умолчанию выполняется только один запрос, который обычно приводит к непредставительным результатам сравнительного анализа.
И -c — это параллелизм, который обозначает количество одновременных запросов. По умолчанию один запрос за раз.
Таким образом, в этом тесте Apache Bench сделает 100 запросов с параллелизмом 10 на сервер организации Apache.
Выход
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.apache.org (be patient).....done
Server Software: Apache/2.4.7
Server Hostname: www.apache.org
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256
Document Path: /
Document Length: 58769 bytes
Concurrency Level: 10
Time taken for tests: 1.004 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 5911100 bytes
HTML transferred: 5876900 bytes
Requests per second: 99.56 [#/sec] (mean)
Time per request: 100.444 [ms] (mean)
Time per request: 10.044 [ms] (mean, across all concurrent requests)
Transfer rate: 5747.06 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 39 46 30.9 41 263
Processing: 37 40 21.7 38 255
Waiting: 12 15 21.7 13 230
Total: 77 86 37.5 79 301
Percentage of the requests served within a certain time (ms)
50% 79
66% 79
75% 80
80% 80
90% 82
95% 84
98% 296
99% 301
100% 301 (longest request)
Запустив наш первый тест, вам будет легко распознать схему использования этой команды, которая выглядит следующим образом:
# ab [options .....] URL
где,
ab — команда Apache Bench
параметры — флаги для конкретной задачи, которую мы хотим выполнить
URL — путь URL, который мы хотим проверить
ab — команда Apache Bench
параметры — флаги для конкретной задачи, которую мы хотим выполнить
URL — путь URL, который мы хотим проверить
Понимание выходных значений
Нам нужно понимать различные метрики, чтобы понимать различные выходные значения, возвращаемые ab. Здесь идет список —
Серверное программное обеспечение — это имя веб-сервера, возвращаемое в заголовке HTTP первого успешного возврата.
Имя хоста сервера — это DNS или IP-адрес, указанный в командной строке.
Порт сервера — это порт, к которому подключается ab. Если порт не указан в командной строке, по умолчанию будет установлено значение 80 для http и 443 для https.
Протокол SSL / TLS — это параметр протокола, согласованный между клиентом и сервером. Это будет напечатано, только если используется SSL.
Путь документа — это URI запроса, проанализированный из строки командной строки.
Длина документа — это размер в байтах первого успешно возвращенного документа. Если длина документа изменяется во время тестирования, ответ считается ошибкой.
Уровень параллелизма — это количество одновременных клиентов (эквивалентных веб-браузерам), использованных во время теста.
Время, затраченное на тесты — это время, затрачиваемое с момента создания первого сокетного соединения до момента получения последнего ответа.
Выполнено запросов — количество полученных успешных ответов.
Failed Requests — количество запросов, которые были признаны ошибочными. Если число больше нуля, будет напечатана другая строка, показывающая количество запросов, которые не были выполнены из-за подключения, чтения, неправильной длины содержимого или исключений.
Всего перенесено — общее количество байтов, полученных с сервера. Это число по сути количество байтов, отправленных по проводам.
Переданный HTML — общее количество байтов документа, полученных с сервера. Это число исключает байты, полученные в заголовках HTTP
Количество запросов в секунду — это количество запросов в секунду. Это значение является результатом деления количества запросов на общее время.
Время на запрос — среднее время, затраченное на запрос. Первое значение рассчитывается по формуле параллелизма * timetaken * 1000 / done, а второе значение рассчитывается по формуле timetaken * 1000 / done.
Скорость передачи — скорость передачи, рассчитанная по формуле totalread / 1024 / timetaken.
Серверное программное обеспечение — это имя веб-сервера, возвращаемое в заголовке HTTP первого успешного возврата.
Имя хоста сервера — это DNS или IP-адрес, указанный в командной строке.
Порт сервера — это порт, к которому подключается ab. Если порт не указан в командной строке, по умолчанию будет установлено значение 80 для http и 443 для https.
Протокол SSL / TLS — это параметр протокола, согласованный между клиентом и сервером. Это будет напечатано, только если используется SSL.
Путь документа — это URI запроса, проанализированный из строки командной строки.
Длина документа — это размер в байтах первого успешно возвращенного документа. Если длина документа изменяется во время тестирования, ответ считается ошибкой.
Уровень параллелизма — это количество одновременных клиентов (эквивалентных веб-браузерам), использованных во время теста.
Время, затраченное на тесты — это время, затрачиваемое с момента создания первого сокетного соединения до момента получения последнего ответа.
Выполнено запросов — количество полученных успешных ответов.
Failed Requests — количество запросов, которые были признаны ошибочными. Если число больше нуля, будет напечатана другая строка, показывающая количество запросов, которые не были выполнены из-за подключения, чтения, неправильной длины содержимого или исключений.
Всего перенесено — общее количество байтов, полученных с сервера. Это число по сути количество байтов, отправленных по проводам.
Переданный HTML — общее количество байтов документа, полученных с сервера. Это число исключает байты, полученные в заголовках HTTP
Количество запросов в секунду — это количество запросов в секунду. Это значение является результатом деления количества запросов на общее время.
Время на запрос — среднее время, затраченное на запрос. Первое значение рассчитывается по формуле параллелизма * timetaken * 1000 / done, а второе значение рассчитывается по формуле timetaken * 1000 / done.
Скорость передачи — скорость передачи, рассчитанная по формуле totalread / 1024 / timetaken.
Быстрый анализ результатов нагрузочного тестирования
Узнав о заголовках выходных значений из команды ab, давайте попробуем проанализировать и понять выходные значения для нашего начального теста —
Организация Apache использует свое собственное программное обеспечение веб-сервера — Apache (версия 2.4.7)
Сервер прослушивает порт 443 из-за https. Если бы это было http, это было бы 80 (по умолчанию).
Всего передано 58769 байт за 100 запросов.
Тест завершен за 1,004 секунды. Нет неудавшихся запросов.
Запросов в секунду — 99,56. Это считается довольно хорошим числом.
Время на запрос — 100,444 мс (для 10 одновременных запросов). Таким образом, для всех запросов это 100,444 мс / 10 = 10,044 мс.
Скорость передачи — 1338,39 [Кбайт / с] получено.
В статистике времени соединения вы можете заметить, что многим запросам приходилось ждать несколько секунд. Это может быть связано с тем, что веб-сервер apache помещает запросы в очередь ожидания.
Организация Apache использует свое собственное программное обеспечение веб-сервера — Apache (версия 2.4.7)
Сервер прослушивает порт 443 из-за https. Если бы это было http, это было бы 80 (по умолчанию).
Всего передано 58769 байт за 100 запросов.
Тест завершен за 1,004 секунды. Нет неудавшихся запросов.
Запросов в секунду — 99,56. Это считается довольно хорошим числом.
Время на запрос — 100,444 мс (для 10 одновременных запросов). Таким образом, для всех запросов это 100,444 мс / 10 = 10,044 мс.
Скорость передачи — 1338,39 [Кбайт / с] получено.
В статистике времени соединения вы можете заметить, что многим запросам приходилось ждать несколько секунд. Это может быть связано с тем, что веб-сервер apache помещает запросы в очередь ожидания.
В нашем первом тесте мы протестировали приложение (например, www.apache.org), размещенное на другом сервере. В следующей части руководства мы будем тестировать наши примеры веб-приложений, размещенных на том же сервере, с которого мы будем выполнять ab тесты. Это для удобства обучения и демонстрации цели. В идеале, хост-узел и узел тестирования должны отличаться для точного измерения.
Чтобы лучше изучить ab, вы должны сравнить и наблюдать, как выходные значения меняются для разных случаев, по мере того, как мы продвигаемся в этом руководстве.
Построение вывода Apache Bench
Здесь мы представим соответствующий результат, чтобы увидеть, сколько времени занимает сервер по мере увеличения количества запросов. Для этого мы добавим опцию -g в предыдущей команде, за которой следует имя файла (здесь out.data), в котором будут сохранены выходные данные ab —
$ ab -n 100 -c 10 -g out.data https://www.apache.org/
Давайте теперь посмотрим out.data, прежде чем мы создадим сюжет —
$ less out.data
Выход
starttime seconds ctime dtime ttime wait Tue May 30 12:11:37 2017 1496160697 40 38 77 13 Tue May 30 12:11:37 2017 1496160697 42 38 79 13 Tue May 30 12:11:37 2017 1496160697 41 38 80 13 ...
Давайте теперь разберемся с заголовками столбцов в файле out.data —
время начала — это дата и время начала разговора.
секунд — то же самое, что и время начала, но в формате отметки времени Unix (date -d @ 1496160697 возвращает вывод времени начала).
ctime — это время соединения.
dtime — это время обработки.
ttime — это общее время (это сумма времени ctime и dtime, математически ttime = ctime + dtime).
wait — это время ожидания.
время начала — это дата и время начала разговора.
секунд — то же самое, что и время начала, но в формате отметки времени Unix (date -d @ 1496160697 возвращает вывод времени начала).
ctime — это время соединения.
dtime — это время обработки.
ttime — это общее время (это сумма времени ctime и dtime, математически ttime = ctime + dtime).
wait — это время ожидания.
Для наглядной визуализации того, как эти несколько элементов связаны друг с другом, взгляните на следующее изображение —
Если мы работаем над терминалом или где графика недоступна, gnuplot — отличный вариант. Мы быстро поймем это, пройдя следующие шаги.
Давайте установим и запустим gnuplot —
$ sudo apt-get install gnuplot $ gnuplot
Выход
G N U P L O T Version 4.6 patchlevel 6 last modified September 2014 Build System: Linux x86_64 Copyright (C) 1986-1993, 1998, 2004, 2007-2014 Thomas Williams, Colin Kelley and many others gnuplot home: http://www.gnuplot.info faq, bugs, etc: type "help FAQ" immediate help: type "help" (plot window: hit 'h') Terminal type set to 'qt' gnuplot>
Поскольку мы работаем над терминалом и предполагаем, что графика недоступна, мы можем выбрать тупой терминал, который будет выводить в ASCII сам терминал. Это помогает нам понять, как выглядит наш сюжет с помощью этого быстрого инструмента. Давайте теперь подготовим терминал для ASCII-сюжета.
gnuplot> set terminal dumb
Выход
Terminal type set to 'dumb' Options are 'feed size 79, 24'
Так как наш терминал gnuplot теперь готов к графику ASCII, давайте построим данные из файла out.data —
gnuplot> plot "out.data" using 9 w l
Выход
1400 ++-----+------+-----+------+------+------+------+-----+------+-----++
+ + + + + + +"out.data" using 9 ****** +
| |
1200 ++ ********************************************
| ******************* |
1000 ++ * ++
| * |
| * |
800 ++ * ++
| * |
| * |
600 ++ * ++
| * |
| * |
400 ++ * ++
| * |
200 ++ * ++
| * |
+**** + + + + + + + + + +
0 ++-----+------+-----+------+------+------+------+-----+------+-----++
0 10 20 30 40 50 60 70 80 90 100
Мы изобразили ttime, общее время (в мс) из столбца 9, относительно количества запросов. Мы можем заметить, что для первых десяти запросов общее время составляло почти 100 мс, для следующих 30 запросов (с 10- го по 40- е ) оно увеличивалось до 1100 мс и так далее. Ваш сюжет должен отличаться в зависимости от ваших out.data .
В предыдущей главе мы понимали, как использовать Apache Bench для тестирования стороннего веб-сайта. В этом разделе мы будем использовать этот инструмент для тестирования веб-приложения на нашем собственном сервере. Чтобы сохранить самоучитель в максимально возможной степени, мы решили установить приложение Python для демонстрационных целей; Вы можете выбрать любой другой язык, например PHP или Ruby, в зависимости от вашего уровня знаний.
Установка Python
Обычно Python установлен по умолчанию на серверах Linux.
Установка Bottle Framework и создание простого приложения
Bottle — это микро-фреймворк, написанный на python для создания веб-приложений, а pip — менеджер пакетов python. Введите следующую команду в терминале, чтобы установить Bottle —
$ sudo apt-get install python-pip $ sudo pip install bottle
Давайте теперь создадим маленькое приложение Бутылка. Для этого создайте каталог и переместитесь в него —
$ mkdir webapp $ cd webapp
Мы создадим новый скрипт python app.py внутри каталога webapp —
$ vim app.py
Теперь напишите следующий код в файле app.py —
from bottle import Bottle, run
app = Bottle()
@app.route('/')
@app.route('/hello')
def hello():
return "Hello World!"
run(app, host = 'localhost', port = 8080)После добавления вышеуказанных строк сохраните и закройте файл. Сохранив файл, мы можем запустить скрипт python для запуска приложения —
$ python app.py
Выход
Bottle v0.12.7 server starting up (using WSGIRefServer())... Listening on http://localhost:8080/ Hit Ctrl-C to quit.
Эти выходные данные показывают, что наше приложение работает на локальной машине на хосте http: // localhost и прослушивает порт 8080 .
Давайте проверим, правильно ли наше приложение отвечает на запросы HTTP. Поскольку этот терминал не может принимать какие-либо входные данные без выхода из приложения «Бутылка», нам необходимо войти в систему нашего VPS с помощью другого терминала. После входа в VPS с помощью другого терминала вы можете перейти к своему приложению, введя следующий код в новом терминале.
$ lynx http://localhost:8080/
Lynx является браузером командной строки и обычно устанавливается по умолчанию в различных дистрибутивах Linux, таких как Debian и Ubuntu. Если вы видите следующий вывод, это означает, что ваше приложение работает нормально.
Выход
Если вы видите вывод выше, это означает, что наше приложение работает и готово к тестированию.
Тестирование приложения с помощью разработанного веб-сервера
Обратите внимание, что в ab есть ошибка, и она не может протестировать приложение на локальном хосте. Поэтому мы изменим хост с localhost на 127.0.0.1 в файле app.py. Таким образом, файл изменится на следующее —
from bottle import Bottle, run
app = Bottle()
@app.route('/')
@app.route('/hello')
def hello():
return "Hello World!"
run(app, host = '127.0.0.1', port = 8080)Давайте теперь протестируем наше приложение, набрав следующую команду на том же терминале, на котором выполнялась команда lynx:
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello
Выход
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: WSGIServer/0.1
Server Hostname: 127.0.0.1
Server Port: 8080
Document Path: /hello
Document Length: 12 bytes
Concurrency Level: 10
Time taken for tests: 0.203 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 16500 bytes
HTML transferred: 1200 bytes
Requests per second: 493.78 [#/sec] (mean)
Time per request: 20.252 [ms] (mean)
Time per request: 2.025 [ms] (mean, across all concurrent requests)
Transfer rate: 79.56 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 0
Processing: 1 6 28.2 2 202
Waiting: 1 6 28.2 2 202
Total: 1 6 28.2 2 202
Percentage of the requests served within a certain time (ms)
50% 2
66% 2
75% 2
80% 2
90% 2
95% 2
98% 202
99% 202
100% 202 (longest request)
В то время как выход на первом терминале будет (100 раз) следующим образом —
... 127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12 127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12 127.0.0.1 - - [10/Jun/2017 04:30:26] "GET /hello HTTP/1.0" 200 12 ...
Вы можете наблюдать, как различные значения исхода АБ изменились по сравнению с первоначальным тестом.
Тестирование приложения с многопоточным веб-сервером
В предыдущих тестах ab мы использовали веб-сервер по умолчанию, входящий в состав среды Bottle.
Теперь мы заменим однопоточный веб-сервер по умолчанию на многопоточный. Поэтому давайте установим многопоточную библиотеку веб-сервера, такую как cherrypy или gunicorn, и попросим Bottle использовать ее. Мы выбрали огнестрельное оружие для демонстрационных целей (вы можете выбрать и другое) —
$ sudo apt-get install gunicorn
И измените файл, то есть изменить с веб-сервера по умолчанию на gunicorn —
... run(server = 'gunicorn'...) ...
Давайте проверим приложение во втором терминале.
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello
Выход
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: gunicorn/19.0.0
Server Hostname: 127.0.0.1
Server Port: 8080
Document Path: /hello
Document Length: 12 bytes
Concurrency Level: 10
Time taken for tests: 0.031 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 17200 bytes
HTML transferred: 1200 bytes
Requests per second: 3252.77 [#/sec] (mean)
Time per request: 3.074 [ms] (mean)
Time per request: 0.307 [ms] (mean, across all concurrent requests)
Transfer rate: 546.36 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.9 0 4
Processing: 1 2 0.7 3 4
Waiting: 0 2 0.8 2 3
Total: 2 3 0.6 3 5
WARNING: The median and mean for the initial connection time are not within a normal
deviation These results are probably not that reliable.
WARNING: The median and mean for the processing time are not within a normal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 3
80% 3
90% 4
95% 5
98% 5
99% 5
100% 5 (longest request)
Посмотрите, как количество запросов в секунду увеличилось с 493 до 3252. Это означает, что gunicorn подходит в качестве рабочего сервера для приложений на Python.
В этой главе мы узнаем, как тестировать несколько URL одновременно. Для этого нам нужно отредактировать файл приложения app.py, включив в него два URL-адреса:
from bottle import Bottle, run
app = Bottle()
@app.route('/')
@app.route('/hello1')
def hello():
return "Hello World! It is first URL."
@app.route('/hello2')
def hello():
return "Hello World! It is second URL."
run(app,server = 'gunicorn',host = '127.0.0.1', port = 8080)Создание простого сценария оболочки
Вы можете сделать это, создав сценарий оболочки с несколькими вызовами ab. Создайте файл test.sh и добавьте в него следующие строки:
ab -n 100 -c 10 http://127.0.0.1:8080/hello1 ab -n 100 -c 10 http://127.0.0.1:8080/hello2
Когда вы добавите вышеуказанные строки, сохраните и закройте файл. Сделайте файл исполняемым —
chmod u+x test.sh
Давайте теперь запустим скрипт —
./test.sh
Чтобы избежать повторения и цели ясности, мы покажем только релевантный вывод ab, указав точками, какая часть была пропущена, как показано ниже.
Выход
.
.
.
Document Path: /hello1
Document Length: 732 bytes
Concurrency Level: 10
Time taken for tests: 0.040 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Total transferred: 90000 bytes
HTML transferred: 73200 bytes
Requests per second: 2496.13 [#/sec] (mean)
Time per request: 4.006 [ms] (mean)
Time per request: 0.401 [ms] (mean, across all concurrent requests)
Transfer rate: 2193.87 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.8 0 3
Processing: 1 3 1.0 4 5
Waiting: 0 3 1.2 4 4
Total: 1 4 0.6 4 5
WARNING: The median and mean for the processing time are not within a normal deviation
These results are probably not that reliable.
.
.
.
Сценарий оболочки для сохранения выходных данных Apache Bench в файл
Вы можете сохранить выходные данные Apache Bench в файл, создав сценарий оболочки с несколькими ab-вызовами. В конце каждой строки поместите &; это заставляет команду выполняться в фоновом режиме и позволяет следующей команде начать ее выполнение. Вы также захотите перенаправить вывод в файл для каждого URL, используя <имя файла>. Например, наш файл test.sh после модификации будет выглядеть следующим образом:
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello1 > test1.txt & $ ab -n 100 -c 10 http://127.0.0.1:8080/hello2 > test2.txt &
Здесь test1.txt и test2.txt — это файлы для сохранения выходных данных.
Вы можете проверить, что вышеприведенный скрипт создал два файла, test1.txt и test2.txt, которые содержат выходные данные ab для соответствующих URL —
$ ls -l
Выход
... -rw-r--r-- 1 root root 5225 May 30 12:11 out.data -rwxr--r-- 1 root root 118 Jun 10 12:24 test.sh -rw-r--r-- 1 root root 1291 Jun 10 12:31 test1.txt -rwxr--r-- 1 root root 91 Jun 10 13:22 test2.sh -rw-r--r-- 1 root root 1291 Jun 10 12:31 test2.txt ...
Бдительная ситуация
При использовании ab вы должны быть предупреждены о неудачном тесте без предупреждения. Например, если вы проверите неправильный URL, вы можете получить что-то похожее на следующее (мы намеренно изменили порт здесь).
$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:805/
Выход
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software:
Server Hostname: 127.0.0.1
Server Port: 805
Document Path: /
Document Length: Variable
Concurrency Level: 10
Time taken for tests: 0.002 seconds
Complete requests: 100
Failed requests: 150
(Connect: 0, Receive: 100, Length: 0, Exceptions: 50)
Keep-Alive requests: 0
Total transferred: 0 bytes
HTML transferred: 0 bytes
Requests per second: 44984.26 [#/sec] (mean)
Time per request: 0.222 [ms] (mean)
Time per request: 0.022 [ms] (mean, across all concurrent requests)
Transfer rate: 0.00 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 0 0 0.2 0 0
Waiting: 0 0 0.0 0 0
Total: 0 0 0.2 0 0
Percentage of the requests served within a certain time (ms)
50% 0
66% 0
75% 0
80% 0
90% 0
95% 0
98% 0
99% 0
100% 0 (longest request)
В этой главе мы поймем подготовку, необходимую для тестирования динамических страниц. Динамическая веб-страница на стороне сервера — это веб-страница, построение которой контролируется сервером приложений, обрабатывающим сценарии на стороне сервера. Стенд apache может выполнять только нагрузочное тестирование динамической веб-страницы на стороне сервера.
Уровень параллелизма и общее количество запросов
Уровень параллелизма должен быть ниже общего количества запросов.
$ ab -l -r -n 30 -c 80 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/
Выход
ab: Cannot use concurrency level greater than total number of requests Usage: ab [options] [http[s]://]hostname[:port]/path
Использование флагов
В этом разделе мы опишем использование некоторых важных флагов с командой ab. Мы будем использовать термины, опции и флаги, взаимозаменяемо.
Verbose -v
Параметр verbose можно использовать для анализа и отладки, если существует несколько неудачных запросов. Распространенным признаком сбоя теста нагрузки является то, что тест завершается очень быстро и дает хорошее число для запроса в секунду. Но это будет неверный ориентир. Чтобы определить успех или неудачу, вы можете использовать опцию -v 2, которая будет выводить тело и заголовок каждого ответа на вывод терминала. Следующая команда описывает вариант использования —
$ ab -n 1 -v 2 http://www.generic-example-URL.com/
Выход
LOG: header received: HTTP/1.0 200 OK … Content-Length: 2548687
Конечно, если вы тестируете переменные ответы или возвращаете не-200 HTTP-коды в случае какой-либо ошибки, вы должны просто игнорировать проверку длины с опцией -l . Скоро мы увидим не 200 HTTP, когда запустим приложение web2py в следующих главах.
Keep-alive -k
Когда клиент отправляет HTTP-запрос, соединение устанавливается с сервером, сервер отправляет ответ, и соединение закрывается после того, как он отправил запрос. Этот цикл продолжается с каждым запросом. Однако с помощью параметра keep-alive (также известного как постоянные соединения) клиент поддерживает базовое TCP-соединение открытым, чтобы упростить множественные запросы и ответы; это устраняет медленное и дорогостоящее время инициализации соединения, которое в противном случае имело бы место.
Переменная длина документа -l
Если веб-страница имеет переменную длину, вам следует использовать опцию -l . Apache Bench не сообщает об ошибках, если длина ответов не постоянна. Это может быть полезно для динамических страниц.
Использование опции -r
Как заставить ab не выходить при получении ошибок? Вы должны использовать опцию -r . Без этой опции ваш тест может прерваться, как только любой запрос достигнет ошибки сокета. Однако с помощью этой опции об ошибках будут сообщаться в заголовке ошибочных ошибок, но тест будет продолжаться до конца.
Использование опции -H
Эта опция используется для добавления произвольной строки заголовка. Аргумент обычно имеет форму правильной строки заголовка, содержащей разделенную двоеточиями пару поле-значение (т. Е. «Accept-Encoding: zip / zop; 8bit»).
Использование опции -C
В следующем разделе мы подробно узнаем, как использовать вышеуказанные опции в сочетании с опцией использования значения cookie, то есть опцией -C . Опция -C обычно имеет форму пары имя = значение . Это поле может быть повторено.
Использование Session Cookie с Apache Bench
Чтобы понять, как использовать куки с Apache Bench, нам нужна веб-страница, которая пытается установить куки. Очень хорошим примером является приложение web2py, которое представляет собой веб-фреймворк Python.
Установка web2py
Мы собираемся быстро установить еще одно приложение python web2py. Вы можете прочитать больше о том, как его использовать, в Web2py Framework Overview .
Python обычно устанавливается по умолчанию на серверы Ubuntu и Debian. Таким образом, одно требование уже выполнено для успешного запуска web2py.
Однако нам нужно установить пакет unzip для извлечения исходных файлов web2py из zip-файла, который мы будем загружать —
$ sudo apt-get update $ sudo apt-get install unzip
Давайте получим фреймворк web2py с веб-сайта проекта. Мы загрузим это в нашу домашнюю папку —
$cd ~ $ wget http://www.web2py.com/examples/static/web2py_src.zip
Теперь мы можем распаковать файл, который мы только что скачали, и переместить внутрь
$ unzip web2py_src.zip $ cd web2py
Чтобы запустить web2py, вам не нужно его устанавливать. Когда вы окажетесь в каталоге web2py, вы можете запустить его, введя следующую команду —
$python web2py.py
Если все прошло успешно, вы увидите следующий вывод, где вас попросят выбрать пароль для административного интерфейса —
web2py Web Framework
Created by Massimo Di Pierro, Copyright 2007-2017
Version 2.14.6-stable+timestamp.2016.05.10.00.21.47
Database drivers available: sqlite3, imaplib, pymysql, pg8000
WARNING:web2py:GUI not available because Tk library is not installed
choose a password:
please visit:
http://127.0.0.1:8000/
use "kill -SIGTERM 23904" to shutdown the web2py server
Однако вы должны знать, что запущенный веб-интерфейс доступен только на локальном компьютере.
Исходя из вывода, вы можете понять, что для остановки веб-сервера вам придется набрать «CTRL-C» в мгновенном терминале. С другой стороны, чтобы остановить сервер web2py на другом терминале, связанном с тем же VPS, вы можете вставить команду kill -SIGTERM <PID>, где <PID> — это идентификатор процесса для сервера web2py, который в данном случае 23904.
Сессионный Cookie от web2py
Если страница доступна только зарегистрированному пользователю, но не доступна напрямую со страницы входа, в этом случае вы можете использовать флаг -C . Этот флаг определяет cookie для команды ab. Но вы должны получить значение cookie идентификатора сеанса из действительного сеанса. Как это получить? Различные онлайн-учебники помогут вам освоить инструменты для разработчиков браузеров Chrome (или Mozilla). Но в нашем тестовом примере, поскольку приложение доступно только из командной строки, мы будем использовать браузер lynx для получения значения.
Давайте сначала получим значение cookie сеанса. Откройте другой терминал и введите следующую команду —
$ lynx http://127.0.0.1:8000/
В ответ на приведенную выше команду lynx запросит у вас разрешение на прием файлов cookie с сервера web2py, как показано на рисунке ниже.
Запишите значение cookie, прежде чем вводить y, чтобы принять cookie. Теперь терминал будет выглядеть следующим образом — сайт на терминале!
Получив значение cookie, мы запустим тест ab. Для этого нам нужно будет открыть третий терминал (см. Изображение ниже) —
Теперь давайте используем флаг -C в третьем терминале —
$ ab -n 100 -c 10 -C session_name = 127.0.0.1-643dad04-3c34 http://127.0.0.1:8000/
Выход
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: 66 bytes
Concurrency Level: 10
Time taken for tests: 0.051 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Total transferred: 27700 bytes
HTML transferred: 6600 bytes
Requests per second: 1968.12 [#/sec] (mean)
Time per request: 5.081 [ms] (mean)
Time per request: 0.508 [ms] (mean, across all concurrent requests)
Transfer rate: 532.39 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.9 2 4
Processing: 0 3 0.9 3 5
Waiting: 0 2 1.1 2 4
Total: 4 5 0.7 5 7
Percentage of the requests served within a certain time (ms)
50% 5
66% 5
75% 5
80% 6
90% 6
95% 6
98% 7
99% 7
100% 7 (longest request)
Из приведенного выше вывода отметим несколько моментов. Во-первых, web2py использует веб-сервер Rocket . Мы также отмечаем, что мы получаем «Не-2xx ответы» в дополнение к ранее обсужденным заголовкам в выходных данных. В общем, протокол Http отвечает на запрос, используя код ответа, и все, что находится в диапазоне 200 с, означает «хорошо», а остальное соответствует некоторой проблеме. Например, 400 — это ошибки, связанные с ресурсами, например, 404 Файл не найден. 500 соответствуют ошибкам сервера. В нашем случае нет ошибок нигде, кроме случаев, когда мы используем опцию -C. Это может быть подавлено с помощью опции -l, как уже описано.
Проверка страницы администратора
В этом разделе мы поймем, как проверить страницу администратора. Для сравнения давайте проверим другой URL-адрес приложения web2py —
$ ab -n 100 -c 10 session_name = 127.0.0.1-643dad04-3c34 http://127.0.0.1:8000/admin
Выход
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /admin
Document Length: 8840 bytes
Concurrency Level: 10
Time taken for tests: 2.077 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 926700 bytes
HTML transferred: 884000 bytes
Requests per second: 48.14 [#/sec] (mean)
Time per request: 207.749 [ms] (mean)
Time per request: 20.775 [ms] (mean, across all concurrent requests)
Transfer rate: 435.61 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.2 0 12
Processing: 62 204 52.2 199 400
Waiting: 61 203 52.0 199 400
Total: 62 205 54.3 199 411
Percentage of the requests served within a certain time (ms)
50% 199
66% 211
75% 220
80% 226
90% 264
95% 349
98% 381
99% 411
100% 411 (longest request)
В частности, вам следует обратить внимание на соответствующие статистические данные в разделах «Время соединения» и «Процент обслуживаемых запросов» http://127.0.0.1:8000/ и http://127.0.0.1:8000/admin . Это огромная разница.
Использование опции Timelimit
Как правило, опция Timelimit довольно сложна. Давайте поймем это из руководства ab , которое довольно объяснительно —
-t timelimit Maximum number of seconds to spend for benchmarking. This implies a -n 50000 internally. Use this to benchmark the server within a fixed total amount of time. Per default there is no timelimit.
Давайте запустим тест с этой опцией. Мы отметим наши наблюдения после прохождения вывода —
$ ab -n 100 -c 10 -t 60 http://127.0.0.1:8000/
Выход
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: 66 bytes
Concurrency Level: 10
Time taken for tests: 22.547 seconds
Complete requests: 50000
Failed requests: 0
Non-2xx responses: 50000
Total transferred: 13850000 bytes
HTML transferred: 3300000 bytes
Requests per second: 2217.61 [#/sec] (mean)
Time per request: 4.509 [ms] (mean)
Time per request: 0.451 [ms] (mean, across all concurrent requests)
Transfer rate: 599.88 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 0.8 2 8
Processing: 0 2 3.2 2 218
Waiting: 0 2 3.2 2 218
Total: 2 4 3.1 4 220
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 5
90% 5
95% 5
98% 7
99% 8
100% 220 (longest request)
Обратите внимание, что выходные данные показывают, что эта опция переопределяет количество запросов, указанных параметром -n, и продолжается до 50 000 запросов. Однако, поскольку запросы обрабатывались очень быстро, ab прекращал работу, как только была достигнута отметка в 50 тыс. — в течение 22 секунд (см. Заголовок «Время, затраченное на испытания») в данном случае.
Вы можете протестировать ту же команду, заменив http://127.0.0.1:8000/ на http://127.0.0.1:8000/admin (при условии, что это наше приложение web2py) или сторонний веб-сайт, такой как https: //www.apache .org /, обратите внимание на разницу в статистике.
Контрольный список перед выполнением нагрузочного теста
Есть несколько проверок, которые помогут вам успешно выполнить тест и точно измерить производительность. Перед выполнением нагрузочного теста рассмотрите следующие условия:
Убедитесь, что дополнительный модуль Python не загружен.
Чтобы избежать исчерпания порта TCP / IP, обычно следует подождать 2-3 минуты, прежде чем перейти к другому тесту ab.
Убедитесь, что число одновременных подключений меньше, чем у рабочих потоков Apache.
Вы должны перезагрузить сервер перед выполнением другого теста в случае сбоя Apache или python.
Убедитесь, что дополнительный модуль Python не загружен.
Чтобы избежать исчерпания порта TCP / IP, обычно следует подождать 2-3 минуты, прежде чем перейти к другому тесту ab.
Убедитесь, что число одновременных подключений меньше, чем у рабочих потоков Apache.
Вы должны перезагрузить сервер перед выполнением другого теста в случае сбоя Apache или python.
В этой главе мы опишем различные комбинации -n и -c с важными флагами, чтобы постепенно увеличить нагрузку на ваш веб-сервер.
В основном вы должны сосредоточиться на том, как меняются следующие показатели при увеличении нагрузки:
- Запросов в секунду
- Время соединения (мс)
- Процент запросов, обработанных в течение определенного времени (мс)
Следует также обратить внимание на пороговое значение, когда сервер начинает зависать, и вы начинаете получать неудавшиеся запросы.
1 одновременный пользователь делает 100 страничных хитов
Давайте сделаем 100 последовательных загрузок страниц одним пользователем —
$ ab -l -r -n 100 -c 1 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/
Выход
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: Variable
Concurrency Level: 1
Time taken for tests: 0.045 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Keep-Alive requests: 0
Total transferred: 27700 bytes
HTML transferred: 6600 bytes
Requests per second: 2206.24 [#/sec] (mean)
Time per request: 0.453 [ms] (mean)
Time per request: 0.453 [ms] (mean, across all concurrent requests)
Transfer rate: 596.80 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.0 0 0
Processing: 0 0 0.0 0 0
Waiting: 0 0 0.0 0 0
Total: 0 0 0.0 0 1
Percentage of the requests served within a certain time (ms)
50% 0
66% 0
75% 0
80% 0
90% 1
95% 1
98% 1
99% 1
100% 1 (longest request)
5 одновременных пользователей, каждый из которых делает 10 хитов
Этот случай соответствует пиковой нагрузке на сайт, которая получает около 50 000+ посещений в месяц.
$ ab -l -r -n 10 -c 5 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/
В следующих последующих выходных данных мы будем опускать общий заголовок для ясности.
Выход
...
Requests per second: 2009.24 [#/sec] (mean)
Time per request: 2.488 [ms] (mean)
Time per request: 0.498 [ms] (mean, across all concurrent requests)
Transfer rate: 543.52 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.5 1 2
Processing: 0 1 0.5 1 2
Waiting: 0 1 0.5 1 1
Total: 2 2 0.4 3 3
ERROR: The median and mean for the total time are more than twice the standard
deviation apart. These results are NOT reliable.
Percentage of the requests served within a certain time (ms)
50% 3
66% 3
75% 3
80% 3
90% 3
95% 3
98% 3
99% 3
100% 3 (longest request)
10 одновременных пользователей, каждый из которых выполняет 10 страниц
Этот тест соответствует 100 загрузкам страниц 10 различными одновременными пользователями, каждый пользователь выполняет 10 последовательных загрузок страниц.
$ ab -r -n 10 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/
Выход
...
Requests per second: 2225.68 [#/sec] (mean)
Time per request: 4.493 [ms] (mean)
Time per request: 0.449 [ms] (mean, across all concurrent requests)
Transfer rate: 602.07 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 3
Processing: 0 2 1.0 2 3
Waiting: 0 1 1.0 2 3
Total: 4 4 0.3 4 4
WARNING: The median and mean for the waiting time are not within a normal deviation
These results are probably not that reliable.
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 4
90% 4
95% 4
98% 4
99% 4
100% 4 (longest request)
20 одновременных пользователей, каждый из которых выполняет 20 просмотров страниц
Этот тест соответствует 400 загрузкам страниц 20 различными одновременными пользователями, каждый пользователь выполняет 20 последовательных загрузок страниц.
$ ab -r -n 20 -c 20 -k -H “Accept-Encoding: gzip, deflate” http://127.0.0.1:8000/
Выход
...
Requests per second: 1619.96 [#/sec] (mean)
Time per request: 12.346 [ms] (mean)
Time per request: 0.617 [ms] (mean, across all concurrent requests)
Transfer rate: 438.21 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 6 2.3 6 10
Processing: 1 5 2.9 5 10
Waiting: 0 5 2.9 5 9
Total: 10 11 0.6 11 12
Percentage of the requests served within a certain time (ms)
50% 11
66% 11
75% 12
80% 12
90% 12
95% 12
98% 12
99% 12
100% 12 (longest request)
30 одновременных пользователей, каждый из которых выполняет 30 просмотров страниц
Этот тест соответствует 900 загрузкам страниц 30 различными одновременными пользователями, каждый пользователь выполняет 30 последовательных загрузок страниц.
$ ab -r -n 30 -c 30 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/
Выход
...
Requests per second: 2283.45 [#/sec] (mean)
Time per request: 13.138 [ms] (mean)
Time per request: 0.438 [ms] (mean, across all concurrent requests)
Transfer rate: 617.69 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 6 2.7 6 11
Processing: 1 6 3.1 6 11
Waiting: 0 5 3.2 5 10
Total: 11 12 0.5 12 13
Percentage of the requests served within a certain time (ms)
50% 12
66% 12
75% 12
80% 12
90% 13
95% 13
98% 13
99% 13
100% 13 (longest request)
Теперь мы научились постепенно увеличивать нагрузку на сайт и тестировать его работоспособность.
В этой главе мы сравним результаты с флагами и без них. Давайте посмотрим, как использование соответствующих флагов может повысить производительность вашего веб-приложения. Перед этим нам нужно понять, как, если ваше приложение простое, вы можете не заметить разницу. Как и в случае с нашим простым приложением, с флагами и без флагов. Затем мы выполним тот же тест с https://www.apache.org/ URL и увидим разницу.
Тестирование нашего приложения без флагов
В этом разделе мы поймем, как тестировать наше приложение без флагов.
$ ab -n 100 -c 10 http://127.0.0.1:8000/
Выход
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient).....done
Server Software: Rocket
Server Hostname: 127.0.0.1
Server Port: 8000
Document Path: /
Document Length: Variable
Concurrency Level: 10
Time taken for tests: 0.244 seconds
Complete requests: 100
Failed requests: 0
Non-2xx responses: 100
Keep-Alive requests: 0
Total transferred: 27700 bytes
HTML transferred: 6600 bytes
Requests per second: 2208.77 [#/sec] (mean)
Time per request: 4.527 [ms] (mean)
Time per request: 0.453 [ms] (mean, across all concurrent requests)
Transfer rate: 597.49 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 3
Processing: 0 2 0.7 2 4
Waiting: 0 2 1.0 2 3
Total: 4 4 0.3 4 5
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 5
80% 5
90% 5
95% 5
98% 5
99% 5
100% 5 (longest request)
Тестирование нашего приложения с флагами
В этом разделе мы поймем, как протестировать наше приложение с флагами.
$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://127.0.0.1:8000/
Выход
...
Requests per second: 2277.07 [#/sec] (mean)
Time per request: 4.392 [ms] (mean)
Time per request: 0.439 [ms] (mean, across all concurrent requests)
Transfer rate: 615.97 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.7 2 3
Processing: 0 2 0.7 2 4
Waiting: 0 2 1.0 2 3
Total: 4 4 0.2 4 5
Percentage of the requests served within a certain time (ms)
50% 4
66% 4
75% 4
80% 4
90% 5
95% 5
98% 5
99% 5
100% 5 (longest request)
Мы можем просто заметить, что между выходной статистикой нет большой разницы.
Тестирование сайта организации Apache без флагов
Давайте теперь посмотрим, как протестировать веб-сайт Apache Organization без флагов.
$ ab -n 100 -c 10 http://www.apache.org/
Выход
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.apache.org (be patient).....done
Server Software: Apache/2.4.7
Server Hostname: www.apache.org
Server Port: 80
Document Path: /
Document Length: 58433 bytes
Concurrency Level: 10
Time taken for tests: 1.498 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 5877500 bytes
HTML transferred: 5843300 bytes
Requests per second: 66.74 [#/sec] (mean)
Time per request: 149.840 [ms] (mean)
Time per request: 14.984 [ms] (mean, across all concurrent requests)
Transfer rate: 3830.58 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 12 110 295.2 12 1012
Processing: 37 38 0.5 38 39
Waiting: 12 13 0.3 13 15
Total: 49 147 295.4 50 1051
Percentage of the requests served within a certain time (ms)
50% 50
66% 50
75% 50
80% 50
90% 816
95% 1050
98% 1051
99% 1051
100% 1051 (longest request)
Тестирование сайта организации Apache с флагами
Теперь давайте проверим веб-сайт организации Apache с флагами.
$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate" http://www.apache.org/
Выход
...
Document Length: Variable
Concurrency Level: 10
Time taken for tests: 0.357 seconds
Complete requests: 100
Failed requests: 0
Keep-Alive requests: 100
Total transferred: 1358510 bytes
HTML transferred: 1317700 bytes
Requests per second: 280.28 [#/sec] (mean)
Time per request: 35.678 [ms] (mean)
Time per request: 3.568 [ms] (mean, across all concurrent requests)
Transfer rate: 3718.41 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.7 0 12
Processing: 14 17 21.3 15 227
Waiting: 14 17 21.3 14 227
Total: 14 18 21.5 15 227
Percentage of the requests served within a certain time (ms)
50% 15
66% 15
75% 15
80% 15
90% 27
95% 28
98% 29
99% 227
100% 227 (longest request)
Вы можете просто заметить, как увеличивается количество запросов в секунду с использованием флагов. В данном случае это, в частности, связано с использованием -H «Accept-Encoding: gzip , deflate, поскольку этот флаг указывает серверу Apache обслуживать запросы в формате gzipped .
Учитывая результаты Apache Bench
Несколько важных моментов необходимо учитывать, когда дело доходит до результатов Apache Bench. Это поможет нам разработать общую стратегию по устранению узких мест в нашем приложении и повышению его производительности.
Нам нужно запросов в секунду. Это дает нам представление о том, насколько хорошо работает настройка нашего веб-сервера; чем больше число, тем выше производительность. Затем следует время соединения (мс) и процент обработанных запросов. Возможно, вам придется изменить настройки вашего веб-сервера, чтобы изменить эти показатели на желаемую производительность.
Проверьте, есть ли ошибки в журналах ошибок Apache или используемого веб-сервера или (общих) журналах. Когда вы увеличите нагрузку, все начнет задыхаться: проблемы с памятью начнут возникать. Многие скрипты Python начнут падать, если они не написаны с учетом параллелизма.
Вам необходимо выяснить, какое критическое значение параллелизма выше, чем ваш веб-сервер дает сбой и / или время ожидания? Обычно это должно происходить на довольно высоком уровне параллелизма. Если это значение низкое, что-то не так, и вам нужно отрегулировать эти настройки ниже / выше.
Заключение
В этом уроке мы узнали, как Apache Bench можно использовать для нагрузочного тестирования любого веб-сайта или веб-приложения. Apache Bench может быть очень ценным инструментом для определения того, как следует улучшить настройку сервера веб-приложений, уменьшить узкие места и повысить производительность. Теперь, когда вы знакомы с базовым использованием Apache Bench, вы можете начать с создания новых планов тестирования для измерения производительности ваших приложений в различных сценариях.
php — неожиданное завершение работы Apache
Я использую XAMPPS для размещения файлов PHP со своего компьютера. Я недавно установил XAMPP, но я не могу запустить службу Apache, поскольку порт 80 используется PID 4 — NT Kernel & System.
Я знаю, что при использовании другого порта (например, при изменении порта 8080 и т. Д. В httpd.conf) можно будет решить эту проблему. Однако мне нужно, чтобы порт 80 был освобожден процессом PID 4 и выделен службе Apache. Я делал это в прошлом, но со временем забыл о шагах решения.Пожалуйста, помогите мне исправить
Это ошибка, с которой я сталкиваюсь при запуске Apache
. `11:19:52 AM [Apache] Ошибка: неожиданное завершение работы Apache .`
`11:19:52 AM [Apache] Это может быть из-за заблокированного порта, отсутствия зависимостей,`
`11:19:52 AM [Apache] неправильные привилегии, сбой или завершение работы другим способом .`
`11:19:52 AM [Apache] Нажмите кнопку журналов, чтобы просмотреть журналы ошибок и проверить`
`11:19:52 AM [Apache] средство просмотра событий Windows для получения дополнительных подсказок`
`11:19:52 AM [Apache] Если вам нужна дополнительная помощь, скопируйте и опубликуйте это`
`11:19:52 AM [Apache] все окно журнала на форумах`
Журналы из файла журнала ошибок apache:
[ср, 03 июля, 00:54:17.004882 2013] [mpm_winnt: notice] [pid 248: tid 240] AH00354: Потомок: запуск 150 рабочих потоков.
[Ср, 03 июля, 01:17: 37.485351 2013] [mpm_winnt: notice] [pid 4200: tid 228] AH00428: Родитель: дочерний процесс 248 завершился со статусом 1073807364 - перезапуск.
[Ср, 03 июля, 08:51: 45.875976 2013] [ssl: warn] [pid 400: tid 228] AH01909: сертификат RSA, настроенный для www.example.com:443, НЕ включает идентификатор, который соответствует имени сервера
[Ср, 03 июля, 08:51: 46.188476 2013] [core: warn] [pid 400: tid 228] AH00098: файл pid C: / xampp / apache / logs / httpd.pid overwritten - Нечистое завершение предыдущего запуска Apache?
[Ср, 03 июля, 08:51: 46.844726 2013] [ssl: warn] [pid 400: tid 228] AH01909: сертификат RSA, настроенный для www.example.com:443, НЕ включает идентификатор, соответствующий имени сервера
[Ср, 03 июля, 08:51: 49.047851 2013] [mpm_winnt: notice] [pid 400: tid 228] AH00455: Apache / 2.4.4 (Win32) OpenSSL / 0.9.8y PHP / 5.4.16 настроен - возобновление нормальной работы
[Ср, 3 июля, 08:51: 49.047851 2013] [mpm_winnt: notice] [pid 400: tid 228] AH00456: Сервер построен: 23 февраля 2013 г., 13:07:34
[Ср, 3 июля, 08:51:49.047851 2013] [core: notice] [pid 400: tid 228] AH00094: Командная строка: 'c: \\ xampp \\ apache \\ bin \\ httpd.exe -d C: / xampp / apache
[Ср, 3 июля, 08:51: 49.063476 2013] [mpm_winnt: notice] [pid 400: tid 228] AH00418: Родитель: Создан дочерний процесс 5384
[Ср, 03 июля, 08:51: 50.579101 2013] [ssl: warn] [pid 5384: tid 240] AH01909: сертификат RSA, настроенный для www.example.com:443, НЕ включает идентификатор, соответствующий имени сервера
[Ср, 03 июля, 08:51: 51.579101 2013] [ssl: warn] [pid 5384: tid 240] AH01909: сертификат RSA настроен для www.example.com:443 НЕ включает идентификатор, который соответствует имени сервера
[Ср, 03 июля, 08:51: 51.750976 2013] [mpm_winnt: notice] [pid 5384: tid 240] AH00354: Потомок: запуск 150 рабочих потоков.
ПРИМЕЧАНИЕ: У МЕНЯ НЕТ IIS, ВЕБ-КЛИЕНТА, ВСЕМИРНОГО ВЕБ-СЕРВИСА.
php — Apache: запрошенный URL / не найден на этом сервере. Apache
Я установил сервер Apache 2.2 и PHP 5.3 на Windows XP SP3. После первоначальной установки Apache загрузил тестовую страницу, т.е.е.,
http: / localhost (C: / Program Files / Apache2.2 / htdocs / index.html) показал «Это работает!».
После настройки Apache и установки PHP, попытка загрузить http: /localhost/phptest.php , т.е. (C: /testsite/htdocs/phptest.php).
Но это выдает ошибку:
Не найдено. Запрошенный URL /phptest.php не найден на этом сервере.
Я также получаю ту же ошибку при загрузке
http: // localhost
httpd.conf правки:
Имя сервера localhost: 80
DocumentRoot "C: / testsite / htdocs"
<Каталог "C: / testsite / htdocs">
Параметры FollowSymLinks
AllowOverride Нет
Заказать отказать, разрешить
Запретить всем
DirectoryIndex index.html index.php
LoadModule php5_module "c: /testsite/php/php5apache2_2.dll"
Приложение AddType / x-httpd-php .php
Приложение AddHandler / x-httpd-php .php
PHPIniDir "C: / testsite / php"
Файл php.ini правок:
include_path = ".; C: \ testsite \ php \ includes"
extension_dir = "C: / testsite / php / ext /"
Системный путь:
Каталог PHP был добавлен в путь к Windows, например
ПУТЬ = C: \ Windows \ System32; C: \ many_dir; C: \ testsite \ php
Единственные ошибки в журнале ошибок Apache:
Предупреждение: DocumentRoot [C: / Program Files / Apache Software Foundation / Apache2.2 /docs/dummy-host.localhost] не существует
Предупреждение: DocumentRoot [C: / Program Files / Apache Software Foundation / Apache2.2 / docs / dummy-host2.localhost] не существует
Предупреждение: DocumentRoot [C: / Program Files / Apache Software Foundation / Apache2.2 / docs / dummy-host.localhost] не существует
Предупреждение: DocumentRoot [C: / Program Files / Apache Software Foundation / Apache2.2 / docs / dummy-host2.localhost] не существует
Служба Apache успешно перезапускается и работает. Я не могу найти ничего неправильного. Кто-нибудь может обнаружить какие-нибудь глупые ошибки?
Как исправить ошибку XAMPP «Неожиданное завершение работы Apache»
XAMPP — полезный инструмент разработки.Однако в какой-то момент вы можете столкнуться с проблемами, например с получением уведомления: «Неожиданное завершение работы Apache». Может показаться, что эта ошибка возникла из ниоткуда, поэтому определение причины — не говоря уже о решении — может вызывать затруднения.
К счастью, внезапному отключению Apache есть обычное объяснение. С помощью нескольких простых изменений вы сможете решить проблему и снова запустить Apache. Все, что вам нужно сделать, это обновить некоторые настройки в файлах конфигурации.
В этой статье мы обсудим частую причину этой ошибки Apache в XAMPP, а затем проведем вас через четыре шага по ее исправлению как в Windows, так и в macOS.
Приступим!
Введение в ошибку XAMPP «Неожиданное завершение работы Apache»
XAMPP — это бесплатный серверный стек с открытым исходным кодом, который включает сервер Apache и базу данных MariaDB:
Сайт XAMPP.
Он запускает сценарии PHP и Perl и используется для разработки и тестирования динамических веб-сайтов на локальных машинах. Это означает, что если вы создаете веб-сайт, вы можете установить WordPress локально на свой компьютер. Вы можете использовать XAMPP без необходимости загружать файлы своего сайта в службу веб-хостинга.
Если вы читаете эту статью, мы предполагаем, что вы уже хоть немного знакомы с XAMPP. Однако вы можете столкнуться с новой ошибкой «Неожиданное завершение работы Apache».
Это сообщение чаще всего вызвано заблокированным портом. Обычно это означает, что другое приложение, установленное на вашем компьютере, например Skype, использует тот же порт, что и XAMPP. Кроме того, вы можете заметить, что сообщение об ошибке указывает на то, что проблема также может быть связана с «отсутствием зависимостей, неправильными привилегиями, сбоем или завершением работы другим методом.”
В любом случае, самое простое решение — просто изменить настройки XAMPP по умолчанию. Однако метод устранения ошибки незначительно отличается в Windows и macOS. Кроме того, интерфейс может немного отличаться в зависимости от версии XAMPP, которую вы используете. Ниже мы предоставим инструкции для обеих операционных систем, начиная с Windows.
Ищете бесплатный и мощный локальный инструмент разработки WordPress? DevKinsta предлагает быстрое и простое создание сайтов, инструменты управления электронной почтой и базами данных, переключение версий PHP одним щелчком мыши и полную интеграцию с MyKinsta.Начните работу с DevKinsta сегодня, даже если вы не являетесь клиентом Kinsta.
Как исправить ошибку XAMPP «Неожиданное завершение работы Apache» в Windows
Если вы используете устройство Windows, вы можете выполнить эти четыре шага, чтобы обновить настройки порта по умолчанию в XAMPP.
Шаг 1. Откройте настройки конфигурации из панели управления XAMPP
Первым шагом, конечно же, является запуск XAMPP. Это откроет панель управления XAMPP. Отсюда вы можете обновить параметры конфигурации для стека серверов.
Поскольку эта ошибка связана с Apache, мы сосредоточимся на этих настройках. В строке параметров «Apache» нажмите кнопку « Config ».
Панель управления XAMPP в Windows.
Откроется раскрывающееся меню файлов. Мы собираемся редактировать два из этих файлов, начиная с httpd.conf .
Шаг 2. Измените настройки порта по умолчанию для файла
httpd.confВ меню файлов щелкните Apache (httpd.конф) . После этого файл откроется в текстовом редакторе по умолчанию на вашем компьютере:
.Файл Apache (httpd.conf) в панели управления XAMPP.
В этом файле есть три настройки, которые нужно обновить. Для начала нажмите Ctrl + F , затем введите «80» в поле поиска:
Файл Apache httpd.conf в Windows.
Это отобразит все экземпляры числа 80 в файле. Найдите «Порт 80» и измените его на «Порт 8080».После обновления настройки порта найдите «Listen 80» и обновите его до «Listen 8080».
Наконец, найдите «имя сервера localhost: 80». Как только вы найдете его, измените его на «servername localhost: 8080». Когда вы закончите, сохраните и закройте файл.
Шаг 3. Обновите настройки порта по умолчанию в файле
http-ssl.confТеперь пора перейти ко второму файлу. Для этого вы можете вернуться в панель управления XAMPP, затем снова выбрать Config в настройках Apache.На этот раз откройте файл Apache (http-ssl.conf) .
Когда файл откроется в текстовом редакторе, нажмите Ctrl + F , а затем введите 443 в поле поиска. Найдите «Слушать 443» и обновите его до «Слушать 4433».
Затем найдите в файле следующий экземпляр «443». Это должно быть «
Подпишитесь на информационный бюллетень
Хотите узнать, как мы увеличили трафик более чем на 1000%?
Присоединяйтесь к 20 000+ других, которые получают нашу еженедельную рассылку с инсайдерскими советами по WordPress!
Подпишитесь сейчасШаг 4. Перезапустите Apache
.Последний шаг после обновления настроек в обоих файлах — остановка Apache. Вы можете сделать это, нажав кнопку Stop в той же строке Apache .После остановки Apache нажмите кнопку Start , чтобы завершить процесс перезапуска.
Возможность остановки Apache в XAMPP.
Вот и все! Ваши номера портов будут обновлены, и теперь Apache должен работать без ошибок.
Как исправить ошибку XAMPP «Неожиданное завершение работы Apache» в macOS
В зависимости от того, какая версия macOS у вас установлена, на вашем компьютере уже может быть установлен Apache. Это приложение Apache по умолчанию будет использовать те же настройки порта по умолчанию, что и сервер Apache в XAMPP, поэтому это может быть причиной ошибки «Неожиданное завершение работы Apache».
Если вы используете macOS, вы можете выполнить эти четыре шага, чтобы обновить настройки порта по умолчанию.
Шаг 1. Откройте конфигурацию XAMPP Apache
Для начала откройте диспетчер приложений XAMPP, если вы еще этого не сделали:
Диспетчер приложений XAMPP.
Затем выберите вкладку Manage Servers рядом с вкладкой Welcome вверху:
Настройки «Управление серверами» XAMPP.
На этом экране вы найдете список опций.Вы можете щелкнуть веб-сервер Apache , а затем кнопку Настроить .
Шаг 2. Откройте файл конфигурации
В поле Настроить веб-сервер Apache выберите Открыть файл конфигурации :
Параметры XAMPP «Настроить веб-сервер Apache».
Появится окно с предупреждением о том, что файл предназначен для опытных пользователей:
Предупреждение файла conf XAMPP «для опытных пользователей».
Вы можете нажать Да , чтобы продолжить.Это откроет httpd . conf файл.
Шаг 3. Обновите настройки порта
После того, как файл откроется в текстовом редакторе, следующим шагом будет обновление настроек порта. Для этого вы можете нажать Ctrl + F , а затем ввести «80» в поле поиска. Это отобразит экземпляры числа 80:
.Настройки порта файла httpd.conf XAMPP.
Найдите эти строки:
#Listen 12.34.56.78:80
Слушай 80
Как только вы это сделаете, измените их на следующие:
# Слушай 12.34.56.78: 8080
Слушай 8080 Когда вы закончите, вы можете сохранить и закрыть файл. В поле Configure Apache Web Server нажмите OK .
Шаг 4. Перезапустите Apache
.Последний шаг — остановить и перезапустить Apache, что можно сделать на вкладке «Управление серверами » в XAMPP Application Manager . После остановки Apache нажмите Start для перезапуска:
Порт XAMPP Apache.
Вот и все! Ваши номера портов будут обновлены, и теперь Apache должен работать без ошибок.
Сводка
Ошибка XAMPP «Неожиданное завершение работы Apache» обычно вызывается другой программой, например Skype, использующей порт Apache по умолчанию. Хотя это может расстраивать, обычно у этого есть простое решение.
Как мы обсуждали в этой статье, самый простой способ решить эту проблему — обновить параметры конфигурации XAMPP Apache. Вы можете сделать это, отредактировав файл httpd.conf и файл http-ssl.conf (для пользователей Windows). Как только это будет сделано, вы должны остановить и перезапустить Apache, чтобы возобновить нормальную работу.
Если вам понравилось это руководство, то вам понравится наша поддержка. Все планы хостинга Kinsta включают круглосуточную поддержку наших опытных разработчиков и инженеров WordPress. Общайтесь с той же командой, которая поддерживает наших клиентов из списка Fortune 500. Ознакомьтесь с нашими тарифами
Apache — документация SignalFx
ОБЗОР
Описание
Эта интеграция в основном состоит из монитора Smart Agent collectd / apache .Ниже представлен обзор этого монитора.
Монитор интеллектуального агента
Отслеживает экземпляры веб-службы Apache, используя информацию, предоставленную mod_status .
Рабочие состояния
Рабочие потоки Apache могут находиться в одном из следующих состояний:
| Государство | Замечание |
|---|---|
| Открыть | Открытый (неиспользуемый) слот — нет процесса |
| Ожидание | Ожидание запроса |
| Отправка | Обслуживающий ответ |
| KeepAlive | Остается в живых для возможного следующего запроса |
| Idle_cleanup | Неактивен и помечен для очистки |
| Закрытие | Закрывающее соединение |
| Лесозаготовки | Запись в файл журнала |
| Чтение | Запрос на чтение |
| Чистовая | Окончательная обработка как часть постепенного завершения работы |
| Пусковой | Ввод в эксплуатацию |
НАСТРОЙКА
УСТАНОВКА
Эта интеграция является частью интеллектуального агента SignalFx.
как монитор collectd / apache .Сначала вы должны развернуть Smart Agent на
тот же хост, что и служба, которую вы хотите отслеживать, а затем продолжите
инструкции по настройке ниже.
Настройка Apache
Для настройки самого веб-сервера Apache для отображения показателей состояния:
Включите модуль mod_status на вашем сервере Apache.
Добавьте следующую конфигурацию на свой сервер Apache:
ExtendedStatus вкл. <Местоположение / mod_status> SetHandler server-status
Перезапустите Apache.
Примечание : Убедитесь, что URL-адрес, который вы указываете для модуля mod_status оканчивается на ? авто . Это возвращает страницу состояния как text / plain , что
плагин требует.
Примеры конфигурации
мониторов: - тип: collectd / apache хост: localhost порт: 80
Если mod_status предоставляется на конечной точке, отличной от / mod_status , вы можете
используйте опцию конфигурации url , чтобы указать путь:
мониторов:
- тип: collectd / apache
хост: localhost
порт: 80
url: "http: // {{.Хост}}: {{. Порт}} / server-status? Auto "
Полный список опций см. В разделе Конфигурация.
Конфигурация
Чтобы активировать этот монитор в интеллектуальном агенте, добавьте в свой конфигурация агента:
мониторов: # Вся конфигурация монитора идет под этим ключом - тип: collectd / apache ... # Дополнительная конфигурация
Список параметров монитора, общих для всех мониторов, см. В разделе Общая конфигурация.
| Опция конфигурации | Обязательно | Тип | Описание |
|---|---|---|---|
хост | да | строка | Имя хоста сервера Apache |
порт | да | целое | Номер порта сервера Apache |
наименование | № | строка | Это будет отправлено как измерение plugin_instance и может иметь любое имя. |
url | № | строка | URL-адрес, либо конечный URL-адрес, либо шаблон Go, который будет заполнен значениями хоста и порта. ( по умолчанию: http: // {{.Host}}: {{.Port}} / mod_status? Auto ) |
имя пользователя | № | строка | |
пароль | № | строка |
Метрики
показателей, относящихся к категории контейнер / хост ( по умолчанию ): жирным шрифтом и курсивом в списке ниже.
Это метрики, доступные для этой интеграции.
-
apache_bytes(всего )
Объем данных, обслуживаемых Apache, в байтах. -
apache_connections( калибр )
Количество подключений, обслуживаемых Apache. Это также равно количеству занятых рабочих потоков, где «занято» означает любой рабочий поток, который был успешно запущен и не предназначен для очистки в режиме ожидания. -
apache_idle_workers( калибр )
Число рабочих Apache, которые простаивают. Если это число постоянно мало, то ваш сервер может быть слишком занят, и вам, возможно, придется увеличить количество потоков. Если он постоянно высокий, то система может использоваться недостаточно. -
apache_requests(всего )
Количество запросов, обслуженных Apache. Эта метрика полезна, чтобы узнать общее количество запросов и скорость, с которой Apache может их обслуживать. -
apache_scoreboard.closing( калибр )
Этот показатель показывает, сколько рабочих потоков находятся в процессе закрытия TCP-соединений после обслуживания ответа. Если это число постоянно велико, возможно, возникла проблема с сетью или ошибочный клиент, препятствующий отключению TCP. -
apache_scoreboard.dnslookup( gauge )
Этот показатель подсчитывает количество рабочих потоков, выполняющих поиск в DNS. Если это число слишком велико, проверьте, есть ли проблема с разрешением DNS на вашем сервере.Это может повлиять на производительность сервера Apache. -
apache_scoreboard.finishing( gauge )
Число рабочих потоков, завершающихся в рамках постепенного завершения работы сервера. -
apache_scoreboard.idle_cleanup(, калибр )
Число рабочих потоков, которые простаивают и готовы к очистке. -
apache_scoreboard.keepalive( калибр )
Число рабочих потоков, которые поддерживают соединения keep-alive: поддержание соединения «живым» после обслуживания ответа в ожидании того, что другой HTTP-запрос придет к тому же соединению.В конце интервала проверки активности соединение закрывается. -
apache_scoreboard.logging( калибр )
Этот показатель показывает, сколько рабочих потоков занято записью в файл журнала. Если это число постоянно велико, ваш уровень ведения журнала может быть слишком высоким или один или несколько модулей могут быть слишком подробными. -
apache_scoreboard.open( калибр )
Этот показатель показывает, сколько рабочих слотов открыто. Слоты еще не имеют рабочего потока, но они могут быть развернуты на основе входящих запросов. -
apache_scoreboard.reading( gauge )
Этот показатель показывает, сколько рабочих процессов находятся в процессе получения запросов (заголовков или тела). Если это число постоянно велико, клиенты могут отправлять большие заголовки или загружать большие файлы. -
apache_scoreboard.sending( gauge )
Этот показатель показывает, сколько работников отправляют ответы. Это нормально, если это большое число при измерении сайтов, которые обслуживают большие загрузки. -
apache_scoreboard.starting( калибр )
Этот показатель показывает, сколько работников запускается. Если это число постоянно велико, то система может быть перегружена. -
apache_scoreboard.waiting( gauge )
Эта метрика показывает, сколько рабочих потоков готовы и ожидают поступления запросов.
Размеры
Следующие параметры могут встречаться в показателях, выдаваемых мониторами.Некоторый размеры могут быть специфичными для определенных показателей.
| Имя | Описание |
|---|---|
plugin_instance | Установите все, что вы установили в опции конфигурации name . |
VPS и выделенный хостинг: Easy Apache
Обзор
В этой статье объясняется, как использовать EasyApache для перекомпиляции Apache. Это полезно, если вы хотите добавить собственные модули в свою версию PHP или Apache.
EasyApache 4
Приведенная ниже информация предполагает, что ваш сервер использует EasyApache 4. На некоторых старых серверах может все еще работать EasyApache 3, который больше не получает обновления. Если у вас нет доступа к разделу EasyApache 4 WHM, обратитесь в службу поддержки, и мы будем рады помочь вам обновить ваш сервер до EasyApache 4.
Вовлеченные шаги
Щелкните любой из шагов, чтобы перейти к этому пункту в пошаговом руководстве и просмотреть дополнительные сведения.
Войти в WHM
Вам нужно будет войти в WHM на своем сервере.Для этого необходимо знать пароль root для вашего сервера. Если вы не знаете пароль root или не установили его, см. Вход в WHM.- Войдите в WHM, перейдя на yourdomain.com/whm в браузере. Замените yourdomain.com своим доменом.
- Как только вы попадете на страницу входа в систему, введите свое имя пользователя и пароль.
- Имя пользователя будет root.
- Пароль будет паролем root для вашего сервера. Если вы не знаете пароль root или не установили его, см. Вход в WHM.
- Если вы впервые входите в WHM, вы можете увидеть страницу под названием Feature Showcase . Нажмите Exit to WHM внизу страницы.
Доступ к Easy Apache Tool
После входа в WHM вам нужно перейти в Easy Apache.
- Введите Easy в поле поиска с левой стороны WHM.
- Щелкните EasyApache 4 в результатах поиска.
- Подождите, чтобы загрузить свой профиль. После загрузки нажмите кнопку Настроить для блока «Установленные пакеты».
Выберите ваши параметры
После того, как вы вошли в Easy Apache и выбрали профиль, вы можете выбрать параметры сборки. Каждый раздел предоставляет доступ к набору тумблеров, которые используются для включения этой опции.Вы можете пропустить один или несколько разделов и в любой момент сразу перейти к шагу «Просмотр». В большинстве разделов вверху есть панель поиска, позволяющая найти нужный вариант.
Примечание: Изменение параметров вне разделов «Версии PHP» и «Расширения PHP» должно выполняться только опытными администраторами.
Apache MPM
Модули многопроцессорной обработки Apache (MPM) определяют способ, которым Apache будет прослушивать сеть, принимать и обрабатывать запросы веб-сайтов.Например, Worker MPM превращает Apache в многопроцессорный многопоточный веб-сервер, в котором каждый процесс имеет несколько потоков.Модули Apache
Этот раздел позволяет добавлять или удалять модули из Apache (процесс веб-сервера).Версия PHP
Это контролирует версии PHP, доступные на вашем сервере. После установки версии ее можно применить для определенного домена через WHM в разделе «Программное обеспечение»> «Диспетчер MultiPHP». При выборе вам будет предложено установить только версию по умолчанию или версию плюс расширения, которые система определяет как активные в других установленных версиях PHP.Как правило, рекомендуется выбирать последнее.Расширения PHP
Здесь можно добавить дополнительные расширения PHP. Обратите внимание, что они предназначены для конкретной версии PHP: если у вас есть несколько активных версий PHP на вашем сервере, вам может потребоваться установить расширение для каждой версии. Вы можете использовать флажки вверху для фильтрации расширений в определенной версии или версиях PHP.Рубин через пассажира
Это можно использовать для установки Ruby на сервере. Однако обратите внимание, что служба поддержки не предлагает какой-либо подробной справки по приложениям Ruby, кроме этой первоначальной установки.Дополнительные пакеты
Это можно использовать для установки Tomcat и Node.js. Однако обратите внимание, что служба поддержки не предлагает какой-либо подробной помощи по этим приложениям, кроме начальной установки.Обзор и сборка
Наконец, это покажет вам пакеты, которые вы выбрали для установки на сервер, а также пакеты, которые будут удалены, и те, которые не будут изменены. При необходимости вы все равно можете вернуться и внести в них какие-либо изменения. Когда вы будете готовы продолжить, нажмите кнопку «Предоставление» в нижней части экрана.Перестройка может занять до 45 минут в зависимости от параметров и ЦП, хотя для небольших изменений, таких как добавление модуля PHP, это может занять всего минуту или две. После завершения у вас будет версия PHP и другие выбранные вами параметры, добавленные на ваш сервер.
Как установить веб-сервер Apache в Ubuntu 20.04
Введение
HTTP-сервер Apache — самый широко используемый веб-сервер в мире. Он предоставляет множество мощных функций, включая динамически загружаемые модули, надежную поддержку мультимедиа и обширную интеграцию с другим популярным программным обеспечением.
В этом руководстве мы объясним, как установить веб-сервер Apache на ваш сервер Ubuntu 20.04.
Предварительные требования
Перед тем, как приступить к работе с этим руководством, у вас должен быть обычный пользователь без полномочий root с привилегиями sudo, настроенными на вашем сервере. Кроме того, вам нужно будет включить базовый брандмауэр, чтобы блокировать второстепенные порты. Вы можете узнать, как настроить учетную запись обычного пользователя и настроить брандмауэр для своего сервера, следуя нашему руководству по начальной настройке сервера для Ubuntu 20.04.
Когда у вас есть доступная учетная запись, войдите в систему как пользователь без полномочий root, чтобы начать.
Шаг 1. Установка Apache
Apache доступен в репозиториях программного обеспечения Ubuntu по умолчанию, что позволяет установить его с помощью обычных инструментов управления пакетами.
Начнем с обновления индекса локального пакета, чтобы отразить последние изменения в восходящей ветке:
Затем установите пакет apache2 :
После подтверждения установки apt установит Apache и все необходимые зависимости.
Шаг 2 — Настройка брандмауэра
Перед тестированием Apache необходимо изменить настройки брандмауэра, чтобы разрешить внешний доступ к веб-портам по умолчанию. Предполагая, что вы следовали инструкциям в предварительных условиях, у вас должен быть настроен брандмауэр UFW для ограничения доступа к вашему серверу.
Во время установки Apache регистрируется в UFW, чтобы предоставить несколько профилей приложений, которые можно использовать для включения или отключения доступа к Apache через брандмауэр.
Перечислите профили приложений ufw , набрав:
Вы получите список анкет:
Выход
Доступные приложения:
Apache
Apache Full
Apache Secure
OpenSSH
Как видно из вывода, для Apache доступно три профиля:
- Apache : этот профиль открывает только порт 80 (обычный, незашифрованный веб-трафик)
- Apache Full : этот профиль открывает порт 80 (обычный незашифрованный веб-трафик) и порт 443 (зашифрованный трафик TLS / SSL)
- Apache Secure : этот профиль открывает только порт 443 (трафик с шифрованием TLS / SSL)
Рекомендуется включить профиль с наиболее строгими ограничениями, который по-прежнему будет разрешать трафик, который вы настроили.Поскольку в этом руководстве мы еще не настроили SSL для нашего сервера, нам нужно будет разрешить трафик только на порт 80:
. Вы можете проверить изменение, набрав:
Выходные данные предоставят список разрешенного HTTP-трафика:
Выход
Статус: активен
К действию от
- ------ ----
OpenSSH РАЗРЕШИТЬ В любом месте
Apache РАЗРЕШИТЬ В любом месте
OpenSSH (v6) РАЗРЕШИТЬ В любом месте (v6)
Apache (v6) РАЗРЕШИТЬ В любом месте (v6)
Как указано в выходных данных, профиль был активирован, чтобы разрешить доступ к веб-серверу Apache.
Шаг 3 — Проверка вашего веб-сервера
В конце процесса установки Ubuntu 20.04 запускает Apache. Веб-сервер уже должен быть запущен.
Проверьте систему инициализации systemd , чтобы убедиться, что служба запущена, набрав:
- sudo systemctl статус apache2
Выходные данные
● apache2.service - HTTP-сервер Apache
Загружен: загружен (/ lib / systemd / system / apache2.услуга; включено; предустановка поставщика: включена)
Активен: активен (работает) с Чт 2020-04-23 22:36:30 UTC; 20ч назад
Документы: https://httpd.apache.org/docs/2.4/
Основной PID: 29435 (apache2)
Заданий: 55 (лимит: 1137)
Память: 8,0 МБ
CGroup: /system.slice/apache2.service
├─29435 / usr / sbin / apache2 -k start
├─29437 / usr / sbin / apache2 -k start
└─29438 / usr / sbin / apache2 -k start
Как подтверждается этими выходными данными, служба запущена успешно.Однако лучший способ проверить это — запросить страницу у Apache.
Вы можете получить доступ к целевой странице Apache по умолчанию, чтобы убедиться, что программное обеспечение работает правильно через ваш IP-адрес. Если вы не знаете IP-адрес своего сервера, вы можете получить его несколькими способами из командной строки.
Попробуйте ввести в командной строке вашего сервера:
Вы получите несколько адресов, разделенных пробелами. Вы можете попробовать каждый из них в своем веб-браузере, чтобы определить, работают ли они.
Другой вариант — использовать инструмент Icanhazip, который должен предоставить вам ваш общедоступный IP-адрес, прочитанный из другого места в Интернете:
Когда у вас есть IP-адрес вашего сервера, введите его в адресную строку браузера:
http: // ваш_сервер_ip
Вы должны увидеть веб-страницу Apache Ubuntu 20.04 по умолчанию:
Эта страница указывает на то, что Apache работает правильно. Он также включает некоторую базовую информацию о важных файлах Apache и расположении каталогов.
Шаг 4. Управление процессом Apache
Теперь, когда ваш веб-сервер настроен и работает, давайте рассмотрим некоторые основные команды управления с помощью systemctl .
Чтобы остановить ваш веб-сервер, введите:
- sudo systemctl stop apache2
Чтобы запустить веб-сервер, когда он остановлен, введите:
- sudo systemctl start apache2
Чтобы остановить, а затем снова запустить службу, введите:
- sudo systemctl перезапустить apache2
Если вы просто вносите изменения в конфигурацию, Apache часто может перезагружаться, не разрывая соединения.Для этого используйте эту команду:
- sudo systemctl перезагрузить apache2
По умолчанию Apache настроен на автоматический запуск при загрузке сервера. Если это не то, что вам нужно, отключите это поведение, набрав:
- sudo systemctl отключить apache2
Чтобы снова включить запуск службы при загрузке, введите:
- sudo systemctl включить apache2
Apache теперь должен запускаться автоматически при повторной загрузке сервера.
Шаг 5 — Настройка виртуальных хостов (рекомендуется)
При использовании веб-сервера Apache вы можете использовать виртуальных хостов (аналогично серверным блокам в Nginx) для инкапсуляции деталей конфигурации и размещения более одного домена с одного сервера. Мы создадим домен под названием your_domain , но вы должны заменить его на свое собственное доменное имя . Если вы настраиваете доменное имя в DigitalOcean, обратитесь к нашей сетевой документации.
В Apache в Ubuntu 20.04 по умолчанию включен один серверный блок, который настроен для обслуживания документов из каталога / var / www / html . Хотя это хорошо работает для одного сайта, это может стать громоздким, если вы размещаете несколько сайтов. Вместо изменения / var / www / html , давайте создадим структуру каталогов в пределах / var / www для сайта your_domain , оставив / var / www / html на месте в качестве каталога по умолчанию, который будет обслуживаться, если запрос клиента не соответствует ни одному другому сайту.
Создайте каталог для your_domain следующим образом:
- sudo mkdir / var / www / your_domain
Затем назначьте владение каталогом с помощью переменной среды $ USER :
- sudo chown -R $ USER: $ USER / var / www / your_domain
Разрешения ваших корневых веб-сайтов должны быть правильными, если вы не изменили значение umask, которое устанавливает права доступа к файлам по умолчанию.Чтобы убедиться, что ваши разрешения верны и позволяют владельцу читать, записывать и выполнять файлы, предоставляя только разрешения на чтение и выполнение группам и другим лицам, вы можете ввести следующую команду:
- sudo chmod -R 755 / var / www / your_domain
Затем создайте образец страницы index.html , используя nano или свой любимый редактор:
- sudo nano /var/www/your_domain/index.html
Внутри добавьте следующий образец HTML:
/ var / www / ваш_домен / index.html
Добро пожаловать в Ваш_домен!
Успех! Виртуальный хост your_domain работает!
Сохраните и закройте файл, когда закончите.
Чтобы Apache мог обслуживать этот контент, необходимо создать файл виртуального хоста с правильными директивами. Вместо изменения файла конфигурации по умолчанию, расположенного по адресу / etc / apache2 / sites-available / 000-default.conf напрямую, давайте создадим новый по адресу /etc/apache2/sites-available/your_domain.conf :
- sudo nano /etc/apache2/sites-available/your_domain.conf
Вставьте следующий блок конфигурации, который аналогичен блоку по умолчанию, но обновлен для нашего нового каталога и имени домена:
/etc/apache2/sites-available/your_domain.conf
ServerAdmin веб-мастер @ localhost
ServerName your_domain
ServerAlias www.ваш_домен
DocumentRoot / var / www / ваш_домен
ErrorLog $ {APACHE_LOG_DIR} /error.log
CustomLog $ {APACHE_LOG_DIR} /access.log объединены
Обратите внимание, что мы обновили DocumentRoot до нашего нового каталога и ServerAdmin на адрес электронной почты, доступ к которому имеет администратор сайта your_domain . Мы также добавили две директивы: ServerName , который устанавливает базовый домен, который должен соответствовать этому определению виртуального хоста, и ServerAlias , который определяет дополнительные имена, которые должны совпадать, как если бы они были базовым именем.
Сохраните и закройте файл, когда закончите.
Давайте включим файл с помощью инструмента a2ensite :
- sudo a2ensite your_domain.conf
Отключить сайт по умолчанию, определенный в 000-default.conf :
- sudo a2dissite 000-default.conf
Теперь давайте проверим ошибки конфигурации:
- sudo apache2ctl configtest
Вы должны получить следующий результат:
Выход
Синтаксис ОК
Перезапустите Apache, чтобы изменения вступили в силу:
- sudo systemctl перезапустить apache2
Apache теперь должен обслуживать ваше доменное имя.Вы можете проверить это, перейдя по адресу http: // your_domain , где вы должны увидеть что-то вроде этого:
Шаг 6. Знакомство с важными файлами и каталогами Apache
Теперь, когда вы знаете, как управлять самой службой Apache, вам следует потратить несколько минут, чтобы ознакомиться с несколькими важными каталогами и файлами.
Содержание
-
/ var / www / html: Фактический веб-контент, который по умолчанию состоит только из страницы Apache по умолчанию, которую вы видели ранее, обслуживается из каталога/ var / www / html.Это можно изменить, изменив файлы конфигурации Apache.
Конфигурация сервера
-
/ etc / apache2: Каталог конфигурации Apache. Здесь находятся все файлы конфигурации Apache. -
/etc/apache2/apache2.conf: основной файл конфигурации Apache. Это можно изменить, чтобы внести изменения в глобальную конфигурацию Apache. Этот файл отвечает за загрузку многих других файлов в каталоге конфигурации. -
/ etc / apache2 / ports.conf: этот файл определяет порты, которые Apache будет прослушивать. По умолчанию Apache прослушивает порт 80 и дополнительно прослушивает порт 443, когда включен модуль, обеспечивающий возможности SSL. -
/ etc / apache2 / sites-available /: каталог, в котором могут храниться виртуальные хосты для каждого сайта. Apache не будет использовать файлы конфигурации, найденные в этом каталоге, если они не связаны с каталогом с поддержкой сайтов. Обычно вся конфигурация серверных блоков выполняется в этом каталоге, а затем включается путем связывания с другим каталогом с помощью командыa2ensite. -
/ etc / apache2 / sites-enabled /: каталог, в котором хранятся включенные виртуальные хосты для каждого сайта. Обычно они создаются путем связывания файлов конфигурации, находящихся в каталогеsites-available, с помощьюa2ensite. Apache читает файлы конфигурации и ссылки, найденные в этом каталоге, при запуске или перезагрузке для компиляции полной конфигурации. -
/ etc / apache2 / conf-available /,/ etc / apache2 / conf-enabled /: Эти каталоги имеют те же отношения, что и каталогиsites-availableиsites-enabled, но используются для хранить фрагменты конфигурации, не принадлежащие виртуальному хосту.Файлы в каталогеconf-availableможно включить с помощью командыa2enconfи отключить с помощью командыa2disconf. -
/ etc / apache2 / mods-available /,/ etc / apache2 / mods-enabled /: Эти каталоги содержат доступные и включенные модули соответственно. Файлы, заканчивающиеся на.load, содержат фрагменты для загрузки определенных модулей, а файлы, заканчивающиеся на.conf, содержат конфигурацию для этих модулей.Модули можно включать и отключать с помощью командa2enmodиa2dismod.
Журналы сервера
-
/var/log/apache2/access.log: по умолчанию каждый запрос к вашему веб-серверу записывается в этот файл журнала, если Apache не настроен на иное. -
/var/log/apache2/error.log: по умолчанию все ошибки записываются в этот файл. ДирективаLogLevelв конфигурации Apache указывает, насколько подробно будут содержаться журналы ошибок.
Заключение
Теперь, когда у вас установлен веб-сервер, у вас есть много вариантов для типа контента, который вы можете обслуживать, и технологий, которые вы можете использовать для создания более насыщенного опыта.
Если вы хотите создать более полный стек приложений, вы можете прочитать эту статью о том, как настроить стек LAMP в Ubuntu 20.04
Вертолет, который сопротивляется
Популярная механика
В феврале 1985 года «Популярная механика» впервые увидела новое поколение военных вертолетов, способных защитить себя в бою.Главным из них был новый AH-64 Apache, вертолет, получивший название «Летающий танк». Созданный на основе уроков, извлеченных из войны во Вьетнаме, Apache будет служить вооруженным силам США еще несколько десятилетий.
Странное привидение внезапно проносится над горным хребтом со скоростью почти 200 миль в час, изрыгая пламя из похожих на клыки ракетных стволов, когда оно нацеливается на колонну боевых танков противника в долине внизу. Танки, застигнутые врасплох, не могут избежать смертельной атаки.
Этот свирепый на вид, огнедышащий монстр мог быть чем-то вроде фильма ужасов, но для американских войск на каком-нибудь поле битвы будущего это будет самое красивое зрелище. Это новый Hughes AH-64 Apache, самый прочный, самый подлый и самый крутой боевой вертолет из когда-либо созданных. При цене 10 миллионов долларов за штуку он также самый дорогой. Ощетинившись ракетами и ракетами, выпущенными из опор, он олицетворяет новое поколение быстрых, маневренных и мощных боевых вертолетов, разработанных специально для поиска и уничтожения тяжелобронированной техники на земле и вражеских вертолетов в воздухе.
Потребность в таких воздушных убийцах танков была доказана на собственном горьком опыте во время войны во Вьетнаме, когда единственные доступные в то время боевые вертолеты были немногим больше, чем гражданские модели, окрашенные в оливково-серый цвет и оснащенные малокалиберным пулеметом. Не имея тяжелого вооружения для самообороны и бронированной кабины для защиты экипажа, они просто сидели, когда подвергались наземному огню противника на малых высотах. Их могли сбить даже несколько правильно сделанных выстрелов из винтовки. Знаменитый вертолет Huey, призванный на военную службу, добился хороших результатов, несмотря на свои ограничения, но заплатил высокую цену.Было потеряно более 5000 человек.
Больше нет. Предполагается, что современные боевые вертолеты обеспечат наши войска мощным оружием наземной поддержки в любой предстоящей наземной войне. В мрачном мире реальности поля боя планировщики НАТО подсчитали, что один ударный вертолет убьет в среднем 16 врагов, прежде чем сам будет уничтожен или выведен из строя. Как бы хладнокровно это ни звучало, тем не менее, это важно. Это означает, что относительно скромные силы в 600 боевых кораблей могут составлять около 10 000 вражеских танков, ракетных объектов или других ключевых целей, число которых, как считается, достаточно велико, чтобы переломить ход битвы в пользу НАТО.
Предлагаемая для ВМФ версия Hughes Apache несет противокорабельные ракеты Harpoon и имеет обтекатель для обнаружения цели над несущим винтом.Популярная механика
Универсальный Sikorsky Black Hawk является одновременно мощным убийцей танков и боевым кораблем. Он несет 16 ракет Hellfire на опорах аутригеров.Популярная механика
Фактически, генеральный план сражения, получивший название «Операция« Глубокий удар », уже был составлен стратегами НАТО и Пентагона для компенсации огромного численного превосходства сил Варшавского договора.Этот план основан на предположении, что нынешние силы НАТО никогда не смогут надеяться пережить полный удар вторжения в условиях обычной прямой конфронтации. Вместо этого он представляет собой современный эквивалент классической тактики «разделяй и властвуй». Поскольку первая волна врага атакует, ему преднамеренно позволяют прорвать линии НАТО с небольшим сопротивлением. Оказавшись внутри линий, противник окружен, пойман в ловушку и в конечном итоге побежден.
Между тем, глубоко внутри вражеской территории наносятся массированные удары с воздуха, чтобы атаковать и уничтожить вторую, третью и четвертую волны, прежде чем они успеют сгруппироваться и продвинуться.Противотанковые вертолеты, а также истребители / бомбардировщики с неподвижным крылом и баллистические ракеты дальнего действия будут играть важную роль в этих атаках в тылу, помогая помешать противнику собрать всю свою мощь.
Операция «Глубокий удар» также рассматривается, как это ни парадоксально, как средство сдерживания ядерной войны. Аргументация такова: если силы НАТО смогут отбить нападавших с помощью обычных вооружений, им не придется прибегать к применению ядерного оружия, и захватчики, уже сильно ослабленные, не осмелятся применить их, опасаясь быстрого возмездия.Таким образом, согласно теории, обе стороны будут избавлены от ужаса ядерной эскалации.
Построен, чтобы выжитьНесмотря на расчетные потери, ожидаемые экспертами НАТО, армия США не считает свои боевые корабли расходными материалами даже при соотношении потерь 16 к 1 и, конечно, не при 10 миллионах долларов за бросок. Живучесть боевого вертолета так же важна, как и его вооружение - если он не выдерживает злоупотреблений, он не проживет долго, чтобы сражаться.
Hughes Apache, как и многие другие новые конструкции, помещает пилота и второго пилота / стрелка в отдельные кабины, один за другим, вместо прежней компоновки с одной кабиной с сиденьями бок о бок.Каждая кабина окружена тяжелой броней, похожей на стальную ванну, и оба разделены прозрачным противоударным экраном.
Как вертолет может атаковать, оставаясь незамеченным
Популярная механика
Как поразить, когда вы не видите: вооруженный противотанковыми ракетами Hellfire с лазерным наведением боевой вертолет невидимо парит за холмом. Он не может видеть врага, но другие глаза могут. Лазерный луч высокой интенсивности, называемый целеуказателем, направляется на карьер либо со второго вертолета-разведчика, либо со скрытого наземного подразделения.Ракеты боевого корабля с дальностью более 7500 ярдов затем попадают в лазерный луч, уничтожая цель, в то время как боевой корабль остается надежно скрытым на расстоянии до четырех миль.
Тандемная компоновка кабины не только сужает фюзеляж, что затрудняет поражение цели, но и изолирует членов экипажа для большей безопасности. Двухтурбинные двигатели обеспечивают резервную мощность на случай отказа одного из двигателей, а специальные песчаные фильтры на впускных отверстиях предотвращают засорение в пустынных регионах, что стало одной из проблем, которые преследовали злополучную попытку спасти U.С. заложники в Иране.
Apache несет до 16 ракет Hellfire с лазерным наведением для уничтожения танков или до 76 ракет для использования по менее бронированным целям. На нем также установлена устрашающая 30-миллиметровая носовая пушка, способная делать 600 выстрелов в минуту. Он имеет переднюю скорость почти 200 миль в час, движется вбок или назад со скоростью 60 миль в час и может тянуть большие перегрузки в крутых поворотах и крутых подъемах, что делает его быстрым и маневренным истребителем.
Electronic EyesСовременный боевой вертолет состоит из трех электронных чудес, которые могли быть взяты прямо из фильма «Звездные войны»: система наведения и ночного видения Martin Marietta TADS / PNVS, нашлемный дневной / ночной прицел Honeywell и дневной мачтовый прицел McDonnell Douglas / Bell / ночной прицел сопровождения цели.
Они позволяют пилоту вертолета видеть в темноте точечные цели, обычно скрытые от поля зрения, и скользить по пересеченной местности на уровне верхушек деревьев даже ночью и в плохую погоду. Способность ехать на скоростях, приближающихся к 200 милям в час, так называемое маневрирование «ворчание земли» - вот что позволяет боевому кораблю наносить удары с такой разрушительной быстротой и неожиданностью, используя естественные особенности земли, чтобы замаскировать его от вражеских радаров и зенитного огня.
Выглядящий как глаза жука, выпирающие из носа боевого корабля, TADS / PNVS состоит из двух оптических сканеров со стеклянной лицевой панелью, удерживаемых в подвижных креплениях, поэтому их можно наводить в любом направлении.Один содержит оптику TADS, другой - оптику PNVS. TADS, что расшифровывается как Target Acquisition Designation Sight, включает телекамеру для дневного наблюдения, инфракрасный формирователь изображения для ночного видения и генератор лазерного луча для обнаружения целей и наведения ракет. Все, что нужно сделать пилоту или стрелку, - это навести лазер на цель, и его ракеты Hellfire с лазерным наведением автоматически попадут в луч, уничтожая все, на что он нацелен. Ракеты могут управляться даже удаленным лазерным источником, например, с вертолета-разведчика или переносного наземного генератора.
PNVS, другая половина системы, обозначает датчик ночного видения для пилотов и содержит инфракрасный формирователь изображения, который обеспечивает ярко освещенный обзор местности внизу ночью или в сильный дождь и туман. Он используется в основном пилотом для навигации близко к земле в темноте, но также может обнаруживать термически активные цели.
Убивающий взгляд
Популярная механика
То, что вы видите, это то, что вы попадаете.С новым нашлемным прицелом, разработанным Honeywell, все, что нужно пилоту вертолета, - это смотреть на вражескую цель и стрелять из пушки. Пушка мгновенно наводится на цель, автоматически следуя за его линией обзора независимо от того, в какую сторону он поворачивает голову.
Сердце этой замечательной системы - крошечный прозрачный окуляр, прикрепленный к шлему пилота так, что он закрывает его правый глаз. Окуляр соединен электроникой с оптическим сканером с сервоприводом, который закреплен на подвижном подвесе в носовой части самолета.Сканер, будь то телекамера для дневного света или инфракрасный датчик для ночного видения, отслеживает движения головы пилота, смотря куда бы он ни смотрел. Пушка, расположенная под носом в аналогичном карданном подвесе, сервоприводится к сканеру, поэтому она указывает на то, куда направлен сканер.
То, что пилот видит поверх окуляра, - это четко очерченный вид местности внизу, даже в плохую погоду или темноту, что позволяет легко выделить цель, которая в противном случае могла бы быть невидимой.Также в окуляре отображается жизненно важная информация о полете, такая как курс, скорость и высота, поэтому пилот может управлять аппаратом, не глядя на свои приборы. Поскольку он видит через глаз сканера, а не только своими глазами, он, по сути, может видеть сквозь твердые объекты. Он может смотреть в пол и замечать цель прямо под ним, как если бы нижняя часть фюзеляжа была прозрачной.
Названный IHADSS (интегрированная система прицеливания на шлеме и дисплее), обзорный прицел Honeywell был разработан специально для нового противотанкового боевого корабля Apache, но также может быть адаптирован к другим боевым вертолетам.
Шлемовой прицел Honeywell используется в сочетании с системой TADS / PNVS, чтобы позволить пилоту или стрелку наводить сканеры простым движением головы. Он электронно связан с серводвигателями, которые приводят в действие сканеры, поэтому они автоматически следят за его линией взгляда - куда бы он ни смотрел, они смотрели.
И система TADS / PNVS, и нашлемный прицел были разработаны специально для Apache, но могут быть адаптированы к другим боевым кораблям. Установленный на мачте прицел McDonnell Douglas / Bell содержит дневную / ночную оптику и генератор лазерного луча, аналогичный тем, что используются в системе TADS / PNVS, но помещает их в корпус, похожий на глазное яблоко, наверху стойки над винтом вертолета.Находясь в приподнятом положении, прицел может заглядывать за деревья и хребты, обнаруживая вражеские цели, в то время как сам вертолет остается скрытым от глаз.
Хотя он может быть адаптирован к боевым кораблям, он предназначен в первую очередь для использования на вертолетах-разведчиках, позволяя им обнаруживать цели незаметно. Как только цель обнаружена лазерным лучом разведчика, она передается на ближайший боевой вертолет, такой как Apache, для фактического уничтожения.
Оппозиция«Апачу» лучше быть хорошим, потому что он сталкивается с жесткой конкуренцией в лице российского Ми-24 Hind, боевого вертолета усовершенствованной конструкции, уже доказавшего свою эффективность во время советского вторжения в Афганистан.
Как и Apache, это тяжело бронированный тандемный самолет, оснащенный ракетами с лазерным самонаведением. Однако у него может быть как минимум одна слабость. В отличие от Apache, он явно не предназначен для маневров с высокой перегрузкой. Некоторые из них разбились, когда лопасти несущего винта врезались в хвостовую балку из-за резкого изменения направления.
Hind также является огромной машиной, которую трудно скрыть, и это одна из немногих боевых моделей, которые, как известно, есть у русских. Напротив, Соединенные Штаты и их зарубежные партнеры по НАТО выпускают более дюжины различных типов и размеров, подходящих для различных требований миссии и условий поля боя.Sikorsky UH-60A Black Hawk, хотя технически это универсальный транспорт, может быть оснащен ракетами Hellfire для противотанковых боевых вылетов и является быстрым и надежным самолетом. Около 1100 «Черных ястребов» и 675 апачей уже заказаны армией.
Другие боевые модели США включают в себя Hughes 530MG Defender, дневной, всепогодный боевой корабль с мачтовым прицелом; Bell 406 Combat Scout, комбинированный разведывательно-ударный вертолет; многоцелевой H-76 Sikorsky, войсковой транспорт с противотанковыми возможностями; и Bell AH-1 Huey Cobra, танковый убийца с тандемным сиденьем, который является высокотехнологичной и хорошо вооруженной производной от винтажного вьетнамского Huey.
Из Франции прибывает Aerospatiale Gazelle, злобная машина, которая в модифицированном виде сыграла чудо-суперкоптер в научно-фантастическом фильме « Blue Thunder ». Еще более грозная версия, Dauphin, будет иметь усовершенствованную авионику и более тяжелое вооружение. Вклад Великобритании - новый Westland Lynx-3, универсальный боевой корабль для работы в дневное и ночное время в любых погодных условиях, оснащенный как авионикой TADS / PNVS, так и мачтовым прицелом.
Западногерманский PAH-1 производства Messerschmitt-Bolkow-Blohm несет противотанковые ракеты, но вскоре будет заменен PAH-2, модернизированной тандемной моделью, оснащенной как воздух-земля, так и воздух-воздух. ракеты, авионика TADS / PNVS и 30-мм носовая пушка, аналогичная пушке Apache.Итальянский Agusta A-129 Mangusta (по-итальянски мангуст) также является тандемным самолетом и, как и Apache, имеет как авионику ночного видения, так и лазерное наведение.
Сегодняшние боевые вертолеты не могут видеть сквозь стены, как вымышленный Blue Thunder , но они могут делать некоторые довольно дикие вещи. А завтрашние версии с еще более совершенной авионикой и более мощными системами вооружения могут даже заставить Blue Thunder выглядеть ручным.
AH-64 Apache, 18 марта 1982 г.Роберт Д. Уорд
.