Оптимизация веб-сайтов на базе Kohana для обеспечения скорости и масштабируемости
-
12-09-2019 - |
Вопрос
Сайт, который я создал с помощью Kohana, вчера был переполнен огромным трафиком, что заставило меня сделать шаг назад и оценить некоторые элементы дизайна.Мне интересно, какие стандартные методы оптимизации приложений на базе Kohana существуют?
Меня тоже интересует бенчмаркинг.Нужно ли мне настраивать Benchmark::start()
и Benchmark::stop()
для каждого метода контроллера, чтобы увидеть время выполнения для всех страниц, или я могу применить сравнительное тестирование глобально и быстро?
Со временем я буду чаще использовать библиотеку Cache, но я открыт для новых предложений, поскольку уверен, что могу многое сделать, о чем просто не знаю в данный момент.
Решение
То, что я скажу в этом ответе, не относится только к 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!
- То же самое и с наиболее посещаемыми страницами вашего сайта, если они не меняются хотя бы пару минут. (пример:домашняя страница?), то нет необходимости тратить ресурсы процессора на их повторное создание каждый раз, когда пользователь их запрашивает.
- Возможно, есть разница между страницами, обслуживаемыми анонимными пользователями. (одна страница для всех анонимных пользователей) и страницы, обслуживаемые для идентифицированных пользователей («Привет, мистер X, у вас есть новые сообщения», например)?
- Если это так, вы, вероятно, можете настроить обратный прокси-сервер для кэширования страницы, которая обслуживается анонимными пользователями. (на основе файла cookie, как правило, сеансового файла cookie)
- Это будет означать, что Apache+PHP имеет меньше проблем:только идентифицированные пользователи, которые могут составлять лишь небольшую часть ваших пользователей.
О использование обратного прокси в качестве кеша, для приложения PHP вы можете, например, взглянуть на Результаты тестов показывают увеличение возможностей сервера на 400–700 % с помощью APC и Squid Cache.
(Да, они используют Squid, и я говорил о лаке — это просто еще одна возможность ^^ Varnish появился позже, но больше предназначен для кэширования)
Если вы сделаете это достаточно хорошо и сумеете прекратить повторное создание слишком большого количества страниц снова и снова, возможно, вам даже не придется оптимизировать какой-либо код ;-)
По крайней мере, может быть, не торопясь...И всегда лучше выполнять оптимизацию, когда вы не находитесь под слишком большим давлением...
В качестве примечания:вы говорите в ОП:
Сайт, который я построил с Коханой, был вчера с огромным количеством движения,
Это своего рода внезапная ситуация, когда обратный прокси-сервер может буквально спасти положение, если ваш сайт может справляться с ежесекундным обновлением:
- установи, настрой, пусть всегда -- каждый обычный день -- бегать:
- Настройте его, чтобы страницы PHP не хранились в кеше;или только на короткий срок;таким образом, у вас всегда будут отображаться актуальные данные
- И в тот день, когда вы сделаете эффект косой черты или Digg:
- Настройте обратный прокси-сервер для хранения страниц PHP в кеше;или на более длительный период времени;возможно, ваши страницы не будут обновляться ни на секунду, но это позволит вашему сайту пережить дигг-эффект!
Об этом, Как я могу обнаружить и выжить, будучи «Slashdotted»? может быть интересное чтение.
Что касается 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.stat](https://php.net/manual/en/apc.configuration.php#ini.apc.stat)
может быть полезен для загрузки системы;но это означает, что изменения, внесенные в файлы PHP, не будут учитываться, если вы не очистите весь кеш кода операции;об этом подробнее см., например stat() или не stat()?
Использование кеша для данных
Насколько это возможно, лучше избегайте делать одно и то же снова и снова.
Главное, о чем я думаю, это, конечно же, SQL-запросы:многие из ваших страниц, вероятно, выполняют одни и те же запросы, и результаты некоторых из них, вероятно, почти всегда одинаковы...Это означает, что много "бесполезный" запросы к базе данных, которой приходится тратить время на обработку одних и тех же данных снова и снова.
Конечно, это справедливо и для других задач, таких как вызовы веб-служб, получение информации с других веб-сайтов, тяжелые вычисления и т. д.
Возможно, вам будет очень интересно узнать:
- Какие запросы выполняются много раз и всегда возвращают одни и те же данные?
- Какой еще (тяжелый) вычисления выполняются много времени, всегда возвращая один и тот же результат
И сохраните эти данные/результаты в каком-нибудь кеше, чтобы их было легче получить – Быстрее - и вам не нужно обращаться к вашему SQL-серверу «ни за чем».
Отличными механизмами кэширования являются, например:
- БТР:помимо opcode-cache, о котором я говорил ранее, он позволяет хранить данные в памяти,
- И/или кэширование памяти (смотрите также), что очень полезно, если у вас буквально есть много данных и/или являются использование нескольких серверов, как оно распределено.
- конечно, вы можете подумать о файлах;и, возможно, многие другие идеи.
Я почти уверен, что в вашей платформе есть некоторые вещи, связанные с кешем;ты, наверное, уже это знаешь, как ты сказал «Со временем я буду чаще использовать библиотеку Cache» в ОП ;-)
Профилирование
Теперь было бы неплохо использовать Xdebug расширение до профилируйте свое приложение:часто это позволяет довольно легко найти пару слабых мест — по крайней мере, если есть какая-то функция, требующая много времени.
Настроен правильно, он создаст файлы профилирования, которые можно проанализировать с помощью некоторых графических инструментов, таких как:
- KCachegrind:мой любимый, но работает только в Linux/KDE
- Винкешгринд для окон;К сожалению, он делает немного меньше вещей, чем KCacheGrind - обычно он не отображает графы вызовов.
- Вебгринд который работает на веб-сервере PHP, поэтому работает где угодно, но, вероятно, имеет меньше возможностей.
Например, вот пара скриншотов KCacheGrind:
(источник: pascal-martin.fr)
(источник: pascal-martin.fr)
(Кстати, граф вызовов, представленный на втором скриншоте, обычно не может быть выполнен ни WinCacheGrind, ни Webgrind, если я правильно помню ^^ )
(Спасибо @Mikushi за комментарий) Другая возможность, которую я мало использовал, — это xhprof расширение :он также помогает с профилированием, может генерировать графы вызовов, но он легче, чем Xdebug, а это значит, что вы сможете установить его на производственный сервер.
Вы должны иметь возможность использовать его вместе XHGui, который поможет визуализировать данные.
Что касается SQL:
Теперь, когда мы немного поговорили о PHP, обратите внимание, что это более чем возможно, что ваше узкое место не связано с PHP., но база данных одна...
Как минимум две-три вещи здесь:
- Вам следует определить:
- Какие запросы чаще всего выполняет ваше приложение?
- Оптимизированы ли они (используя правильные индексы, в основном?), используя
EXPLAIN
инструкция, если вы используете MySQL- Смотрите также: Оптимизация SELECT и других операторов
- Вы можете, например, активировать
log_slow_queries
чтобы получить список запросов, которые принимают "слишком" время и начните оптимизацию по ним.
- можете ли вы кэшировать некоторые из этих запросов (см. то, что я сказал ранее)
- Хорошо ли настроен ваш MySQL?Я мало что знаю об этом, но есть некоторые параметры конфигурации, которые могут оказать определенное влияние.
- Оптимизация сервера MySQL может дать вам некоторую интересную информацию об этом.
И все же две самые важные вещи:
- Не заходите в БД, если вам не нужно: кэшируйте столько, сколько сможете!
- Когда вам нужно обратиться к БД, используйте эффективные запросы:использовать индексы;и профиль!
И че теперь?
Если вы все еще читаете, что еще можно оптимизировать?
Ну, есть еще куда расти...Несколько идей, ориентированных на архитектуру, могут быть следующими:
- Переключитесь на n-уровневую архитектуру:
- Поместите MySQL на другой сервер (2-й уровень:один для PHP;другой для MySQL)
- Используйте несколько PHP-серверов (и распределить нагрузку между ними)
- Используйте другие машины для статических файлов с более легким веб-сервером, например:
- Используйте несколько серверов для MySQL, несколько серверов для PHP и несколько обратных прокси перед ними.
- Конечно:установить кэширование памяти демоны на любом сервере, где есть сколько-нибудь свободной оперативной памяти, и используйте их для кэширования столько, сколько сможете/имеет смысл.
- Использовать что-то «более эффективное», чем Apache?
- Я все чаще слышу о nginx, который должен быть хорош, когда речь идет о PHP и веб-сайтах с большим объемом трафика;Сам я никогда им не пользовался, но вы можете найти несколько интересных статей об этом в сети;
- например, Производительность PHP III – запуск nginx.
- Смотрите также: PHP-FPM — диспетчер процессов FastCGI, который входит в состав PHP >= 5.3.3 и творит чудеса с nginx.
- Я все чаще слышу о nginx, который должен быть хорош, когда речь идет о PHP и веб-сайтах с большим объемом трафика;Сам я никогда им не пользовался, но вы можете найти несколько интересных статей об этом в сети;
Что ж, возможно, некоторые из этих идей в вашей ситуации немного излишни ^^
Но все равно...Почему бы не изучить их немного, на всякий случай?;-)
А что насчет Коханы?
Ваш первоначальный вопрос касался оптимизации приложения, использующего Kohana...Ну, я опубликовал кое-что идеи, которые верны для любого приложения PHP...А это значит, что они справедливы и для Коханы ;-)
(Даже если это не конкретно ^^)
Я сказал:использовать кэш;Кохана, кажется, поддерживает некоторых кэширование данных (Вы сами об этом говорили, так что здесь нет ничего нового...)
Если есть что-то, что можно сделать быстро, попробуйте ;-)
Я также сказал, что не следует делать ничего лишнего;есть ли в Кохане что-нибудь, что вам не нужно по умолчанию?
Просматривая сеть, кажется, что есть хоть что-то о XSS-фильтрации;тебе это нужно?
И все же, вот пара ссылок, которые могут оказаться полезными:
- Общая дискуссия Кохана:Кэширование?
- Поддержка сообщества:Оптимизация веб-сайта:Максимальная производительность веб-сайта с использованием Kohana
Заключение?
И в заключение простая мысль:
- Сколько будет стоить вашей компании заплатить вам за 5 дней? -- учитывая, что это разумный промежуток времени, чтобы провести отличную оптимизацию.
- Сколько будет стоить вашей компании покупка (платить за?) второй сервер и его обслуживание?
- Что делать, если вам нужно масштабировать больше?
- Сколько будет стоить провести 10 дней?более?оптимизируете все возможные части вашего приложения?
- И сколько стоит еще пара серверов?
Я не говорю, что вам не следует оптимизировать:вам обязательно следует!
Но выбирайте «быструю» оптимизацию, которая принесет вам большие выгоды. первый:использование некоторого кэша опкодов может помочь вам снизить нагрузку на процессор вашего сервера на 10–50 процентов...А настройка занимает всего пару минут ;-) С другой стороны, потратив 3 дня на 2 процента...
Да, и, кстати:прежде чем что-либо делать: установить некоторые средства мониторинга, чтобы вы знали, какие улучшения были сделаны и как!
Без мониторинга вы не будете иметь ни малейшего представления о эффекте того, что вы сделали...Даже неважно, настоящая это оптимизация или нет!
Например, вы можете использовать что-то вроде RRDtool + кактусы.
А показать своему начальнику красивую графику с падением загрузки процессора на 40 % — это всегда здорово ;-)
В любом случае, и подведем итог: веселиться!
(Да, оптимизация — это весело!)
(Эмм, не думал, что напишу так много...Надеюсь, что хотя бы некоторые части этого будут полезны...И мне следует запомнить этот ответ:может быть пригодится в другой раз...)
Другие советы
Использовать XDebug и WinCacheGrind или WebCacheGrind для профилирования и анализа медленного выполнения кода.
(источник: jokke.dk)
Код профиля с XDebug.
Используйте много кэширования.Если ваши страницы относительно статичны, лучшим способом сделать это может быть обратный прокси-сервер.
Kohana работает очень быстро, за исключением использования объектов базы данных.Чтобы процитировать Zombor: «Вы можете уменьшить использование памяти, гарантируя, что вы используете объект результата базы данных вместо массивов результатов». Это делает огромную разницу в производительности на сайте, который защеливается.Он не только использует больше памяти, но и замедляет выполнение скриптов.
Также - необходимо использовать кеширование.Я предпочитаю кэш памяти и использую его в своих моделях следующим образом:
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 (погуглите), чтобы получить еще несколько советов по производительности.
Строго связано с Коханой (вероятно, вы уже это сделали или нет):
В производственном режиме:
- Включите внутреннее кэширование (это будет кэшировать только результаты Kohana::find_file, но на самом деле это может очень помочь.
- Отключить профилировщик
Просто мои 2 цента :)
Я полностью согласен с ответами XDebug и кешированием.Не изучайте уровень Kohana для оптимизации, пока не определите свои самые большие узкие места в скорости и масштабировании.
XDebug сообщит вам, где вы проводите больше всего времени, и определит «горячие точки» в вашем коде.Сохраните эту информацию профилирования, чтобы можно было определить базовые показатели и измерить улучшения производительности.
Пример проблемы и решения:Если вы обнаружите, что каждый раз создаете дорогостоящие объекты из базы данных, которые на самом деле не часто меняются, вы можете рассмотреть возможность их кэширования с помощью memcached или другого механизма.Все эти исправления производительности требуют времени и усложняют вашу систему, поэтому убедитесь в наличии узких мест, прежде чем приступать к их устранению.