SymfonyCloud handles resource allocation in a reserved approach, rather than on-demand. This means that your project (applications plus services) are given a certain amount of resources and can use as much, or as little, of them as needed.
Your production plan size determines how much CPU and RAM are available to your entire production environment.
The development plan has no dedicated resources allocated: the main
environment is treated like a
development environment and container sizes are set
You can change your project plan at anytime using the
symfony project:scale <plan> command.
Possible production plan sizes are:
Each plan comes with increasing CPU and memory compared to the previous one. Please refer to the SymfonyCloud pricing page to get the official allowance coming with each plan.
By default, SymfonyCloud allocates CPU and memory resources to each container automatically. Some services are optimized for high CPU load, some for high memory load and applications are treated as balanced. By default, SymfonyCloud tries to allocate the largest “fair” size possible to all containers, given the available resources on the plan. That is not always optimal, however, and you can customize that behavior on any application or service container.
If the total resources requested by all apps and services is larger than what the plan size allows then a production deployment will fail with an error.
This value is always ignored in development environments and set to
It will only take effect in the production environment. This default
development container size can be changed (paid option) if you need to.
Please contact SymfonyCloud Support for more information.
For the vast majority of applications, the default fair allocation will be the best option. In particular it will allow the application to grow as the plan size increases. If a container is set at a fixed size, however, it will not get any bigger and the extra resources might go to waste.
The main use-case where setting size manually is helpful is when setting
particular containers to a fixed size to indicate that it really doesn’t need
much CPU or RAM or if its workload is fixed and doesn’t need to scale much.
Static sites, background workers, and other low-need containers can
be set that way to allow more resources to go to other applications and services
containers that really need them. For example, keep your main web container on
the auto size and set your Symfony Messenger consumer sending emails to
A Redis container - set to
S - holding backend sessions
for an application where traffic is mostly due to stateless API requests is
another plausible scenario.
Outside of the PHP world, two additional use cases can benefit from setting these values:
- Shifting memory allocation from the
base_memory(see the custom resources allocation section) for applications with a high baseline need but a low per-request need, such as Java or Go applications.
- For especially memory intensive per-process applications, setting a higher
memory_ratio(see the custom resources allocation section) will give those applications more head room to grow. However, be aware that doing so may draw memory away from other applications or services that need it. Try to optimize your application before throwing more resources at it.
In both cases you will need to do your own profiling to determine optimal values for your application.
Service sizes are set via the
size property in .symfony/services.yaml.
Possible values are
AUTO (the default if not set),
Application (web and workers containers) sizes are set via the
properties in .symfony.cloud.yaml. Possible values are
(the default if not set),
These sizes have a fixed allocation of CPU associated with them and a default RAM one:
XS container size is only available when using custom
resources allocation as describe below in the custom resources allocation
Custom Resources Allocation¶
The default values are appropriate for most reasonably sized scripted applications (PHP, Python, Node.js, Ruby) and so should rarely be changed. Please read carefully this section to determine if you actually need to tweak those settings.
Application containers have memory allocated based on a default ratio that is configurable. Two properties can be adjusted:
1 2 3
resources: base_memory: 64 #default and minimum memory_ratio: 256 #defautl, minimum: 128
base_memory represents a fixed amount of memory (in megabytes) allocated to
memory_ratio is an amount of memory allocated per CPU share.
For example: an
S container gets a 0.5 CPU share, with the default
configuration it would get 64 + 0.5 x 256 = 192 MB of RAM.
If the same container gets its size increased to an
XL, it would now get
64 + 4 x 256 = 1088 MB of RAM.
Memory is expressed as two separate values to match different performance profiles depending on your application needs.
For instance, a PHP web application needs a relatively low base memory to start
PHP-FPM, but each parallel request consumes some additional memory. It would
benefit from a low
base_memory and a relatively high
way, increasing the container size would increase the CPU share allowing more
concurrent requests and its memory allocation naturally scales to match.
Applications in languages that have a persistent runtime, such as Java or Go,
requires a high baseline memory to boot up but then each parallel request
consumes relatively little memory. They would benefit from a much higher
base_memory value and a lower
memory_ratio, so that any container size
has sufficient memory to start the application.
Background workers can also generally benefit from a higher
value and a lower
memory_ratio if they only process one task at a time as
the increase of the CPU share will speed up processing time but will not cause
more tasks to be processed at once so the additional memory is not required.
This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.