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

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

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

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

Author: Sampson, 2009-08-11
Source

6 answers

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

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


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

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


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

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

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

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

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


В качестве примечания: вы говорите в ОП:

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

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

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

Об этом, Как я могу обнаружить и выжить, будучи "срезанным"? может быть, это будет интересное чтение.


С точки зрения PHP:

Прежде всего: используете ли вы последнюю версию PHP? Регулярно улучшается скорость, появляются новые версии;-)
Например, взгляните на Бенчмарк ветвей PHP с 3.0 по 5.3-CVS.

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

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

  • Я думаю о APC - альтернативном кэше PHP, например ( пекл, руководство), какое решение, как я видел, использовалось чаще всего -- и это используется на всех серверах, на которых я работал.
  • Это действительно может значительно снизить загрузку процессора сервера, в некоторых случаях (Я видел, что загрузка процессора на некоторых серверах увеличивается с 80% до 40%, просто установив APC и активировав его кэш-код операции функциональность!)
  • В принципе, выполнение PHP-скрипта выполняется в два этапа:
    • Компиляция исходного кода PHP в коды операций (своего рода эквивалент байт-кода JAVA)
    • Выполнение этих кодов операций
    • APC хранит их в памяти, поэтому при каждом выполнении PHP-скрипта/файла требуется меньше работы: только извлекайте коды операций из оперативной памяти и выполняйте их.
  • Возможно, вам придется взглянуть на APC параметры конфигурации, кстати
    • их довольно много, и некоторые из них могут оказать большое влияние как на скорость/загрузку процессора, так и на простоту использования для вас
    • Например, отключение [apc.stat](http://php.net/manual/en/apc.configuration.php#ini.apc.stat) может быть полезно для загрузки системы; но это означает, что изменения, внесенные в файлы PHP, не будут учитываться, если вы не очистите весь кэш кода операции; об этом, для получения более подробной информации, см., например, Для stat() Или Не для статистика()?


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

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

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

Вам может быть очень интересно определить:

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

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

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

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

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


Профилирование

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

Правильно настроенный, он будет генерировать файлы профилирования, которые можно анализировать с помощью некоторых графических инструментов, таких как:

  • программа: мой любимый, но это работает только на Linux/КДЕ
  • Винкачегринд для Windows; к сожалению, он делает немного меньше, чем KCachegrind, - он не отображается как правило, графики вызовов.
  • Веб-Грайнд который работает на веб-сервере PHP, поэтому работает где угодно, но, вероятно, имеет меньше функций.

Например, вот пара скриншотов KCachegrind:

KCachegrind: главный экран http://extern.pascal-martin.fr/so/kcachegrind/kcachegrind-1-small.png KCachegrind: График вызовов, экспортированный в виде изображения http://extern.pascal-martin.fr/so/kcachegrind/kcachegrind-2-small.png

( Кстати, график вызовов, представленный на втором снимке экрана, обычно не может сделать ни WinCacheGrind, ни Webgrind, если я правильно помню ^^ )


( Спасибо @Mikushi за комментарий) Еще одна возможность, которую я не часто использовал, - это xhпроф расширение: оно также помогает в профилировании, может генерировать графики вызовов, но легче, чем Xdebug, это означает, что вы должны иметь возможность установить его на рабочий сервер.

Вы должны быть в состоянии использовать его самостоятельно Ххгуй, что поможет в визуализации данных.


С точки зрения SQL:

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

По крайней мере, две или три вещи, здесь:

  • Вы должны определять:
    • Какие наиболее частые запросы выполняет ваше приложение
    • Оптимизированы ли они (в основном с использованием правильных индексов ?), используя EXPLAIN инструкция, если вы используете MySQL
    • можете ли вы кэшировать некоторые из этих запросов (см., что я сказал ранее)
  • Хорошо ли настроен ваш MySQL? Я мало что знаю об этом, но есть некоторые параметры конфигурации, которые могут оказать некоторое влияние.

Тем не менее, две самые важные вещи являются:

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


И что теперь?

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

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

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

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


А как насчет Коханы?

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

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

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

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


Заключение?

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

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

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

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

Например, вы могли бы использовать что-то вроде Инструмент RRDTool + кактусы.
И показывать своему боссу красивую графику с 40%-ным снижением загрузки процессора всегда здорово ;-)


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

 211
Author: Pascal MARTIN, 2017-05-23 11:54:15

Используйте xdebug и WinCacheGrind или webcachegrind для профилирования и анализа медленного выполнения кода.

Веб-интерфейс http://jokke.dk/media/2008-webgrind/webgrind_small.png WinCacheGrind

 6
Author: Alix Axel, 2017-02-08 14:12:42

Код профиля с xdebug.

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

 5
Author: Kornel, 2009-08-11 12:55:32

Кохана выходит из коробки очень и очень быстро, за исключением использования объектов базы данных. Цитируя Зомбора: "Вы можете уменьшить использование памяти, убедившись, что используете объект результата базы данных вместо массивов результатов". Это приводит к ОГРОМНОЙ разнице в производительности на сайте, который захлопывается. Он не только использует больше памяти, но и замедляет выполнение сценариев.

Также - вы должны использовать кэширование. Я предпочитаю 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
Author: ae., 2009-08-16 12:16:34

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

В производственном режиме:

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

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

 1
Author: Tamás Pap, 2012-12-31 00:04:14

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

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

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

 0
Author: Ozten, 2009-08-11 23:52:55