Disk I/O performance is a crucial yet often overlooked metric when selecting a Japanese cloud server. When renting a Japanese cloud server, it's recommended to understand storage specifications, performance benchmarks, disk specifications of major cloud service providers' Japanese nodes, practical testing, and application scenario optimization strategies.

Currently, mainstream Japanese cloud servers primarily use three types of storage media:

Hard Disk Drives (HDDs): Enterprise-grade HDDs typically have a rotational speed of 7200 RPM, with sequential throughput reaching 200-300 MB/s per disk. However, random IOPS is affected by mechanical seek and rotational latency, usually only in the hundreds to thousands. HDD P99 latency often peaks at tens of milliseconds, with significant performance degradation, especially under high-concurrency random read/write scenarios.

SATA/SAS Solid State Drives (SSDs): Based on NAND flash memory, these have no mechanical parts. In tests on Tokyo servers, sequential read/write speeds per disk were approximately 500-550 MB/s, with random IOPS reaching tens of thousands. P99 latency is typically in the range of a few milliseconds.

NVMe SSDs: Based on the PCIe bus, they transmit data and support multi-queue parallel processing, significantly reducing I/O latency. NVMe SSDs differ significantly from SATA SSDs in interface bandwidth, queue depth, and concurrency capabilities: SATA interface bandwidth is capped at approximately 600MB/s, while NVMe, through the PCIe bus, can achieve several GB/s or even higher transmission bandwidth. In actual testing, NVMe SSDs can achieve 4KB random read latency as low as 10 microseconds and write latency as low as 5 microseconds.

Core Performance Metrics for Hard Drive Speed

When evaluating the hard drive speed of Japanese cloud servers, the following three core metrics need to be considered:

IOPS (Input/Output Operations Per Second): Measures the storage device's ability to handle random I/O requests, directly impacting performance in scenarios such as database queries, transaction processing, and small file access. In the Tokyo server environment, NVMe SSD random read IOPS typically reaches hundreds of thousands, while HDD random IOPS is usually below 1000. For OLTP loads such as MySQL and PostgreSQL, a minimum IOPS of 5000 is recommended; high-concurrency databases require over 10000.

Throughput: Measures the bandwidth capability of a storage device in sequential read/write scenarios, typically measured in MB/s or GB/s. High-end NVMe SSDs can achieve sequential read speeds exceeding 3500 MB/s and sequential write speeds exceeding 3000 MB/s. In enterprise deployments, the throughput of a single NVMe SSD can exceed several GB/s.

Latency: Measures the response time of a single I/O request and is a key factor affecting the overall response speed of an application. SSD P99 latency is typically within 1ms, reaching microsecond levels in extreme performance scenarios; while HDD latency can climb to tens of milliseconds in high-concurrency random read/write scenarios.

Real-world test data on hard drive speeds in Japanese cloud servers

Based on actual test data conducted in a Tokyo data center, NVMe SSDs demonstrate significant advantages across various metrics. In terms of random IOPS, NVMe SSDs typically achieve hundreds of thousands of random read IOPS and tens of thousands to hundreds of thousands of random write IOPS; SATA SSDs offer tens of thousands of IOPS; while HDDs only offer hundreds to thousands. Regarding latency, SSD P99 latency is typically between 1ms and a few milliseconds, while HDDs often experience latency peaks of tens of milliseconds in high-concurrency scenarios. In terms of sequential throughput, high-end HDDs can reach 200-300 MB/s per disk, SATA SSDs commonly reach 500-550 MB/s, while NVMe SSDs can easily exceed GB/s.

In 4KB random read/write tests, NVMe SSD read latency is approximately 10 microseconds, and write latency is as low as 5 microseconds, while traditional SATA SSDs have significantly higher latency. Some NVMe SSDs at Hengtian Cloud's Japanese nodes achieved 500K IOPS in random read/write tests. A 100% NVMe SSD array in a bare-metal server can achieve sequential read speeds of 7000 MB/s.

It is particularly important to understand the steady-state performance of NVMe SSDs, rather than their initial performance. New NVMe drives often perform better when they haven't undergone a large number of write/erase cycles than when they're in steady-state operation, because the inline garbage collection mechanism can impact IOPS once it's stable.

Methods for Checking and Testing Hard Drive Speed

Checking through the service provider's configuration list:

When purchasing a Japanese cloud server, the service provider usually indicates the storage type in the product specifications. Based on practical experience, pay attention to the following characteristics: If the storage interface listed in the configuration list is PCIe or NVMe, the instance supports NVMe SSDs; if it's listed as SATA or SAS, it's a SATA SSD; if it's only listed as SSD without specifying the interface type, it's recommended to confirm with customer service.

Checking the storage type of purchased instances through the cloud service provider's management console: Volume types can be viewed on the EBS Volumes page of the management console; managed disk types can be viewed on the Disk page of the Azure portal; persistent disk types can be viewed on the Disk page of the GCP console.

Real-world testing using the fio tool:

fio is an industry-standard I/O benchmarking tool that supports customizable read/write ratios, block sizes, queue depths, and other parameters. It allows direct testing of hard drive performance on Japanese cloud servers. Installation is as follows: Execute `apt install fio` or `yum install fio` on your Linux system. Before testing on a raw disk, please note: Do not perform destructive testing on a disk with an existing filesystem, as this may render the disk read-only. It is recommended to test on an unmounted, free disk, or use a test file instead of a raw device.

Typical test cases include:

Random 4K read/write test to measure IOPS and latency:

fio --name=randrw --rw=randrw --bs=4k --size=10G --numjobs=8 --time_based --runtime=60 --iodepth=32 --direct=1 --group_reporting

Sequential 1M read/write test to measure throughput:

fio --name=seqrw --rw=readwrite --bs=1m --size=10G --numjobs=4 --time_based --runtime=60 --iodepth=8 --direct=1 --group_reporting

After the test is executed, `fio` will output detailed data in three dimensions: IOPS, throughput, and latency, facilitating comparison and verification with nominal specifications.

Use the `dd` command for quick testing:

The `dd` command can be used to quickly evaluate sequential read/write speeds. Example:

dd if=/dev/zero of=test.out bs=1M count=1024 conv=fdatasync

The dd command is limited to sequential read/write throughput testing and cannot evaluate random IOPS and latency. It is recommended to use it only as a preliminary assessment tool.

Not all hard drives on Japanese cloud servers have the same speed level; the underlying storage architectures of different service providers vary. For small to medium-sized web applications and development testing environments, SATA SSDs are a good choice, with sequential read/write speeds of approximately 500 MB/s and random IOPS of approximately 50,000-80,000, which can meet daily load requirements. For scenarios requiring deployment in Tokyo nodes, handling high-frequency read/write operations, such as cross-border e-commerce platforms, real-time game backends, and log systems, NVMe SSDs are recommended. Their sequential read/write speeds of up to 3500 MB/s and random read/write capabilities of hundreds of thousands of IOPS can effectively ensure business stability. For scenarios with large file sequential read/write intensive operations, such as video transcoding, content distribution, and file servers, the focus should be on throughput rather than IOPS; a sequential read throughput of at least 1000 MB/s is recommended. Financial transaction systems and large OLTP databases with sufficient budgets and high latency sensitivity should prioritize disk types that support sub-millisecond latency.