How to Calculate VPS Resources for an Online Store Before a Sale
A practical approach to evaluating CPU, memory, database, and performance headroom before a marketing campaign: from load scenarios to scaling criteria.
In this article
Увеличить VPS в два раза перед распродажей — понятное, но слабое решение. У магазина может хватать процессора и не хватать соединений с базой; память может уходить в кэш, а очередь заказов — ждать внешний API доставки. Тариф становится дороже, а узкое место остаётся.
Ресурсы лучше оценивать от пользовательских сценариев и измерений. Цель — не угадать идеальную конфигурацию, а определить рабочую нагрузку, запас, момент масштабирования и действия при деградации.
Переведите прогноз продаж в технические сценарии
Количество посетителей само по себе мало что говорит серверу. Один человек открывает карточку из CDN, другой применяет тяжёлый фильтр, третий оформляет заказ и вызывает несколько интеграций. Прогноз разбивают на действия и доли.
Сценарий | Что нагружает | Что измерять |
|---|---|---|
Категория и фильтр | PHP, база, поиск, кэш | Время ответа, запросы к базе, доля попаданий в кэш |
Карточка товара | Шаблон, цены, остатки, изображения | Время сервера и вес ответа |
Корзина | Сессия, пересчёт цены и скидок | Ошибки, блокировки, стабильность суммы |
Оформление заказа | База, платёж, доставка, CRM | Время шага, тайм-ауты, число повторов |
Импорт каталога | CPU, диск, база, фоновые задания | Длительность и влияние на покупателей |
Условный пример: реклама обещает 12 тысяч визитов за час. Если пик распределится неравномерно и один визит создаёт в среднем восемь динамических запросов, среднее значение не равно безопасному пику. Для теста задают плавный рост, ожидаемое плато и короткий всплеск выше прогноза.
Снимите базовую линию до теста
Измерения на уже перегруженном сервере не показывают нормальное состояние. Выберите обычный час без импорта и зафиксируйте загрузку процессора, свободную и доступную память, swap, задержку диска, число соединений с базой, очередь фоновых задач и распределение времени ответа.
CPU важен вместе с очередью выполнения и временем одного запроса; процент без контекста не показывает насыщение.
Память оценивают по доступному объёму и давлению, а не по полю «свободно»: Linux использует RAM для кэша.
Диск проверяют по задержке и очереди, особенно во время импорта, резервного копирования и записи журнала.
Базу оценивают по медленным запросам, блокировкам, пулу соединений и доле чтения с диска.
Внешние сервисы измеряют отдельно: быстрый сайт не исправит медленный расчёт доставки или зависший платёжный callback.
Тестируйте копию, похожую на боевую систему
Нагрузочный тест на пустом каталоге и свежей базе измеряет лабораторный шаблон. В тестовом контуре нужны сопоставимый объём товаров и заказов, те же индексы, версия PHP, конфигурация базы, кэш и фоновые процессы. Персональные данные при копировании обезличивают.
Опасно направлять искусственную нагрузку на рабочий магазин без согласованного окна и ограничителей. Тест может исчерпать соединения, заполнить журнал, создать заказы или вызвать реальные платёжные и доставочные API. Для внешних интеграций используют тестовые режимы либо заглушки с измеренной задержкой.
Как читать результат без магических порогов
Смотрите на момент, когда система перестаёт выполнять договорённый уровень сервиса. Например, 95 процентов карточек должны отвечать серверной частью быстрее 600 миллисекунд, ошибки — оставаться ниже согласованной доли, а очередь заказов — разбираться не дольше двух минут. Это условные примеры, а не универсальные нормы.
Если время растёт вместе с CPU и очередь выполнения не успевает снижаться, вероятно насыщение процессора или слишком дорогой код. Если CPU умеренный, но растут ожидание диска и запросы базы, увеличение ядер может почти не помочь. Если заканчивается память и начинается постоянный обмен со swap, сначала выясняют владельца памяти и настройки кэшей.
Разделите вертикальный рост и архитектурные изменения
Ситуация | Вероятное действие | Ограничение |
|---|---|---|
Короткий прогнозируемый пик | Временно увеличить VPS и прогреть кэш | Нужны измерения и возможность вернуть тариф |
Один тяжёлый шаблон | Оптимизировать запросы и компонент | Новый тариф маскирует причину |
Много статических файлов | Вынести раздачу в CDN или объектное хранилище | Динамика и база останутся на сервере |
Фоновые задачи мешают покупателям | Разнести очереди и расписание | Нельзя допустить отставание заказов |
Предел одного узла | Разделить веб, базу, поиск или добавить несколько веб-узлов | Появятся требования к сессиям и общему хранилищу |
Подготовьте план на день кампании
Заморозьте необязательные обновления и массовые изменения каталога.
Проверьте резервную копию и восстановление, но не запускайте тяжёлое копирование в пик.
Прогрейте кэши контролируемыми запросами и убедитесь, что прогрев не создаёт побочных действий.
Настройте наблюдение за временем ответа, ошибками, очередями, базой и внешними API.
Назначьте уровни реакции: что можно масштабировать автоматически, что требует решения специалиста и когда останавливается реклама.
После пика сохраните графики и фактические числа, чтобы следующий расчёт опирался на реальные данные.
Итоговая конфигурация VPS — это следствие теста, а не отправная точка. Полезный расчёт связывает прогноз действий покупателей с ограничениями приложения и оставляет запас на ошибку прогноза. Если магазин нельзя воспроизвести в тестовом контуре, масштабирование проводят осторожнее, с ранними порогами и готовым откатом.
Doubling the VPS before a sale is a clear but weak solution. A store may have enough CPU but lack database connections; memory may be consumed by cache, while the order queue waits for an external delivery API. The tariff becomes more expensive, but the bottleneck remains.
Resources are better evaluated based on user scenarios and measurements. The goal is not to guess the ideal configuration, but to determine the workload, headroom, the moment for scaling, and actions during degradation.
Convert sales forecasts into technical scenarios
The number of visitors alone tells the server little. One person opens a product card from the CDN, another applies a heavy filter, and a third places an order triggering several integrations. The forecast is broken down into actions and proportions.
Scenario | What is under load | What to measure |
|---|---|---|
Category and filter | PHP, database, search, cache | Response time, database queries, cache hit rate |
Product card | Template, prices, stock levels, images | Server time and response size |
Shopping cart | Session, price recalculation, and discounts | Errors, locks, and sum stability |
Order placement | Database, payment, delivery, CRM | Step duration, timeouts, number of retries |
Catalog import | CPU, disk, database, background jobs | Duration and impact on shoppers |
A conditional example: advertising promises 12,000 visits in an hour. If the peak is unevenly distributed and one visit generates an average of eight dynamic requests, the average does not equal the safe peak. For testing, set a gradual increase, an expected plateau, and a short spike above the forecast.
Establish a baseline before testing
Measurements taken on an already overloaded server do not reflect normal conditions. Select a typical hour without imports and record CPU load, free and available memory, swap, disk latency, number of database connections, background task queue, and response time distribution.
CPU matters together with the execution queue and the time per request; a percentage without context does not show saturation.
Memory is assessed by available volume and pressure, not by the 'free' field: Linux uses RAM for caching.
The disk is checked for latency and queue depth, especially during import, backup, and logging.
The database is evaluated by slow queries, locks, connection pool usage, and the proportion of reads from disk.
External services are measured separately: a fast site will not fix a slow shipping calculation or a stuck payment callback.
Test a copy resembling the production system
A load test on an empty catalog and fresh database measures a laboratory template. The test environment requires a comparable volume of products and orders, the same indexes, PHP version, database configuration, cache, and background processes. Personal data must be anonymized during copying.
It is dangerous to direct artificial load to a live store without an agreed window and limits. The test may exhaust connections, fill logs, create orders, or trigger real payment and shipping APIs. For external integrations, use test modes or stubs with measured latency.
How to read results without magic thresholds
Focus on the point where the system stops meeting the agreed service level. For example, 95 percent of product cards must respond via the server in under 600 milliseconds, errors must remain below the agreed share, and the order queue must be processed within two minutes. These are conditional examples, not universal norms.
If execution time increases alongside CPU usage and the execution queue fails to decrease, the processor is likely saturated or the code is too expensive. If CPU usage is moderate but disk wait times and database queries rise, adding more cores may offer little help. If memory runs out and swapping begins, first identify the memory owner and cache settings.
Separate vertical scaling from architectural changes
Situation | Likely Action | Limitation |
|---|---|---|
Short Predictable Spike | Temporarily increase VPS resources and warm the cache | Measurements are needed, and the ability to revert the tariff plan |
One heavy template | Optimize queries and the component | A new tariff plan masks the cause |
Many static files | Offload distribution to a CDN or object storage | Dynamic content and the database will remain on the server |
Background tasks hinder shoppers | Separate queues and schedules | Do not allow orders to fall behind |
The limit of a single node | Separate web, database, search, or add multiple web nodes | Requirements for sessions and shared storage will arise |
Prepare a plan for the campaign day
Freeze optional updates and mass catalog changes.
Verify backups and restoration, but do not run heavy copying during peak hours.
Warm up caches with controlled requests and ensure warming does not trigger side effects.
Configure monitoring for response time, errors, queues, the database, and external APIs.
Define response levels: what can be scaled automatically, what requires a specialist's decision, and when to stop advertising.
After the peak, save the graphs and actual figures so the next calculation is based on real data.
The final VPS configuration is a result of testing, not a starting point. A useful calculation links predicted shopper actions to application constraints and leaves a margin for forecast error. If the store cannot be reproduced in a test environment, scale cautiously with early thresholds and a ready rollback plan.
Discussion 0
Share your experience and ask questions. Comments without links appear after editorial review.
No comments yet. Start the discussion.