У меня есть веб-сервер, который я хочу протестировать, прежде чем делать некоторые оптимизации, чтобы увидеть, имеют ли они какой-либо эффект.
Однако я хочу знать, как лучше всего проводить сравнительный анализ?
Например, коллега посоветовал мне протестировать машину с другой машиной в локальной сети, чтобы устранить проблемы с сетевым трафиком.
Тем не менее, я думал об использовании стороннего компьютера для тестирования, потому что хотел увидеть, повлияет ли оптимизация на ситуацию в реальном мире.
Я утверждал, что многие настройки скорости связаны с оптимизацией сетевого соединения. Например, в Apache значение KeepAlive позволяет браузерам использовать одно TCP-соединение для запроса нескольких объектов вместо открытия и закрытия соединения для каждого ресурса.
Если бы тест проводился при подключении к локальной сети, то эта настройка не имела бы особого значения, верно? То же самое с минимизацией js / css и удалением пробелов / комментариев из HTML.
С другой стороны, я вижу проблему с тем, что интернет-трафик при каждом запуске теста не соответствует требованиям. Я бы не знал, связаны ли изменения в числах с настройками или серверы между ними увеличили или уменьшили нагрузку.
Кто прав? Как лучше всего проводить сравнительный анализ? Стоит ли делать и то, и другое?
tl; dr - Должен ли я тестировать, используя машину в локальной сети / за пределами площадки / или на обоих?
Все это во многом зависит от вашего сайта. Выполнение тестов как в автономном режиме, так и на месте не повредит. Но что настраивать и как тестировать?
Если вы в основном раздаете статический контент или очень простой динамический контент и делать это с безумной скоростью, тогда имеет смысл настраивать вещи на уровне тайм-аута / ядра Apache.
Если у вас динамический сайт, то настройка очень скоро станет совсем другой. Конечно, выполнение всех этих оптимизаций на уровне Apache и ядра по-прежнему является разумным занятием, но не позволяйте им себя одурачивать и копировать.
Когда дело доходит до настройки / тестирования производительности, всегда в первую очередь заботьтесь о самых медленных частях. В случае динамического сайта реальным узким местом, скорее всего, является 1) база данных или 2) скрипты, которые выполняет ваш сайт.
Если самая медленная часть - это база данных, нет смысла настраивать производительность вашего Apache, прежде чем вы сможете сделать свою базу данных быстрой. В дополнение к этому вам нужно убедиться, что у вас есть правильные методы кеширования, и вы запускаете memcached или подобное, если возможно.
Итак, это было о какие для тестирования и настройки. Сейчас, как для сравнения?
Мне нравится проводить два вида тестов. Если цифры уже известны - скажем, сайт обновляется, поэтому вы знаете уникальных посетителей, загрузку страниц и аналогичную статистику со старого сайта - я провожу реалистичный тест со скоростью, аналогичной текущему веб-сайту. Я также сравниваю его с аналогичным показателем * 2, чтобы увидеть, выдержит ли он небольшой рост в будущем.
Другой вид тестов, который мне нравится проводить, - это выкурить и сжечь сайт. Я просто замучу до чертиков, запустив тест как можно быстрее с безумным количеством одновременных запросов. Если он выдержит - отлично, если не выдержит, я найду предел.
Инструменты, которые мне нравятся: ab, siege, JMeter.
Я использовал собственный формат журнала с указанием% T (время обслуживания) на постоянной основе. se Я заменил% l (имя идентификатора) в формате. Это можно использовать для определения медленных страниц для настройки. Большие ответы на медленных линиях могут вызвать ложные срабатывания, как и попытки сети.
Я использовал собственный сценарий сводки журнала, чтобы определить страницы с самым медленным откликом и средним временем отклика. Это могут быть хорошие цели для оптимизации. Сравнение отчетов с течением времени помогает определить предстоящие проблемы.
Инструменты на стороне клиента могут обеспечить хорошие тесты стресса и убедиться, что исправления не нарушили работу сайта. Существуют факторы, которые могут предоставить эталонные тесты, не соответствующие тому, что вы получаете в производстве.