Тактика сайта: вопрос о том, сколько запросов SQL достаточно

Question

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

Я ввел серию кода, который позволяет мне видеть, как быстро генерируется каждая страница и сколько запросов выполняется; в среднем я вижу 9-13, до 12 запросов MySQL, выполняемых на страницу. Среднее время создания страницы составляет где-то 10-20 мс. Теперь, не имея никакого опыта в профессиональном дизайне, к какому оптимальному мне нужно стремиться?

Каковы способы сокращения времени генерации (или, в среднем, 15 мс / стр., Это даже не проблема), или тактики по уменьшению количества запросов на странице, где большая часть контента загружается из база данных MySQL, включая такие элементы, как пункты меню.

Имейте в виду, это очень широкий вопрос; я не намерен задавать общий вопрос или разжигать разговор, а выяснить способы уменьшения нагрузки (если таковая имеется) на сервере, который может создать такая система.

Answer 1

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

• Включение MySQL кеша запросов обычно (хотя и не всегда) хорошая идея.

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

• Используйте профилировщик , например, встроенный в XDebug . Вместе с таким интерпретатором, как KCacheGrind или WinCacheGrind, оптимизация кода действительно помогает, когда вы знаете, на чем сосредоточиться. Не стоит оптимизировать то, что вносит незначительный вклад в общее время выполнения. Стоит узнать, что все в * CacheGrind означает.

Моя система управления контентом PHP обычно загружает страницу примерно за одно и то же время (до минимум 8 мс, когда все попадает в кэш). Но очень редко, когда вы делаете что-то сложное, это может занять более 500 мс. Когда речь идет об опыте пользователя, типичное время является более важным, не столько выбросы, но когда дело касается загрузки сервера, среднее время более важно, поэтому эти 500 мс внезапно становятся очень важными.

Answer 2

Это зависит ... как это всегда происходит с вопросами производительности, если система в настоящее время отвечает вашим требованиям к производительности, то не стоит слишком беспокоиться.

Обычно, если время генерации вашей страницы составляет 15 мс, это будет лишь малая доля от общего времени клика на стекле, которое испытывает пользователь, см. Страницы производительности исключений yahoo Там будут и другие вещи, на которые следует обратить внимание чтобы получить максимально быстрое время загрузки страницы.

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

Answer 3

Если вы в основном разрабатываете эти сайты для небольших компаний или по другим причинам, когда вы не прогнозируете или не представляете большой трафик (т. Е. Ничего похожего на Digg / Facebook / и т. Д.), Тогда в среднем должно быть 15 мс.

Могу я спросить, для чего нужны 12 запросов? Я предполагаю, что они предназначены для получения пунктов меню, получения содержимого страницы и тому подобного. Существуют различные методы объединения / оптимизации запросов, поэтому, если вы, возможно, опубликуете несколько I (и других накопителей), возможно, сможете помочь вам оптимизировать ваши запросы.