Рекомендации по оптимизации узлов LAMP для скорости?

Question

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

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

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

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

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

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

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

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

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

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

Answer 1

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

• Установка mod_deflate для апача, и не использовать обработчики GZIP РНР. mod_deflate позволит вам компресс статического контента, как JavaScript/CSS/статический HTML, а также как обычный динамический выход PHP и это одна вещь меньше вам не придется беспокоиться о в вашем коде.

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

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

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

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

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

• Минимизировать Javascript.

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

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

ресурс может оказаться полезной является YDN set of performance rules.

Answer 5

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

Просмотрите на странице Yahoo Developer Network о Best Practices for Speeding Up Your Web Site и YSlow tool, чтобы узнать, какая часть загрузки сайта занимает много времени.

Answer 6

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

Answer 7

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

Теперь, на специфику:

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

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

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

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

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

Для более глубокого ознакомления с большей частью вышесказанного ознакомьтесь с Building Scalable Web Sites от Cal Henderson от славы Flickr. Google имеет portions of the book available for preview

Answer 8

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