COMPUTE / SHARED CPU
Start with the resources your website, development environment or small service needs. Shared CPU is a cloud server model to consider when processor demand varies throughout the day. Choose capacity by looking at CPU, memory, storage and traffic together.
01 / Overview
With Shared CPU, virtual machines share time on the underlying physical processors. This model is worth considering for applications with short bursts of computation and quieter periods between them. If web requests, background jobs and development tools run together, understand the demand of each component before sizing the server.
Visitor counts alone do not define a suitable plan. Applications serving similar traffic can have very different database, caching and file-processing requirements. Consider Dedicated CPU for sustained processor demand, or High Memory when the working set is the constraint. Use current pricing and available plan specifications for the commercial decision.
Evaluate web and service workloads that do not compute intensively all day. Track response times during busy periods as well as average CPU utilisation.
Separate development, staging and production servers make changes easier to understand. Record differences in configuration and access, and keep test credentials away from production.
Compare CPU pressure, memory use, storage latency and network activity before choosing a larger plan. Addressing the actual constraint makes the next step more deliberate.
02 / Architecture
Illustrative resource relationship: an application runs on a virtual server that shares processor time. Data storage and backup remain separate planning decisions.
Selection guide03 / Selection guide
| Consider | How to decide | Why it matters |
|---|---|---|
| Duration of CPU demand | Distinguish short spikes from sustained processor utilisation. | Continuous compute demand may call for a different resource model. |
| Memory working set | Measure the application, database and cache together. | Memory pressure can increase response times even while CPU capacity is available. |
| Storage behaviour and growth | Estimate file volume, read/write patterns and backup storage separately. | Additional capacity and lower storage latency address different requirements. |
| User location and traffic | Measure access from Türkiye and your other target markets, and review transfer needs. | Infrastructure decisions should reflect real user experience and the full cost of operation. |
04 / Use cases
Measure traffic patterns, plugin activity and database queries on content-led sites. Test an expected campaign peak before relying on normal-day resource usage.
Validate releases in a separate environment before deployment. Keep test data, external service connections and administrative access distinct from the production environment.
Consider services with modest computation per request and variable traffic. Check whether scheduled work competes with interactive requests for the same resources.
Plans & pricing
| Host | CPU | RAM | Storage | Bandwidth | Price |
|---|---|---|---|---|---|
 FibaCloud
|
1
|
1 GB
|
25 GB
|
Includes 2TB bandwidth
|
4.00$Hourly: 0,005
|
| Host | CPU | RAM | Storage | Bandwidth | Price |
|---|---|---|---|---|---|
|
FibaCloud
|
2
|
4 GB
|
80 GB
|
Includes 5TB bandwidth
|
12.00$Hourly: 0,016
|
| Host | CPU | RAM | Storage | Bandwidth | Price |
|---|---|---|---|---|---|
|
FibaCloud
|
4
|
8 GB
|
160 GB
|
Includes 6TB bandwidth
|
24.00$Hourly: 0,033
|
| Host | CPU | RAM | Storage | Bandwidth | Price |
|---|---|---|---|---|---|
|
FibaCloud
|
8
|
16 GB
|
320 GB
|
Includes 10TB bandwidth
|
49.00$Hourly: 0,068
|
Review the current configuration, price and order terms before selecting a service.
Choose a location to measure your connection latency.
05 / From planning to operation
List the services, operating system requirements and likely busy periods. Record the assumptions behind your initial resource estimate.
Restrict administration, assign responsibility for updates and plan how data will be restored before the application starts collecting it.
Use realistic data and requests. Assess successful responses, latency and resource consumption together instead of relying on a single utilisation chart.
Optimise the application or select another resource family when demand justifies it. Define maintenance and rollback steps for each infrastructure change.
No. It describes a virtual server resource model that shares physical processor time. Consider Bare Metal if your requirements call for a different level of control over a physical machine.
There is no useful answer based on visitor count alone. Application design, queries, caching and concurrent requests all matter. Measure an initial requirement with representative load tests.
Consider it when CPU demand stays high or processing time becomes central to the application. First distinguish CPU pressure from memory, storage and application bottlenecks.
No. Decide which data to protect, how often to capture it and how long to retain it. Review the selected backup service scope and practise restoring the data.
Connect product decisions with installation, configuration and operating knowledge.
These references explain the technical concepts discussed on this page. Available configurations and service scope are defined by FibaCloud product and order information.
FIBACLOUD / Shared CPU
Tell us about your application, expected usage and operating requirements. Let’s bring the resource choices together.
