Подтвердить что ты не робот

Лучшие методы оптимизации сайтов LAMP для скорости?

Я хочу знать, когда вы строите типичный сайт в стеке LAMP, как вы оптимизируете его для наилучшего времени загрузки. Я представляю типичный сайт, управляемый DB.

Это высокоуровневый вид и, вероятно, может затронуть вопрос и позволить мне разбить его на каждый уровень стека.

L - На системном уровне (настройка и файловая система) вы можете улучшить скорость? Одна вещь, о которой я могу думать, это размеры изображения, может ли сжатие здесь помочь оптимизировать что-нибудь?

A - На веб-сервере должна быть тонна настроек, связанных с скоростью сайта. Не моя Форте. Вероятно, многое зависит от того, сколько сайтов работает одновременно.

M - MySQL на сайте, управляемом базой данных, является ключевым фактором эффективности БД. Есть ли лучший подход к нормализации, т.е. С использованием таблиц ссылок? Веб-разработчики часто просто делают простые монолитные таблицы похожими на 1NF, и это может убить производительность.

P - помимо настроек повышения производительности, таких как кеширование, что может сделать программист, чтобы повлиять на производительность на высоком уровне? Мне бы очень хотелось узнать, приближается ли проект MVC к производительности быстрее, чем быстро и грязно. Другие простые советы, такие как сеансы быстрее, чем файлы cookie, будут интересны.

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

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

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

Итак, мой вопрос: если вы начинаете с нуля, как бы вы убедились, что ваш сайт LAMP был быстрым?

4b9b3361

Ответ 1

Вот несколько личных must-dos, которые я всегда настраивал в своих приложениях LAMP.

  • Установите mod_deflate для apache и не используйте обработчики gzip PHP. mod_deflate позволит вам сжимать статическое содержимое, например javascript/css/static html, а также как обычный динамический вывод PHP, и это еще одно дело, что вам нужно беспокоиться в вашем коде.

  • Будьте осторожны с файлами .htaccess! Включение файлов .htaccess для каталоги в вашем приложении означают, что Apache должен сканировать файловую систему постоянно, ища .htaccess директивы. Гораздо лучше поставить директивы внутри основного конфигурации или vhost конфигурации, где они загружаются один раз. Каждый раз, когда вы можете избавиться от файл доступа на уровне каталога путем перемещения он в основной файл конфигурации, вы сохраняете время доступа к диску.

  • Подготовьте свою базу данных приложений для использования диспетчера соединений (я использую Singleton для большинство приложений). Это не очень трудно сделать и уменьшить число подключения к базе данных приложение открывает экономию ресурсов.

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

  • Как только приложение будет запущено, установите MySQL медленное время запроса до небольшого число и мониторинг медленного журнала запросов старательно. Это покажет вам, где ваши проблемы возникают, и позволяют оптимизировать запросов и индексов, прежде чем они становятся проблемой.

  • Для серьезных твикеров производительности вы захочет скомпилировать PHP из исходного кода. Установка из пакета устанавливает много библиотек, которые вы никогда не сможете использовать. Поскольку среда PHP загружаются в каждый Поток Apache, даже память 5 МБ накладные расходы из дополнительных библиотек быстро становится 250 МБ потерянной памяти, когда есть 50 потоков Apache в существование. Я сохраняю список своих Стандартная. /configure строка, которую я использую, когда создание PHP здесь, и я нахожу его подходит для большинства моих приложений. недостатком является то, что если вы закончите нуждающихся в библиотеке, вы должны перекомпилируйте PHP, чтобы получить его. анализировать ваш код и протестируйте его в devel окружающей среды, чтобы убедиться, что у вас есть все, что вам нужно.

  • Измените свой Javascript.

  • Будьте готовы перемещать статический контент, таких как изображения и видео, нединамический веб-сервер. Написать свой кода, чтобы любые URL-адреса изображений и видео легко настраиваются на другой сервер в будущем. веб-сервер, оптимизированный для статического контент может легко обслуживать десятки или даже в сотни раз быстрее, чем сервер динамического контента.

Это то, что я могу думать о моей голове. Поисковая оптимизация для лучших практик PHP найдет много советов о том, как писать быстрее/лучше код (например: echo быстрее, чем print).

Ответ 2

Во-первых, осознайте, что производительность - это итеративный процесс. Вы не создаете веб-приложение за один проход, не запускаете его и больше не работаете с ним. Напротив, вы начинаете с малого и решаете проблемы производительности, поскольку ваш сайт растет.

Теперь, по спецификациям:

  • Профиль. Определите свои узкие места. Это самый важный шаг. Вам нужно сосредоточить свои усилия, чтобы получить наилучшие результаты. У вас должно быть какое-то решение для мониторинга (например, кактусы или мунины), что дает вам представление о том, что происходит на вашем сервере (ах).
  • Кэш, кеш, кеш. Вероятно, вы обнаружите, что доступ к базе данных является вашим самым большим узким местом на заднем конце, но вы должны убедиться в этом сами. К счастью, вы, вероятно, обнаружите, что большой трафик для небольшого набора ресурсов. Вы можете кэшировать эти ресурсы в чем-то вроде memcached, сохраняя при этом попадание в базу данных и обеспечивая лучшую производительность бэкэнд.
  • Как уже упоминалось выше, ознакомьтесь с правилами производительности YDN. Подумайте о том, чтобы собрать сопроводительную книгу. Это поможет вам с работой переднего конца.
  • Установите PHP APC и убедитесь, что он настроен с достаточной памятью для хранения всего вашего скомпилированного байт-кода PHP. Недавно мы обнаружили, что у нашей установки APC не было почти достаточного количества бара; давая ему достаточно для работы в сокращении нашего процессорного времени пополам, а активность диска на 10%
  • Убедитесь, что таблицы базы данных правильно проиндексированы. Это идет рука об руку с мониторингом медленного журнала запросов.

Вышеупомянутое позволит вам очень далеко. Другими словами, даже довольно дБ-тяжелый сайт должен иметь возможность выжить на главной странице digg на одном сервере с скромным спектром, если вы сделали это.

В конечном итоге вы попадете в точку, где конфигурация apache по умолчанию не всегда сможет идти в ногу с входящими запросами. Когда вы нажмете эту стену, вам нужно сделать две вещи:

  • Как и выше, профиль. Контролируйте свою активность в Apache - вы должны иметь представление о том, сколько подключений активны в любой момент времени, в дополнение к максимальному количеству активных соединений при внезапных всплесках трафика.
  • Настройте apache с учетом этого. Это лучшее руководство по конфигурации apache, которое я видел: Практическая глава mod_perl 11
  • Возьмите как можно больше нагрузки от apache. Apache слишком тяжелый, чтобы эффективно обслуживать статический контент. Вы должны использовать прокси-сервер с более легким весом (например, squid) или веб-сервер (lighttpd или nginx) для обслуживания статического контента и взять на себя выполнение ложных байтов для медленных клиентов. Это позволяет Apache делать то, что он делает лучше всего: выполните свой код. Опять же, книга mod_perl хорошо описывает объяснение этого.

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

Для более глубокого изучения большей части вышесказанного ознакомьтесь с Создание масштабируемых веб-сайтов Cal Henderson от славы Flickr. Google имеет части книги, доступные для предварительного просмотра

Ответ 3

Я использовал MysqlTuner для анализа производительности на моих серверах mysql, и это дало хорошее представление о дальнейших проблемах для googling, поскольку так же как и его собственные рекомендации

Ответ 5

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

См. страницы в Yahoo Developer Network о "Лучшие практики для ускорения вашего веб-сайта" и Инструмент YSlow, чтобы узнать, какая часть загрузки сайта занимает время.

Ответ 6

Не забудьте отключить atime для вашей файловой системы!

Ответ 7

Я бы рекомендовал использовать Jet Profiler для MySQL, чтобы найти любые плохие запросы. Я успешно использовал его на нескольких моих сайтах. Действительно полезно и намного легче переварить, чем медленный журнал запросов.

Ответ 8

Я бы рекомендовал начать с http://highscalability.com/

Что касается ваших предложений:

Сжатие изображений, безусловно, нет. Тип файловой системы настройки, да, это может иметь некоторый эффект, но минимальный. Но на самом деле лучше всего использовать обратный прокси в памяти или даже лучше CDN.

Для Apache в основном загружаются только нужные модули. Не загружайте ничего. Как и в случае с PHP, вы можете использовать forking MPM, важно сохранить его тонким. Что касается оптимальных настроек, вы должны настроить их на конкретное приложение, аппаратное обеспечение и т.д. Если у вас достаточно центрального процессора, рекомендуется использовать mod_deflate. Чем быстрее сервер может отправлять данные клиенту, тем быстрее он может начать обработку следующего запроса.