Apache2 SSL 'значение по умолчанию virtualhost' не работает

Параллелизм был моей первой мыслью, поскольку параллелизм по умолчанию в ab один и добавление, что подсистема балансировки нагрузки будет всегда увеличивать задержку запроса, но Вы упомянули установку параллелизма на 100, таким образом, это не должно быть причиной.

Обратный прокси будет, вероятно, добавлять заголовок к каждому запросу. Это делает ответы немного больше при использовании nginx чем тогда, когда нет. Вероятно, незаметное изменение при выполнении этого более чем Гигабитная внутренняя сеть, но если Вы выполняете это из своего офиса или из Вашего дома, и особенно при использовании маленького файла, чтобы сделать этот тест, дополнительные данные, могло бы вызвать измеримое различие. Конечно, маленькие файлы довольно нормальны в сети, таким образом, маленькие файлы могли бы сделать для более реалистического сравнительного теста.

Кэширование может также иметь значение к последующим выполнениям в зависимости от того, как Ваш сравнительный тест выполняется. Это сделает Ваш первый показ медленнее, чем все выполнения после него. Это составлено еще больше, когда выравнивание нагрузки, потому что существует вдвое больше кэшей для нагреваний. Если Вы протестировали nginx сначала, который, возможно, вызвал различие. Можно смягчить это путем выключения всего кэширования или игнорирования первого показа, который Вы делаете. Довольно трудно получить все кэши, и некоторые даже не могут находиться под Вашим контролем. Я одобрил бы ignoring-the-first-run метод. Вы упомянули выполнение нескольких выполнений с различными значениями, но что необходимо сделать, чтобы избежать, чтобы основанные на кэше погрешности выполнили точно тот же сравнительный тест два или больше раза подряд и проигнорировать первый показ.

Другой вещью, которая может вызвать этот вид поведения, является блокировка где-то в другом месте в системе. "Блокировкой" я имею в виду ресурс, который только один из веб-серверов может использовать за один раз. Пример этого сохранил бы сессии PHP в таблице MyISAM в Вашей базе данных. Каждый запрос к странице PHP или собирается сделать, запрос чтения на этой таблице для поиска сессии или записи запрашивает создать новую сессию. Поскольку таблицы MyISAM имеют блокировку уровня таблицы, только один из Ваших веб-серверов может использовать эту таблицу в любой момент времени, и так как каждая страница должна будет использовать эту таблицу, это может инвертировать преимущество наличия двух веб-серверов полностью. Чем более быстрой остальной частью Ваша система является, тем более относительный эффект блокировка будет иметь. Это не имеет, чтобы быть базой данных или, это мог быть общий webroot на SAN или NAS, поэтому даже статические файлы не неуязвимы для этого вида проблемы. Вы не упоминали никакие другие системы в своем исходном вопросе, но эта проблема очень вероятно обнаружится, когда Ваша система растет.

Наконец, немного (это превратилось в довольно много) общих рекомендаций по сравнительному тестированию. Причина Вы получаете особую скорость (или количество запросов в секунду на этот вид сравнительного тестирования) всегда происходит из-за единственного узкого места. Сравнительный тест Apache будет просто продолжать запрашивать с такой скоростью, как он может до некоторого ресурса достигать используемых 100%. Этот ресурс может быть центральными процессорами в Ваших веб-серверах, или это может быть ЦП в обратном прокси-сервере. Однако это маловероятно. Доступ к диску и сетевая пропускная способность (внутренний и внешний) обычно являются первыми узкими местами, с которыми Вы сталкиваетесь, задолго до того, как скорость ЦП становится проблемой. Даже если Вы видите ресурс в используемых 90%, это не узкое место. Будет другой где-нибудь в 100%, который мешает этому идти немного выше, чем 90%. Тот в 100% может быть в другой системе, и это не может быть система, которой Вы владеете. Это может быть сеть, и это означает конкретное устройство, такое как переключатель или NIC или даже кабели, который является частью сети.

Для нахождения истинного горлышка бутылки необходимо ли запустить в некотором значении, которое можно измерить (скажите, число nginx в настоящее время активных рабочих), и спросите, "Почему это не идет немного выше?" Если это достигло своего максимального значения, затем Вы нашли свое узкое место. В противном случае следующее место, необходимо посмотреть, является связанным запросом. Идете ли Вы в восходящем направлении, или в нисходящем направлении вопрос инстинкта пищеварительного тракта. Нисходящий поток, nginx будет просить сетевые слоты передавать запросы Apache. Спросите себя, если количество соединений открытой сети в ее максимуме. Затем пропускная способность NIC. Затем пропускная способность сети. Затем пропускная способность NIC машины Apache. Можно пропустить некоторые из этих шагов, если ответ очевиден, но только пойдите, случайным образом предположив путь через систему. Сделайте свои поиски заказанными и логичными.

Иногда узкое место, с которым Вы сталкиваетесь, будет на машине, Вы работаете на ab. Когда это происходит, сравнительный тест бессмыслен. Все, что Вы протестировали, является скоростью машины или сети, Вы работаете на ab. Вы получили бы тот же Google сравнительного тестирования результата, как Вы будете свой сайт. Чтобы удостовериться, чтобы у Вас был значимый сравнительный тест, необходимо найти узкое место, в то время как сравнительный тест работает. (Или по крайней мере удостоверьтесь, что это не находится на машине тестирования.) Для улучшения сравнительных тестов сайта, необходимо найти узкое место в системе и расширить его, и это является самым легким сделать, в то время как сравнительный тест работает.

Тестирование большой системы как Вы является средствами, что количество мест, которые могло скрыть узкое место, является довольно большим. Иногда это может помочь сузить Ваш сравнительный тест всего к нескольким частям системы. Включение nginx и движение к Apache являются одним примером этого и выполнения Вашего сравнительного теста в той же сети, как веб-серверы - другой. Но можно пойти далее и сравнить отдельных компонентов, таких как диск, сеть и задержка RAM и пропускная способность.

К сожалению, не все ресурсы имеют хорошие легкие проценты, сообщил способ, которым делают ЦП и Использование оперативной памяти. Например, при записи большого файла в диск можно получить 40MB/s, но при записи, что много небольших файлов и чтение их въезжают задним ходом одновременно (такие как сессии PHP, сохраненные на диске), можно получить 10MB/s. Для нахождения истинного размера ресурса, необходимо выполнить сравнительные тесты на каждой части системы индивидуально. Не предполагайте, что Вы получите 1000Mb/s по своей внутренней сети просто, потому что у Вас есть Гигабитный переключатель. IP, TCP и заголовки прикладного уровня, такие как заголовки NFS могут все уменьшить этот сравнительный тест, как может медленнее NICs и кабели. Аппаратные ошибки могут также влиять на все виды сравнительных тестов, в то время как аппаратные средства все еще функционируют, но в меньше, чем спецификации производителя.

Узкое место может быть на nginx машине. Если так, причина загрузки сбалансировала решение, являющееся медленнее, чем прямой единственный сервер должен быть очевидным. На данном этапе некоторые предложения rmalayter были бы хороши для следования. Пока Вы не знаете, где узкое место, Вы просто предполагаете и мы тоже. Если узкое место в другом месте, необходимо, вероятно, найти его и затем возвратиться сюда и искать или задать более конкретный вопрос.