Оптимізація експорту великих масивів даних у Laravel: як уникнути перевантаження пам'яті

Чому генерація великих звітів ламає веб-додатки

У процесі масштабування бізнес-додатків, CRM-систем та інтернет-магазинів обсяг операційних даних стрімко зростає. Типовий сценарій: функція завантаження замовлень чи транзакцій у форматі Excel бездоганно працює на етапі тестування, але під час експлуатації на продакшені починає видавати помилку Allowed memory size exhausted або аварійно завершується через таймаут з'єднання веб-сервера.

Головна причина криється в типовому підході розробників: завантаженні всієї колекції моделей через Model::all() або Model::get() безпосередньо в оперативну пам'ять перед формуванням файлу. Кожен запис Eloquent ініціалізується як повноцінний об'єкт із додатковими метаданими, що за кількох десятків тисяч рядків миттєво вичерпує ліміт оперативної пам'яті сервера.

Перехід від FromCollection до FromQuery

Ефективне вирішення проблеми утилізації ресурсів у популярному пакеті Laravel Excel полягає у використанні інтерфейсу FromQuery замість стандартного FromCollection. Основна різниця полягає в тому, що система не завантажує дані миттєво, а отримує підготовлений Query Builder.

• Відкладене виконання: пакет самостійно керує порційним отриманням записів із бази даних, не перевантажуючи RAM.
• Вибір тільки необхідних колонок: використання select() дозволяє відкинути зайві поля моделі, суттєво зменшуючи розмір кожного рядка в пам'яті.
• Сортування за первинним ключем: обов'язкове додавання orderBy('id') гарантує детермінований порядок обробки пачок і запобігає дублюванню рядків під час тривалого експорту.

Контроль розміру порцій: WithCustomChunkSize

За замовчуванням обробка запитів відбувається фіксованими партіями, проте специфіка проектів відрізняється. Використовуючи інтерфейс WithCustomChunkSize, розробник може чітко контролювати кількість записів у кожній пачці через метод chunkSize().

Вибір розміру пачки — це завжди компроміс між навантаженням на базу даних та оперативною пам'яттю:

• Малий розмір (200–500 записів): мінімальне споживання оперативної пам'яті, що ідеально підходить для серверів з обмеженими ресурсами або рядків із великою кількістю текстових даних.
• Великий розмір (1000–5000 записів): зменшує загальну кількість SQL-запитів до бази даних і прискорює загальний час формування звіту, але потребує більшого запасу пам'яті для генератора таблиць.

Винесення важких звітів у черги (Queued Exports)

Навіть оптимізоване порційне читання з бази не усуває проблеми HTTP-таймаутів: веб-сервер (Nginx чи Apache) закриє з'єднання, якщо генерація файлу триває довше ніж 30–60 секунд. Користувач у результаті бачить білий екран або помилку 504 Gateway Timeout.

Правильна архітектурна практика для бізнес-додатків — перенесення операції у фонові черги (Laravel Queues). При такому підході експорт розбивається на незалежні асинхронні завдання. Користувач миттєво отримує сповіщення про старт процесу, а готовий документ зберігається в хмарному сховищі та відправляється на електронну пошту або стає доступним за посиланням у кабінеті.

Рекомендації команди ViAcore для стабільної роботи

Для забезпечення безперебійної роботи високонавантажених звітів наша команда дотримується таких правил:

• Не збільшуйте параметр memory_limit у конфігурації PHP як постійне рішення — оптимізуйте саму логіку запитів.
• Використовуйте WithMapping, щоб передавати у файл тільки потрібні значення без важких зв'язків моделей.
• Налаштовуйте моніторинг черг за допомогою Laravel Horizon для своєчасного виявлення збоїв у воркерах.