Оптимизация веб-сайтов на основе Kohana для скорости и масштабируемости

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

меня также интересует бенчмаркинг. Мне нужно настроить Benchmark::start() и Benchmark::stop() для каждого метода контроллера, чтобы увидеть время выполнения для всех страниц, или я могу применить бенчмаркинг глобально и быстро?

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

80
kohana optimization performance php scalability

6 ответов

то, что я скажу в этом ответе, не относится к Kohana и, вероятно, может применяться ко многим проектам PHP.

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


Прежде всего, когда дело доходит до выступлений, есть много аспекты / вопросы, которые следует рассмотреть:

  • настройки сервера (и Apache, PHP, MySQL, другие возможные демоны и система); вы можете получить больше помощи о том, что на ServerFault, Я полагаю,
  • PHP-кода
  • запросы к базе данных,
  • использование или нет вашего веб-сервера?
  • можете ли вы использовать какой-либо механизм кэширования? Или вам всегда нужно больше, что в курсе данные на сайте?


использование обратного прокси

первое, что может быть действительно полезно, это использовать обратного прокси-сервера, как лак, перед вашим веб-сервер: да кэш столько вещей, сколько возможно, поэтому только запросы, которые действительно нуждаются в вычислениях PHP/MySQL (и, конечно же, некоторые другие запросы, когда их нет в кэше прокси) сделать это для Apache / PHP / MySQL.

  • прежде всего, ваш CSS / Javascript / Images -- ну, все, что статично -- вероятно, не нужно всегда обслуживаться Apache
    • таким образом, вы можете иметь обратный прокси-кэш все это.
    • обслуживание этих статических файлов не имеет большого значения для Apache, но чем меньше он должен работать для них, тем больше он сможет сделать с PHP.
    • помните: Apache может только сервер конечное, ограниченное, количество запросы за один раз.
  • тогда пусть обратный прокси-сервер обслуживает как можно больше PHP-страниц из кэша: вероятно, есть некоторые страницы, которые не меняются так часто и может быть обслужен из кэша. Вместо того, чтобы использовать некоторый PHP-кэш, почему бы не позволить другому, более легкому серверу обслуживать эти (и время от времени извлекайте их с сервера PHP, поэтому они всегда почти актуальны)?
    • например, если у вас есть RSS для (мы вообще склонны забывать те, при попытке оптимизировать для выступлений) по просьбе очень часто, имея их в кэше в течение нескольких минут, можно сохранить сотни / тысячи запросов к Apache + PHP + MySQL!
    • то же самое для самых посещаемых страниц вашего сайта, если они не меняются в течение хотя бы пары минут (пример: Домашняя страница?), то нет необходимости тратить CPU повторно генерировать их каждый раз, когда пользователь запрашивает их.
  • может быть, есть разница между страниц для анонимных пользователей (одна и та же страница для всех анонимных пользователей) и страницы, предназначенные для идентифицированных пользователей ("Здравствуйте, мистер Икс, у вас новые сообщения", например)?
    • если это так, вы, вероятно, можете настроить обратный прокси-сервер для кэширования страницы, которая обслуживается для анонимных пользователей (на основе cookie, например, cookie сеанса, как правило)
    • это будет означать, что Apache+PHP имеет меньше проблем: только идентифицированные пользователи , которые могут быть только небольшой частью ваших пользователей.

о использование обратного прокси-сервера в качестве кэш -, для приложения PHP, вы можете, например, взглянуть на результаты тестов показывают 400% -700% увеличение возможностей сервера с APC и Squid Cache.
(Да, они используют Squid, и Я говорил о лаке - это просто еще одна возможность ^^ лак быть более недавним, но более посвященным кэшированию)

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


Как sidenote: вы говорят в ОП:

сайт я создал с Кохана окатили огромное количество трафика вчера,

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

  • установите его, настройте его, пусть он всегда -- каждый нормальный день... выполнить:
    • настроить его, чтобы не держать PHP страницы в кэше; или только на короткий срок; таким образом, у вас всегда есть актуальные данные, отображаемые
  • и, в день, когда вы принимаете эффект slashdot или digg:
    • настройте обратный прокси-сервер для хранения страниц PHP в кэше; или в течение более длительного периода времени; возможно, ваши страницы не будут обновлены на секунду, но это позволит вашему сайту пережить digg-эффект!

об этом как я могу обнаружить и выжить "Slashdotted"? может быть интересное чтение.


на стороне PHP вещей:

прежде всего: вы используете последняя версия PHP? Есть регулярно улучшения в скорости, с новыми версиями ;-)
например, посмотри бенчмарк филиалов PHP 3.0 через 5.3-CVS.

обратите внимание, что выступления-довольно хорошая причина для использования PHP 5.3 (я сделал несколько тестов (на французском языке), и результаты отличные)...
еще одна довольно веская причина, конечно, что PHP 5.2 достиг своего конца жизни и больше не поддерживается!

вы используете какой-либо кэш кода операции?

  • я думал о APC-альтернативный PHP кэш, например (по PECL, руководство), который является решение, которое я видел, используется больше всего-и это используется на всех серверах, на которых я работал.
  • это может действительно снизить нагрузку на процессор сервера много, в некоторых случаях (Я видел, что загрузка процессора на некоторых серверах идет от 80% до 40%, просто установив APC и активировав его функциональность opcode-cache!)
  • в основном, выполнение скрипта PHP происходит в два этапа:
    • компиляция исходного кода PHP в opcodes (своего рода эквивалент байт-кода JAVA)
    • выполнение этих кодов операций
    • APC сохраняет их в памяти, поэтому при каждом выполнении PHP-скрипта / файла требуется меньше работы: только извлекать коды операций из ОЗУ и выполнять их.
  • возможно, вам придется взглянуть на БТР!--213-->параметры конфигурации, кстати
    • их довольно много, и некоторые из них могут оказать большое влияние на скорость / загрузку процессора / простоту использования для вас
    • например, отключение [apc.stat](http://php.net/manual/en/apc.configuration.php#ini.apc.stat) может быть хорошо для загрузки системы; но это означает, что изменения, внесенные в файлы PHP, не будут учитываться, если вы не очистите весь кэш кода операции; об этом, для более подробности, см., например,stat () или не stat ()?


использование кэша для данных

насколько это возможно, лучше не делать то же самое снова и снова.

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

Это может быть очень интересно для вас, чтобы определить:

  • какие запросы выполняются много раз, всегда возвращаются одни и те же данные
  • какие другие (тяжелый) вычисления выполняются много времени, всегда возвращая один и тот же результат

и хранить эти данные/результаты в каком-то кэше, поэтому их легче сделать -- быстрее -- и вам не нужно идти на свой SQL server для "ничего".

большие механизмы кэширования, например:

  • APC: в дополнение к кэш-коду, о котором я говорил ранее, он позволяет хранить данные в памяти,
  • и/или memcached (см. также), что очень полезно, если вы буквально много данных и/или использование нескольких серверов, так как он распространяется.
  • конечно, вы можете думать о файлах; и, вероятно, многие другие идеи.

Я уверен, что ваш фреймворк поставляется с некоторыми связанными с кэшем вещами; вы, вероятно, уже знаете это, как вы сказали "Я буду использовать Кэш-библиотека больше во времени, чтобы прийти" в ОП ;-)


профилирования

Теперь неплохо было бы использовать отладчик xdebug

  • не переходите в БД, если вам не нужно:кэш столько, сколько вы можете!
  • когда вам нужно перейти в БД, используйте эффективные запросы: используйте индексы; и профиль!


и что теперь?

Если вы все еще читаете, что еще можно оптимизировать?

Ну, есть еще место для улучшений... Пара архитектурно-ориентированных идей может быть:

  • переключиться на N-уровневую архитектуру:
    • поместите MySQL на другой сервер (2 уровня: один для PHP, другой для MySQL)
    • используйте несколько PHP серверов (и нагрузка-баланс пользователей между ними)
    • используйте другие машины для статических файлов, с более легким веб-сервером, например:
      • lighttpd
      • или nginx и -- этот становится все больше и больше более популярный, кстати.
    • используйте несколько серверов для MySQL, несколько серверов для PHP и несколько обратных прокси перед этими
    • конечно: установить memcached демоны на любом сервере имеют любое количество свободной оперативной памяти и используют их для кэширования столько, сколько вы можете / имеет смысл.
  • использовать что-то" более эффективное", что Apache?

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


а как же Кохана?

ваш первоначальный вопрос был об оптимизации приложения, которое использует Кохана... Ну, я опубликовал некоторые идеи, которые верны для любого приложения PHP... Что означает, что они верны для Кохана тоже ;-)
(даже если это не специфично для него ^^)

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

Я также сказал, что вы не должны делать ничего, что не является необходимым; есть ли что-то включено по умолчанию в Kohana, что вам не нужно?
просмотр сети, кажется, есть на хотя бы что-то о фильтрации XSS; вам это нужно?

тем не менее, вот несколько ссылок, которые могут быть полезны:


вывод?

и, в заключение, простая мысль:

  • сколько это будет стоимость вашей компании, чтобы заплатить вам за 5 дней? -- учитывая, что это разумное количество времени, чтобы сделать некоторые большие оптимизаций
  • сколько будет стоить ваша компания, чтобы купить (оплачивать?) второй сервер и его обслуживание?
  • что делать, если вам нужно масштабировать больше?
    • сколько будет стоить потратить 10 дней? еще? оптимизация всех возможных бит вашего приложения?
    • и сколько стоит еще пара серверы?

Я не говорю, что вы не должны оптимизировать: вы, безусловно, должны!
но перейти на" быстрые " оптимизации, которые получат вам большие награды во-первых: использование некоторого кэша кодов операций может помочь вам получить от 10 до 50 процентов от загрузки процессора вашего сервера... И это займет всего пару минут, чтобы настроить ;-) с другой стороны, потратив 3 дня на 2 процента...

О, и кстати: прежде чем что-то делать: положите некоторый контроль вещи на месте, так что вы знаете, какие улучшения были сделаны, и как!
без мониторинга, вы не будете иметь никакого представления о влиянии того, что вы сделали... Даже если это настоящая оптимизация или нет!

например, вы можете использовать что-то вроде RRDtool + кактусы.
и показывая вашему боссу некоторые хорошие графики с 40% CPU-падение нагрузки всегда здорово ; -)


Во всяком случае, и действительно вывод:удачи!
(да, оптимизация-это удовольствие!)
(Ergh, я не думал, что буду писать так много... Надеюсь, по крайней мере, некоторые части этого полезны... И я должен помнить этот ответ: может быть, пригодится в другой раз...)

211

использовать отладчик xdebug и WinCacheGrind или WebCacheGrind профилировать и анализировать медленное выполнение кода.

WebCacheGrind http://jokke.dk/media/2008-webgrind/webgrind_small.png WinCacheGrind

6

код профиля с отладчик xdebug.

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

5

в Kohana из коробки очень быстро, за исключением использования объектов базы данных. Цитата Zombor " вы можете уменьшить использование памяти, гарантируя, что вы используете объект результата базы данных вместо результирующих массивов."Это делает разницу в производительности HUGEE на сайте, который захлопывается. Он не только использует больше памяти, но и замедляет выполнение скриптов.

также необходимо использовать кэширование. Я предпочитаю memcache и использую его в своих моделях следующим образом:

public function get($e_id)
{
    $event_data = $this->cache->get('event_get_'.$e_id.Kohana::config('config.site_domain'));

    if ($event_data === NULL)
    {
        $this->db_slave
            ->select('e_id,e_name')
            ->from('Events')
            ->where('e_id', $e_id);

        $result = $this->db_slave->get();
        $event_data = ($result->count() ==1)? $result->current() : FALSE;

        $this->cache->set('event_get_'.$e_id.Kohana::config('config.site_domain'), $event_data, NULL, 300); // 5 minutes
    }

    return $event_data;
}

Это также значительно повысить производительность. Вышеуказанные два метода улучшили производительность сайтов на 80%.

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

также проверьте yslow (google it) для некоторых других советов по производительности.

5

строго связано с Кохана (вы, вероятно, уже сделали это, или нет):

в рабочем режиме:

  1. включить внутреннее кэширование (это будет кэшировать только результаты Kohana::find_file, но это действительно может помочь.
  2. отключить профайлер

только мои 2 цента:)

1

Я полностью согласен с ответами XDebug и кэширования. Не смотрите в слой Kohana для оптимизации, пока вы не определили свои самые большие узкие места скорости и масштаба.

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

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

0