- Who is this for?
- Developers running small VPS backends and teams planning resource budgets.
- Before you start
- Representative data, an owned staging environment and normal/peak user journeys.
1. Separate MAU from concurrency
Monthly users may arrive gradually or simultaneously after a notification. Capacity depends on concurrent work and the cost of each action. Include lists, searches, uploads and writes in the session model. Record assumptions when production traffic is unavailable rather than presenting a guess as a benchmark.
2. Budget memory across services
The operating system, API, database, connection pool and workers share resources. Total server memory is not the application quota. Image jobs can compete with API requests, while adding processes increases baseline memory use. Identify where memory is allocated before choosing a larger package.
| Resource | Signal | First investigation |
|---|---|---|
| Memory | RSS and pressure | Process and job size |
| Database | Connections / slow queries | Pool and indexes |
| CPU | Long tasks | Worker boundaries |
| Disk | Space and latency | Retention / capacity |
3. Test representative journeys
An empty table and one endpoint cannot validate a real product. Include normal payload size, permissions and relationships. Model the read/write mix and time between actions. Test an owned staging system with gradual ramps and bounded bursts. Measure recovery after the load falls, not just behavior at peak.
4. Define pass criteria first
Track p95 latency, timeout, error rate and queue wait alongside memory, CPU, connections and storage latency. A low average response time can hide a slow minority of requests. Capture data size and test duration so results are reproducible.
Input: dataset + flow mix + concurrency + duration
Output: p50 / p95 + error rate + resource use + recovery5. Turn findings into resource decisions
Fix slow queries, excessive payloads and unbounded queues before buying capacity. Compare larger resources with separate database or worker placement. Do not generalize one test to every mobile app. Planned Uygulama Cloud packages describe resource scope without a user-count, SLA or connection guarantee.
Action summary
- Separate monthly users from concurrency.
- Test realistic data and actions.
- Report latency, errors and recovery together.
Common questions
What exact user count fits 2 GB?
There is no reliable number without a workload and concurrency test.
Does low CPU mean spare capacity?
Not necessarily. Memory, connections, storage, network or queues may be the bottleneck.
Sources and scope
Technical references are listed below. Examples illustrate implementation in your own environment; they are not customer benchmarks or claims of live Uygulama Cloud services. Check the current provider documentation before applying settings.
Sources checked: