Я хочу знать, когда вы строите типичный сайт в стеке LAMP, как вы оптимизируете его для наилучшего времени загрузки. Я представляю типичный сайт, управляемый БД.
Это высокоуровневый вид и, вероятно, может затронуть вопрос и позволить мне разбить его на каждый уровень стека.
L – На системном уровне (настройка и файловая система) вы можете улучшить скорость? Одна вещь, о которой я могу думать, это размеры изображений, может ли сжатие здесь помочь оптимизировать что-нибудь?
A – На веб-сервере должна быть тонна настроек, связанных с скоростью сайта. Не моя Форте. Вероятно, многое зависит от того, сколько сайтов работает одновременно.
M – MySQL на сайте, управляемом базой данных, является ключевым фактором эффективности БД. Есть ли лучший подход к нормализации, т. Е. Использование таблиц ссылок? Веб-разработчики часто просто делают простые монолитные таблицы похожими на 1NF, и это может убить производительность.
P – помимо настроек повышения производительности, таких как кеширование, что может сделать программист, чтобы повлиять на производительность на высоком уровне? Мне бы очень хотелось узнать, приближается ли проект MVC к производительности быстрее, чем быстро и грязно. Другие простые советы, такие как сеансы быстрее, чем файлы cookie, будут интересны.
Очевидно, что вам нужно спуститься и засориться в деталях и найти, какой код замедляет вас. Также я понимаю, что многие сайты имеют много разных характеристик производительности, но давайте предположим, что типичный сайт, который больше читает, затем пишет.
Мне просто интересно, можем ли мы собрать кучу лучших практик и в полной мере ожидать, что люди свяжут другие вопросы, чтобы мы могли эффективно обрабатывать контрольный список.
Моя цель состоит в том, чтобы увидеть, даже если в дополнение к обычным проблемам производительности мы можем видеть некоторые вещи, которые вы, возможно, не придумали, чтобы справиться с обзором лучших практик.
Итак, мой вопрос: если вы начинаете с нуля, как бы вы гарантировали, что ваш сайт LAMP будет быстрым?
Вот несколько личных 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 для ее получения. Проанализируйте свой код и протестируйте его в среде разработки, чтобы убедиться, что у вас есть все, что вам нужно.
Минимизируйте свой Javascript.
Будьте готовы перемещать статический контент, такой как изображения и видео, на нединамический веб-сервер. Напишите свой код, чтобы любые URL-адреса для изображений и видео были легко настроены для указания на другой сервер в будущем. Веб-сервер, оптимизированный для статического контента, может легко обслуживать десятки или даже сотни раз быстрее, чем сервер динамического контента.
Это то, что я могу придумать с головы. Поисковая оптимизация для лучших практик PHP найдет множество советов о том, как писать быстрее / лучше код (например: echo быстрее, чем print ).
Во-первых, осознайте, что производительность – это итеративный процесс. Вы не создаете веб-приложение за один проход, не запускаете его и больше не работаете с ним. Напротив, вы начинаете с малого и решаете проблемы производительности по мере роста вашего сайта.
Теперь о специфике:
Вышеизложенное вы получите очень далеко. Другими словами, даже довольно дБ-тяжелый сайт должен иметь возможность выжить на главной странице digg на одном сервере с скромным спектром, если вы сделали это.
Вы, в конце концов, попадете в точку, где конфигурация apache по умолчанию не всегда сможет идти в ногу с входящими запросами. Когда вы нажмете эту стену, вам нужно сделать две вещи:
Как только вы достигли этого, это в значительной степени проблема кэширования и отслеживания вашей базы данных. В конце концов, вы перерастуте один сервер. Во-первых, вы, вероятно, добавите больше интерфейсных ящиков, все подкрепленные одним сервером базы данных. Тогда вам придется начать распространять нагрузку на базу данных, возможно, путем осколки. Для отличного обзора этого процесса роста см. Презентацию livejournal
Для более глубокого ознакомления с большей частью вышесказанного посетите веб-сайты Building Scalable , Cal Henderson, о славе Flickr. В Google есть части книги, доступные для предварительного просмотра
Я использовал MysqlTuner для анализа производительности на моих серверах mysql, и это дало хорошее представление о дальнейших проблемах для googling, а также разработало собственные рекомендации
Ресурсом, который может оказаться полезным, является набор правил производительности YDN .
Не забывайте, что ваши пользователи будут находиться за тысячи километров от вашего сервера и загружать десятки файлов для создания одной страницы. Эта латентность и накладные расходы на отображение страницы в их браузерах могут быть больше, чем время, затрачиваемое на сбор информации, и создание страницы.
См. Страницы в «Сети разработчиков Yahoo» о наилучших методах ускорения вашего веб-сайта и инструмент YSlow для просмотра того, какая часть загрузки сайта занимает много времени.
Не забудьте отключить atime для вашей файловой системы!
Я бы рекомендовал использовать Jet Profiler для MySQL, чтобы найти любые плохие запросы. Я успешно использовал его на нескольких моих сайтах. Действительно полезно, и намного легче переварить, чем медленный журнал запросов.
Я рекомендую начинать с http://highscalability.com/
Что касается ваших предложений:
Сжатие изображений, безусловно, нет. Тип файловой системы настройки, да, это может иметь некоторый эффект, но минимальный. Но на самом деле лучше всего использовать обратный прокси в памяти или даже лучше CDN.
Для Apache в основном загружаются только нужные модули. Не загружайте ничего. Как и в случае с PHP, вы можете использовать forking MPM, важно сохранить его тонким. Что касается оптимальных настроек, то вы должны точно настроить их на конкретное приложение, аппаратное обеспечение и т. Д. Если у вас достаточно центрального процессора, рекомендуется использовать mod_deflate. Чем быстрее сервер может отправлять данные клиенту, тем быстрее он может начать обработку следующего запроса.