PHP: полный мануал с примерами, функциями и ООП

Сначала понимаем объём работы, затем измеряем время

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

Что уже пригодится. ключи массива, foreach

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

<?php
declare(strict_types=1);

$products = [
    ['sku' => 'A', 'stock' => 7],
    ['sku' => 'B', 'stock' => 0],
];
$bySku = [];
foreach ($products as $product) {
    $bySku[$product['sku']] = $product;
}
echo $bySku['B']['stock'], "\n";

0

Следующая ступень. Теперь измеряем hrtime и память, разбираем SQL N+1, кеш и потоковую обработку. Сначала сохраняем правильный результат, затем оцениваем ускорение.

Быстро для одного запроса и быстро под нагрузкой — разные вещи

Страница каталога может отвечать за 200 мс одному посетителю и за пять секунд сотне посетителей. Причина не обязательно в медленной функции PHP: заканчиваются воркеры, база ждёт блокировки, внешний API отвечает дольше или каждый запрос повторяет одинаковую работу. Начинайте с измерения полного пути и числа операций. Среднее значение скрывает хвосты, поэтому смотрите p95/p99 и долю ошибок вместе с нагрузкой.

Для длительности внутри процесса используйте hrtime(true), для памяти — memory_get_usage и memory_get_peak_usage. Сравнивайте одинаковые входы, прогретое окружение, несколько повторов и отдельно холодный запуск. Не публикуйте вывод «array_map всегда быстрее foreach» на основании одного микротеста: размер данных, callback, версия PHP и остальной код меняют результат.

Стоимость алгоритма объясняет рост лучше, чем случайные миллисекунды. Вложенный поиск товара в списке для каждой позиции заказа даёт порядка n×m сравнений. Индекс по ID требует дополнительной памяти, но позволяет один раз пройти справочник и затем делать прямые обращения. Для десятка элементов обе версии могут быть достаточны; для тысяч разница становится архитектурной.

Убираем повторный линейный поиск

<?php
declare(strict_types=1);

$products = [['id'=>10,'name'=>'Tea'],['id'=>20,'name'=>'Coffee']];
$lines = [['productId'=>20,'quantity'=>2],['productId'=>10,'quantity'=>1]];
$byId = [];
foreach ($products as $product) $byId[$product['id']] = $product;
foreach ($lines as $line) {
    $product = $byId[$line['productId']] ?? null;
    if ($product === null) throw new DomainException('Unknown product');
    echo $product['name'].':'.$line['quantity']."
";
}

Coffee:2
Tea:1

Не материализуем всё, если нужен один проход

<?php
declare(strict_types=1);

function quantities(int $count): Generator {
    for ($i=0;$i<$count;$i++) yield ($i % 3)+1;
}
$sum = 0;
foreach (quantities(100000) as $quantity) $sum += $quantity;
echo $sum."
";

199999

fetchAll, file_get_contents и ob_start удобны для ограниченного объёма, но материализуют данные целиком. Большой CSV обрабатывают строками, экспорт — страницами по ключу, JSON огромного размера требует подходящего потокового парсера либо изменения API. json_decode не становится потоковым от того, что результат потом обходится генератором: исходная строка и структура уже загружены.

Повторная конкатенация и копирование больших массивов могут увеличить пиковую память. PHP использует copy-on-write, поэтому присваивание массива не всегда немедленно копирует всё, но изменение общей структуры может потребовать копию. Не делайте вывод о памяти только из числа переменных. Измеряйте пик на реальном размере данных и учитывайте буферы расширений, которые не всегда полностью видны счётчикам PHP.

Подходы, которые особенно часто становятся дорогими

Кеш сокращает повторную работу, но добавляет вопросы актуальности, ключа и сброса. Кеш цены должен учитывать валюту, сегмент покупателя и версию прайс-листа. Ошибка ключа может показать чужую скидку. При одновременном истечении популярного ключа множество запросов начнут один дорогой расчёт; нужны координация обновления, случайное распределение TTL или выдача допустимого устаревшего значения.

OPcache хранит скомпилированный код и обычно полезен для веб-приложений. Он не кеширует результат SQL и не исправляет N+1. JIT не является универсальным ускорителем веб-сайта, где значительная часть времени уходит в I/O. Настройки выбирают измерением на целевой нагрузке, а не копированием максимальных чисел из статьи.

Время и память ограничивают намеренно

У каждого внешнего вызова должен быть timeout, у выборки — разумная граница, у загрузки — предел байтов, у рекурсии — ограничение глубины. Это одновременно надёжность и производительность. Больший memory_limit может временно скрыть утечку, но уменьшит число параллельных воркеров в доступной RAM. Рассчитывайте вместимость сервера по фактической памяти процессов с запасом, а не только по лимиту PHP.

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

Скорость не должна разрушать корректность

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

Измеряйте стоимость промаха и одновременного обновления кеша, а не только идеальный hit. Проверяйте, что отказ кеша не превращается в лавину запросов к базе. Ограничение параллельности обновления и постепенное распределение TTL часто важнее ещё одной микросекунды сериализации. Любые числа скорости в документации без размера данных и окружения рассматривайте как пример методики, а не обещание результата.

Практика: проверьте решение, а не только успешный путь

Импорт 50 000 товаров использует foreach и на каждом шаге SELECT поставщика. С чего начать оптимизацию?