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

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

80 голосов
/ 11 августа 2009

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

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

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

Ответы [ 6 ]

211 голосов
/ 16 августа 2009

То, что я скажу в этом ответе, не относится к 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!
    • То же самое для наиболее посещаемых страниц вашего сайта, если они не меняются хотя бы в течение пары минут (пример: домашняя страница?) , то нет необходимости тратить ЦП на их повторную генерацию каждый раз, когда пользователь запрашивает их.
  • Возможно, есть разница между страницами, обслуживаемыми анонимными пользователями (одна и та же страница для всех анонимных пользователей) и страницами, обслуживаемыми идентифицированными пользователями ("Здравствуйте, мистер Х, у вас есть новые сообщения", например) ?
    • Если это так, вы, вероятно, можете настроить обратный прокси-сервер для кэширования страницы, которая обслуживается анонимными пользователями (на основе файла cookie, например, файла cookie сеанса)
    • Это будет означать, что с Apache + PHP меньше приходится иметь дело: только с идентифицированными пользователями - которые могут быть только небольшой частью ваших пользователей.

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

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


Как свидетельство: вы говоритев ОП:

Вчера сайт, который я построил с помощью Kohana, был переполнен огромным количеством трафика,

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

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

Об этом, Как я могу обнаружить и выжить, будучи «Слэшдоттом»? может быть интересным чтением.


Со стороны PHP:

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

  • KCachegrind : мой любимый, но работает только на Linux / KDE
  • Wincachegrind для окон; к сожалению, он делает немного меньше, чем KCacheGrind - обычно он не отображает графы вызовов.
  • Webgrind , который работает на веб-сервере PHP, поэтому работает где угодно - но, вероятно, имеет меньше возможностей.

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

KCacheGrind : main screen
(источник: pascal-martin.fr )
KCacheGrind : Callgraph exported as an image
(источник: pascal-martin.fr )

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


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

Вы можете использовать его отдельно XHGui , что поможет визуализировать данные.


На стороне SQL вещей:

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

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

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

Тем не менее, две самые важные вещи:

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


А что теперь?

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

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

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

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


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

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

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

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

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


Заключение

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

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

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

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

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


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

6 голосов
/ 11 августа 2009

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

WebCacheGrind
(источник: jokke.dk )
WinCacheGrind

5 голосов
/ 16 августа 2009

Кохана из коробки очень и очень быстро, за исключением использования объектов базы данных. Процитируем 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 google), чтобы узнать о других советах по повышению производительности.

5 голосов
/ 11 августа 2009

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

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

1 голос
/ 31 декабря 2012

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

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

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

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

0 голосов
/ 12 августа 2009

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

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

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

...