Cloud instances are used to host websites, applications and development environments, allowing computing resources to follow business stage planning.
Suitable for teams that want to go online first and then plan resources according to business growth.
Cloud servers combine compute, memory, and storage into available cloud instances. It is suitable for starting a small-scale business and then adjusting the resource plan according to the number of visits, application load and data growth.
The value of cloud servers lies in organizing computing resources according to business scale; application concurrency, status data, and fault recovery must be considered when selecting a server.
Plan computing, memory, and storage according to application scale to reduce early one-time investment. As your business grows, you can adjust the instance specifications or add more instances based on the platform's support range.
Deploy development, testing and production environments separately, manage systems, applications and access rights according to purpose to reduce mutual impact.
The resources of websites, interfaces and data services have different focuses. Combine CPU, memory, disk, and bandwidth usage to choose a more appropriate combination of instances.
Cloud instances provide a computing environment visible to the operating system. For the business, response speed depends on the entire path the request takes, not just how many vCPUs are purchased.
The request first goes through DNS, connection establishment and portal forwarding; cross-regional delay will directly enter the user waiting time.
The process executes routing, authentication and business logic, and thread scheduling and connection pooling determine how concurrency falls to the CPU.
Databases, caches, and files hold shared state, and their wait times often exceed the application's own computation time.
The response is returned to the client, and delays, errors, and dependency time are recorded at the same time, providing a basis for capacity expansion and fault location.
vCPU represents the virtual processor that can be used by an instance. Its correspondence with physical cores and hardware threads depends on the platform and instance type. The actual throughput may be different when the same number of vCPUs encounter different processor generations, single-core capabilities, and scheduling methods. First use business requests to verify single-thread and concurrency performance, and then determine whether adding cores is effective.
Vertical expansion is to increase the computing or memory resources of a single instance. It is suitable for applications that cannot be split temporarily, but is still limited by the capacity of a single machine. Horizontal expansion involves adding application nodes, which requires ingress offloading and shared state management. Identify bottlenecks before scaling; if all nodes are waiting for the same slow query, adding application instances will only further amplify database pressure.
If login sessions, uploaded files, and background task progress are only saved in a certain instance, the context may be lost after traffic switching. This state can be handed off to a dedicated data layer and idempotent handling set up for repeated requests. The database still needs to handle consistency, replication, and recovery; just because the application layer becomes stateless does not mean that the entire system no longer needs to manage data.
The following are common architecture and operation and maintenance examples. WAF.PRO's resource specifications, network and storage forms, expansion methods, mirroring and backup capabilities are subject to the specific plan and delivery list; the reference documents are only used to understand the technical principles.
Fix the same data size, request ratio and concurrency conditions, and observe the sustained load and peaks; in addition to the average, look at the p95 and p99 latencies of slower requests.
| Metric | Application impact | How to assess |
|---|---|---|
| CPU and concurrency | Single-thread hotspots or lock contention may make the total CPU appear low, but the interface is queued. | At the same time, each core utilization, request throughput and thread waiting are recorded, and single concurrency and multiple concurrency are compared. |
| memory working set | Insufficient cache can increase database or disk access; continuous paging can slow down response. | Observe available memory, paging and cache hit rates, covering real data volumes and peak periods. |
| IOPS and throughput | Small block random access is more concerned with operations per second, and large file transfer is more concerned with bytes per second. | Test against actual block sizes, read-to-write ratios, and queue depths, while checking instance and storage limits. |
| storage latency | Synchronous writing and transaction submission will wait for I/O, and obvious lags may occur if the throughput is not full. | Pay attention to read and write latency and queuing time, and align application transaction time with storage metrics. |
| Networks and Dependencies | Bandwidth, number of connections, and downstream responses combine to limit how quickly requests can be completed. | Measure the connection delay and packet loss from the main user area, and split the time consumption of the entrance, application and data layers. |
Bring these four types of information to make the selection discussion more concrete.
Host the official website, content management system and regular web services, and plan resources according to the access scale.
Deploy business interfaces, background services and lightweight applications to leave room for subsequent multi-instance deployment.
Divide the environment by project and conduct functional verification, version testing and application trial operation.
Taking corporate websites and APIs as an example, first establish a recoverable basic deployment, and then split and expand based on evidence to avoid incurring the cost of complex clusters in advance when traffic is small.
Version application configurations and packages, record health checks, startup sequences, and dependencies; test representative interfaces first to determine normal delays and capacity margins.
Sort out the storage locations of sessions, files, tasks and databases; move the state that needs to be shared across nodes out of the local application, and verify that the business can still continue after restarting.
When necessary, access the second application node through a self-built or confirmed available ingress diversion mechanism to verify request allocation, connection draining, and single node exit.
Restore the backup in the isolation environment, check the data and key transactions, record the total time from fault discovery to service restoration, and organize the steps into an operation manual.
Single-device deployment is easy to maintain, but it concentrates application and data failures; multiple nodes improve replaceability, but also increase the cost of configuration synchronization, session management, and monitoring. Scaling cadence should be determined by a combination of load, allowed outage time, and team maintenance capabilities.
First monitor the request success rate, key interface latency and task backlog, and then correlate CPU, memory, disk and network indicators. Alarms should describe the impact and processing entry; simply looking at instance survival will not reveal application deadlocks, exhaustion of database connections, or expired certificates.
Keep the verified program version and configuration, update it on a small scale first, and observe health checks and business indicators. Database changes must be compatible with old and new versions during the release period, and rollback conditions must be clear; if you only roll back the program and ignore the table structure, you may not be able to restore the service.
Writing data to persistent storage does not mean that there is a backup, and the copy may be accidentally deleted simultaneously. Develop backup frequency, retention period and independent storage strategies, regularly restore and verify business data, and use actual results to verify whether the preset data loss tolerance and recovery time goals are achieved.
Combined with peak concurrency, data growth and dependent capacity planning margin, verify the expansion process and possible interruption windows in advance. After expansion, retest whether the bottleneck has been transferred to the database or network, and clean up failed resources to avoid long-term costs for idle capacity.
Applications can be incrementally split by workload, allowing teams to validate capacity and deployment processes from smaller starting points.
It can run, but transaction latency, data protection and failure recovery should be verified first, and cannot be judged based on the number of cores alone.
The ordinary virtual resource view does not prove that the physical core is exclusive, nor does it automatically provide the hardware access capabilities required by the application.
Serial logic, database locks, and external interface waits do not improve linearly with the number of cores, and the actual wait point should be found first.
Capacity, IOPS, throughput, and latency are different dimensions, and instances and storage paths may also have their own performance limitations.
Whether the snapshot is available, what data it covers, and whether it meets the consistency requirements need to be checked; it still needs to be verified by recovery.
Support for upgrades, resizable resources, and required downtime depend on the platform and instance specifications selected. It is recommended to confirm the expansion path when purchasing and reserve a window for business maintenance.
Basic network protection and advanced defense products have different service scopes. If your business continues to face DDoS attacks, you can learn more about Titanium Cloud (DDoS-protected cloud) and confirm the required defense amount and processing strategy.
First sort out the application type, expected concurrency, data volume and access area, and then make adjustments based on actual monitoring results. Whether the database, cache, and file services are deployed separately will also affect resource requirements.
No need. First complete configuration management, health checks and backups, and then separate states such as sessions and files; only consider further splitting when clear capacity or team needs arise.
Start by looking at single cores, I/O waits, locks, connection pools, and downstream latency. The overall low CPU may just be the process waiting, and adding cores directly may not necessarily improve the user experience.
In addition to functional testing, compare delays and error rates under representative loads, verify scheduled tasks, permissions, and recovery processes, and clarify data synchronization and rollback methods before switching.
Provide business type, access area, peak load, data size and recovery objectives, and work with technical consultants to evaluate configuration, network and delivery solutions.
From personal projects to corporate operations, find the protection solution that's right for you.
Pay only when satisfied
Contact support