каков ожидаемый предел приемлемой производительности wordpress без каких-либо настроек?

<p>по вашему опыту, когда нужно начинать думать о расширении?</p><p><strong> какова ожидаемая производительность обычной установки wordpress на стандартном веб-сервере apache без каких-либо [настроек производительности или плагинов] </strong> ( <a href="https://wordpress.stackexchange.com/questions/199/what-steps-can-i-take-to-optimize-wordpress-in-regard-to-server-load">шаги для оптимизации wordpress в отношении загрузки сервера?</a> )?</p><p>с точки зрения загрузки страниц (давайте предположим, что нет кэширования): <strong> находится ли он в диапазоне 100/1000-х/+ загрузок страницы в секунду? </strong></p><p>с точки зрения трафика: <strong> при каком количестве пользователей в день можно ожидать попадания в узкие места производительности (игнорируя трафик, предполагая отличное соединение)? </strong></p>

<p>многое из этого очень субъективно и трудно ответить из-за различных серверных сред, тем, размера базы данных и т.д.</p><blockquote>по вашему опыту, когда нужно начинать думать о расширении?</blockquote><p>если вы беспокоитесь о своем опыте работы с пользователями, вы уже должны практиковать <a href="http://stevesouders.com/hpws/">качественные методы работы с внешним интерфейсом</a> . когда пришло время расширяться? когда ваши пользователи начинают ухудшаться, а медленные загрузки страниц приводят к увеличению показателя отказов.</p><blockquote>какова ожидаемая производительность обычной установки wordpress на стандартном веб-сервере apache без каких-либо настроек производительности или плагинов?</blockquote><p>обычная установка wordpress, запускающая тему по умолчанию для небольшого и среднего блога на одном из рекомендуемых общих хостов, должна без проблем обрабатывать сотни пользователей в день.</p><blockquote>с точки зрения загрузки страниц (предположим, нет кэширования): находится ли он в диапазоне от 100 до 1000 загрузок страниц в секунду?</blockquote><p>для этого вопроса я запустил apache benchmark на установке wordpress с темой 2010 по умолчанию без кэширования.</p><p><img src="https://i.stack.imgur.com/vmkhk.jpg" alt="alt text"></p><p>я сделал 500 запросов со скоростью 10 запросов в секунду и смог составить в среднем 3,6 запроса в секунду, но, поскольку запросы начали накапливаться, самый длинный запрос занял почти 2 минуты.</p><blockquote>с точки зрения трафика: при каком количестве пользователей в день можно ожидать попадания в узкие места производительности (игнорируя трафик, предполагая отличное соединение)?</blockquote><p>на этот вопрос невозможно ответить без запуска нагрузочных тестов или тестов на сервере. для приведенного выше теста у вас могут возникнуть узкие места в любое время, когда сайт используют более 10 пользователей одновременно.</p>

<p>марек, твой вопрос очень субъективен и поэтому не может быть правильно дан ответ. вы должны предоставить правильно определенный контекст, определение терминов и значений, и так далее, чтобы это было близко. что-то наверняка здесь невозможно. если вы не сделаете, ответ очень прост:</p><p>это зависит.</p><p>например, если ваш сайт чувствует себя медленно после пустой настройки и требует около 30 секунд, чтобы ответить, я без сомнения могу сказать, что пришло время подумать о расширении.</p><p>эмпирическое правило может заключаться в том, что ваш жизненный сайт должен отвечать менее чем на x времени (например, 10-й секунды) на любой запрос, находясь под нагрузкой. если нет, начните думать о расширении. установите время для ваших нужд, затем следите за своим сайтом и, если он работает по линии, начните думать о расширении. с сайтами это всегда зависит, поэтому вам нужно измерить это.</p>

<p>это также зависит от установленных плагинов и т.д.</p><p>сейчас я работаю над установкой на несколько сайтов, на которой установлено более 60 плагинов.</p><p>на сервере amazon ec2, m2-xlarge, его пиковая скорость составляет 25 php запросов в секунду (проверяется нагрузкой с помощью httperf, выполняется только обращение к urlphp \_, а не к изображениям и т.д.) максимальный процесс php-fpm.</p><p>там много возможностей для улучшения.</p>