Оптимизация находящихся в Kohana веб-сайтов для скорости и масштабируемости
По той же причине Вы не можете сказать
5++;
или
f(i)++;
, функция А возвращается значение , не переменная. Инкрементные операторы также возвращаемые значения, но не может быть применен к значениям.
5 ответов
То, что я скажу в этом ответе, не относится к Kohana и, вероятно, может применяться ко многим проектам PHP.
Вот некоторые моменты, которые приходят мне на ум, когда я говорю о производительности, масштабируемость, PHP, ...
Я использовал многие из этих идей при работе над несколькими проектами - и они помогли; так что они, вероятно, могли бы помочь и здесь.
Прежде всего, когда дело доходит до производительности, есть множество аспектов / вопросов, которые необходимо учитывать :
- конфигурация сервера (оба Apache, PHP, MySQL, другие возможные демоны и система) ; вы можете получить дополнительную информацию об этом на ServerFault , я полагаю,
- PHP-код,
- Запросы к базе данных,
- Используете или нет ваш веб-сервер?
- Можете ли вы использовать какой-либо вид кеширования механизм? Или вам всегда нужно больше обновленных данных на веб-сайте?
Использование обратного прокси
Первое, что может быть действительно полезно, - это использование обратного прокси , например varnish перед вашим веб-сервером:
- Итак, у вас может быть кэш обратного прокси-сервера.
- Обслуживание этих статических файлов не представляет большого труда для Apache, но чем меньше он должен работать с ними, тем больше он сможет делать с PHP.
- Помните: Apache может одновременно обслуживать только ограниченное, ограниченное количество запросов.
- Например, если у вас есть RSS-каналы (мы обычно забываем о них, пытаясь оптимизировать производительность) , которые запрашиваются очень часто , имея их в кеше для пара минут может сэкономить сотни / тысячи запросов к Apache + PHP + MySQL!
- То же самое для наиболее посещаемых страниц вашего сайта, если они не меняются хотя бы пару минут (пример: домашняя страница?) , тогда нет необходимости тратить ресурсы процессора на их повторное создание каждый раз, когда пользователь запрашивает их.
- Если это так, вы, вероятно, можете настроить обратный прокси-сервер для кэширования страницы, обслуживаемой анонимными пользователями (на основе файла cookie, например, файла cookie сеанса, как правило)
- Это будет означать, что Apache + PHP имеет меньшее значение: только идентифицированные пользователи, которые могут составлять лишь небольшую часть ваших пользователей.
О использовании обратного прокси-сервера в качестве кеша для приложения PHP вы можете, например, , взгляните на Результаты тестов показывают увеличение возможностей сервера на 400–700% с APC и Squid Cache .
(Да, они используют Squid, и я говорил о лаке - это просто еще одна возможность ^^ Varnish является более свежим, но в большей степени предназначен для кеширования)
Если вы сделаете это достаточно хорошо и сумеете прекратить повторное создание слишком большого количества страниц снова и снова, возможно, вам даже не придется оптимизировать какой-либо код ;-)
По крайней мере, может быть, не в спешке ... И всегда лучше выполнять оптимизацию, когда вы не находитесь под слишком большим давлением ...
В качестве примечания: вы говорите в OP:
Сайт, который я создал с помощью Kohana, был подвергнут критике огромный объем трафика вчера,
Это такая внезапная ситуация, когда обратный прокси-сервер может буквально спасти положение , если ваш веб-сайт может справиться с необновлением каждую секунду:
- установите, настройте, пусть всегда - каждый нормальный день - запускает:
- Настройте его так, чтобы страницы PHP не оставались в кеше; или только на короткий срок; таким образом вы всегда будете отображать актуальные данные
- И в день, когда вы воспользуетесь эффектом косой черты или digg:
- Настройте обратный прокси-сервер для хранения страниц PHP в кеше; или на более длительный период времени; может быть, ваши страницы не будут обновляться каждую секунду, но это позволит вашему сайту пережить эффект digg!
Об этом, Как я могу обнаружить и выжить, будучи «помеченным косой чертой»? мог бы
Что касается PHP:
Прежде всего: вы используете последнюю версию PHP ? Регулярно улучшается скорость, с новыми версиями ;-)
Например, взгляните на Бенчмарк ветвей PHP с 3.0 по 5.3-CVS .
Обратите внимание, что производительность - вполне веская причина для использования PHP 5.3 ( I ' Я сделал несколько тестов (на французском языке) , и результаты отличные) ...
Еще одна довольно веская причина, разумеется, в том, что PHP 5.2 подошел к концу и больше не поддерживается!
Используете ли вы какой-либо кеш опкодов?
- Я думаю о APC - Альтернативный кеш PHP , например ( pecl , руководство ) , это решение, которое я видел чаще всего - и это используется на всех серверах, на которых я работал.
- Это действительно может значительно снизить загрузку ЦП сервера, в некоторых случаях (я видел, как загрузка ЦП на некоторых серверах упала с 80% до 40%, просто установив APC и активировав его функцию кеширования кодов операций!)
- Обычно выполнение PHP-скрипта состоит из двух этапов:
- Компиляция исходного кода PHP в коды операций (что-то вроде эквивалента байт-кода JAVA)
- Выполнение этих кодов операций
- APC сохраняет их в памяти, поэтому каждый раз приходится выполнять меньше работы выполняется сценарий / файл PHP: только извлекает коды операций из ОЗУ и выполняет их.
- Возможно, вам потребуется взглянуть на параметры конфигурации APC , кстати
- их довольно много, и некоторые из них могут сильно повлиять на скорость / загрузку процессора / простоту использования для вас
- Например, отключение
[apc.stat] (https: / /php.net/manual/en/apc.configuration.php#ini.apc.stat)может подойти для загрузки системы; но это означает, что изменения, внесенные в файлы PHP, не будут приняты во внимание, если вы не очистите весь кеш-код операций; об этом подробнее см., например, To stat () or Not To stat ()?
Использование кеша для данных
Насколько это возможно, лучше избегать того же снова и снова .
Главное, о чем я думаю, это, конечно, SQL-запросы: многие из ваших страниц, вероятно, выполняют одни и те же запросы, и результаты некоторых из них, вероятно, почти всегда то же самое ... Что означает множество "бесполезных"
что очень полезно, если у вас буквально есть много данных и / или вы используете несколько серверов , поскольку они распределены.
Я почти уверен, что в вашей структуре есть кое-что, связанное с кешем; вы, вероятно, уже знаете, что, как вы сказали «Я буду использовать Cache-библиотеку в будущем» в OP; -) Теперь, приятное занятие было бы использовать расширение Xdebug для профиля вашего приложения : это часто позволяет довольно легко найти пару слабых мест - по крайней мере, если есть какая-либо функция, которая требует много времени. При правильной настройке он будет генерировать файлы профилирования, которые можно анализировать с помощью некоторых графических инструментов, таких как: Для Например, вот пара скриншотов KCacheGrind: ( Кстати, граф вызовов, представленный на втором снимке экрана, обычно не может сделать ни WinCacheGrind, ни Webgrind, если я правильно помню ^^) Тем не менее, два наиболее важных момента: Если вы все еще читаете, что еще можно оптимизировать? Что ж, есть еще возможности для улучшений ... Вот пара архитектурно-ориентированных идей: Что ж, может быть, некоторые из этих идей немного излишни в вашей ситуации ^^
Ваш первоначальный вопрос был об оптимизации приложения, использующего Kohana ... Ну, я опубликовал несколько идей, которые верны для любого приложения PHP . .. Значит, они верны и для Коханы ;-)
Я сказал: используйте кеш; Kohana, кажется, поддерживает некоторые кеширующие штуки (Вы сами об этом говорили, так что здесь ничего нового ...)
Я также сказал, что вы не должны делать ничего лишнего; есть ли в Kohana по умолчанию что-то, что вам не нужно?
Тем не менее, вот пара ссылок, которые могут быть полезны: И в заключение простая мысль: Я не говорю, что вы не должны оптимизировать: вы определенно должны!
О, и, кстати: прежде чем что-либо делать: поставьте кое-что для мониторинга , чтобы вы знали, какие улучшения были внесены и как!
Например, вы можете использовать что-то вроде RRDtool + кактусы .
Профилирование
(источник: pascal-martin.fr )
(источник: pascal-martin.fr )
(Спасибо @Mikushi за комментарий) Еще одна возможность, которую я мало использовал, - расширение xhprof : оно также помогает с профилированием, может генерировать графы вызовов - но легче, чем Xdebug,
EXPLAIN ] инструкция, если вы используете MySQL
log_slow_queries , чтобы получить список запросов, которые занимают «слишком много»
И что теперь?
Но, все же ... Почему бы не изучить их немного, на всякий случай? ; -) А как насчет Kohana?
(Даже если не конкретно ^^)
Если есть что-то, что можно сделать быстро, попробуйте; -)
Просматривая сеть, кажется, что есть хоть что-то о XSS-фильтрации; Вам это нужно?
Заключение?
Но выберите «быструю» оптимизацию, которая сначала принесет вам большие выгоды : использование некоторого кеша опкодов может помочь вам снизить нагрузку на ЦП вашего сервера от 10 до 50 процентов ... пара минут на настройку ;-) С другой стороны, потратив 3 дня на 2 процента ...
Без мониторинга вы не будете иметь представления о влиянии того, что вы сделали ... Даже если это настоящая оптимизация или нет!
А показать вашему боссу красивую графику с падением загрузки процессора на 40% - это всегда здорово; -)
В любом случае, и в заключение: получайте удовольствие!
(Да, оптимизация - это весело! )
(Эээ, я не думал, что напишу так много ... Надеюсь, хоть некоторые части этого будут полезны ... И я должен запомнить этот ответ: может быть полезно в других случаях ...)
Код профиля с XDebug .
Используйте много кеширования. Если ваши страницы относительно статичны, обратный прокси-сервер может быть лучшим способом сделать это.
Используйте XDebug и WinCacheGrind или WebCacheGrind для профилирования и анализа медленного выполнения кода.
(источник: ] jokke.dk )
![] jokke.dk](http://jokke.dk/media/2008-webgrind/webgrind_small.png){kind=link}
Я полностью согласен с ответами XDebug и кешированием. Не ищите оптимизацию на уровне Kohana, пока не определите свои самые большие узкие места в скорости и масштабировании.
XDebug сообщит вам, где вы проводите большую часть своего времени, и определит «горячие точки» в вашем коде. Сохраните эту информацию профилирования, чтобы вы могли определить и измерить улучшения производительности.
Пример проблемы и решения: Если вы обнаружите, что каждый раз создаете дорогостоящие объекты из базы данных, которые на самом деле не часто меняются, вы можете посмотреть на их кеширование с помощью memcached или другого механизма. Все эти исправления производительности требуют времени и усложняют вашу систему, поэтому убедитесь в наличии узких мест, прежде чем приступать к их устранению.
Kohana работает очень и очень быстро из коробки, за исключением использования объектов базы данных. Процитирую Зомбора: «Вы можете уменьшить использование памяти, убедившись, что вы используете объект результата базы данных вместо массивов результатов». Это существенно влияет на производительность 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 (погуглите), чтобы узнать о других советах по производительности.