Как вы максимизируете производительность сервера? - PullRequest
5 голосов
/ 11 января 2009

Я пытался понять, что такое производительность и масштабируемость, и хотел бы знать, что делают разработчики / системные администраторы для создания сока своих систем. Чтобы стандартизировать ответы, было бы полезно, если бы вы наилучшим образом ответили на любое из следующего:

  1. Профиль - публикация журнала на Joomla; Доска вакансий на CodeIgniter + OpenId + AJAX
    • Производительность - Максимальное количество запросов в секунду на сервер ?
    • Оборудование - Сервер, маршрутизатор, диск, локальная сеть?
    • Программное обеспечение - Lighttpd, Memcache, Varnish, Nginx, Squid, Pound, LVS, eAccelerator и т. Д.
    • Сервисы - Amazon S3, Akamai, Google Compute и т. Д.
    • Конфигурация - Статическое хеширование, модуль Upstream, Memcache на x минут после n запросов, отключение регистрации запросов изображений и т. Д.
    • Другое - Что-нибудь еще? (например, нормализованные таблицы плохо для сайтов с большим чтением)

Редактировать: Пожалуйста, перед закрытием этого вопроса еще раз подумайте: * * * * * * важно для веб-разработчиков при поиске этого материала Программист может настроить точку с запятой в своем коде, но все равно проиграть плохой кодер, пишущий для memcached или умеющий собрать CDN через Google App Engine.

Ответы [ 3 ]

3 голосов
/ 11 января 2009

Наша система: я не могу вам многое рассказать об этом, но это большое SaaS-приложение, обслуживающее многих платящих клиентов.


Каждая часть работы над производительностью / мощностью, которую мы выполняем, выполняется очень осторожно - мы не можем просто попробовать что-то проверить, чтобы убедиться, что они работают.

Первоначально был бы некоторый анализ текущей производительности и мощности, можем ли мы продолжать работать в любом случае.

Если возможно, мы будем воспроизводить проблемы с производительностью в непроизводственной системе, где мы можем профилировать код и вносить экспериментальные изменения. Мы не всегда можем использовать точно такое же оборудование, как и на производстве (на производстве имеется большое количество серверов с очень высокими техническими характеристиками; у dev есть только несколько специализированных блоков тестирования производительности для производственных спецификаций).

Если проблема не может быть осмысленно проанализирована в непроизводственной среде, мы отправим некоторые инструменты в наш код в процессе производства (после тщательного тестирования, чтобы убедиться, что инструменты не влияют на саму систему). Эта аппаратура будет поставляться «выключенной» и включаться выборочно, чтобы собрать достаточно данных.

Как только мы получим точный анализ проблемы, мы рассмотрим возможные решения и, возможно, разработаем прототипы - их можно будет проверить на функциональную корректность.

Обычно мы выбираем наименее рискованный вариант, если их несколько.

Затем будет следовать нормальный процесс выпуска - множество тестов, обзоров кода и т. Д.

Если необходимо, изменение может быть отправлено с «переключателем возврата», который позволяет быстро отключить его в производственном режиме, если возникла проблема.

Существует много потенциальных улучшений производительности, которые мы определили, большинство из которых мы не будем развивать до тех пор, пока не возникнет проблема (если мы в любом случае не выполняем рефакторинг этого компонента программного обеспечения).

3 голосов
/ 12 января 2009

Не существует конкретного генерального плана для оптимизации производительности (как сначала запуск в программном обеспечении "xyz").

Общий подход:

  1. Определить (измерить!) Вашу самую способную к совершенствованию сущность посредством улучшения / затраченного времени
  2. Оптимизация
  3. Повторите
2 голосов
/ 11 января 2009

У меня нет времени, чтобы ответить на ваш вопрос bullet by bullet. =) Но я могу рекомендовать общую стратегию разделения проблем, а не объединять ресурсы сервера, когда в этом нет срочной необходимости. mod_proxy (и любые его эквиваленты) - ваш друг. Это позволяет легко бросать аппаратные средства при проблемах производительности, которые обнаруживаются. Конечно, вам не нужно идеально учитывать систему с самого начала (поскольку очень трудно предвидеть, где будут обнаруживаться реальные узкие места). Но когда вы сталкиваетесь с проблемами. Помни своего друга.

...