Je, NVMe ni bora kuliko SSD kwenye VPS?

Je, NVMe ina umuhimu kwenye VPS?

NVMe ina umuhimu kwenye VPS pale programu yako inapofanya shughuli nyingi ndogo za kusoma na kuandika (reads and writes) na kusubiri kila moja ikamilike. Hii haileti mabadiliko makubwa kwa tovuti inayohudumia kurasa zilizohifadhiwa kwenye cache (cached pages), au kwa programu inayotumia muda wake kusubiri mtandao. Aina ya hifadhi ni kigezo kimoja tu. Hypervisor iliyo mbele ya diski, na wateja wengine wanaoshiriki seva moja (host), ndiyo huweka ukomo wa utendaji unaopata kihalisi.

Mabadiliko ya NVMe na yale yasiyobadilika

NVMe (non-volatile memory express) si aina ya flash memory. Ni itifaki na muunganisho unaotumika kufikia flash hiyo. Kifaa cha NVMe hukaa kwenye njia za PCIe (peripheral component interconnect express) na hutumia lugha ya NVMe. SSD ya SATA (serial ATA) hukaa kwenye link ya SATA na hutumia lugha ya AHCI (advanced host controller interface). Chips za kumbukumbu zinazohifadhi data zako zinaweza kuwa sawa katika vifaa vyote viwili.

Mambo mawili yanatofautiana, na yote yanahusu njia ya amri (command path) badala ya hifadhi yenyewe.

Foleni (Queues). AHCI huipa kernel foleni moja ya amri inayoshikilia amri 32. NVMe inaruhusu maelfu ya foleni, kwa kivitendo foleni moja kwa kila core ya CPU, kila moja ikiwa na kina kikubwa zaidi ya 32. Mchakato mmoja unaosoma block moja kwa wakati mmoja hauwezi kuona tofauti hiyo. Database yenye maombi 64 ya kusoma (reads) yaliyosubiri inaweza kuona: kwenye SATA, ombi la 33 husubiri nafasi kwenye foleni kabla ya kifaa kukiona, wakati kifaa cha NVMe hukubali yote na kuyafanyia kazi kwa pamoja.

Upana wa link (Link width). Link ya SATA III huenda kwa kasi ya 6 Gbit/s, ambayo ni takriban 550 MB/s ya data halisi baada ya kuondoa overhead ya itifaki. Hiyo ni kikomo kisichobadilika, bila kujali flash iliyopo nyuma yake. Njia nne za PCIe hubeba gigabytes kadhaa kwa sekunde, hivyo link huacha kuwa kikomo.

Latency ndipo matarajio yanapokosewa mara nyingi. Katika kina cha foleni (queue depth) cha 1, ikimaanisha ombi moja linaloshughulikiwa, SSD ya SATA hujibu usomaji wa 4k katika takriban microsecond 100 hadi 150. NVMe hujibu katika takriban 80 hadi 100. Zote ni za haraka, na hakuna unachokiendesha kitakachotambua tofauti hiyo kwa ombi moja. Pengo huonekana wakati wa concurrency. Queue depth, idadi ya maombi yanayoshughulikiwa kwa wakati mmoja, ndiyo mpangilio unaoamua kama media hizi mbili zinafanana au ni tofauti sana.

Network block storage ni darasa la tatu lenye fizikia tofauti. Uandikaji (write) huvuka mtandao kwenda kwenye storage cluster na huthibitishwa tu pale cluster inapopokea data hiyo, hivyo latency yake hupimwa kwa millisecond badala ya microsecond. Unachokipata kwa latency hiyo ni uimara (durability): volume hudumu zaidi ya host iliyounganishwa nayo, na inaweza kupigwa snapshot na kubadilishwa ukubwa.

Takwimu za kawaida zilizochapishwa: NVMe, SATA SSD na hifadhi ya mtandao

[
  {
    "disk": "Local NVMe SSD",
    "iops_4k_read": "184,000",
    "p99_latency_ms": 0.4,
    "seq_read_mbps": "3,400"
  },
  {
    "disk": "Local SATA SSD",
    "iops_4k_read": "90,000",
    "p99_latency_ms": 1.2,
    "seq_read_mbps": "550"
  },
  {
    "disk": "Network block storage",
    "iops_4k_read": "12,500",
    "p99_latency_ms": 6.5,
    "seq_read_mbps": "250"
  }
]

Kifaa cha NVMe cha ndani kwa kawaida hutoa 184,000 IOPS (operesheni za kuingiza/kutoa data kwa sekunde) za kusoma 4k bila mpangilio katika queue depth ya 32. Jaribio hilohilo kwenye SATA SSD hutoa karibu 90,000, likizuiliwa na queue moja ya AHCI na link ya 6 Gbit/s. Hifadhi ya block ya mtandao kwa kawaida hupunguzwa na mtoa huduma badala ya maunzi, na 12,500 ni kikomo cha kawaida kilichoorodheshwa.

Latency inaeleza jambo hilohilo katika kipimo ambacho watumiaji wako hukihisi. P99 read latency, ikimaanisha asilimia 1 ya maombi ya polepole zaidi, ni karibu 0.4 ms kwenye NVMe ya ndani na 1.2 ms kwenye SATA. Ukiweka mtandao kwenye njia hiyo, inakuwa 6.5 ms, zaidi ya mara kumi ya takwimu ya NVMe.

Sequential reads ndiyo pengo kubwa zaidi na lisilo na manufaa sana: 3,400 MB/s dhidi ya 550 MB/s. Karibu hakuna kitu kwenye seva kinachosoma faili kubwa moja mwanzo hadi mwisho kwa kasi kamili. Safu ya random na safu ya latency zinaelezea kile ambacho database, mail queue au package manager hufanya kwa uhalisia.

Ni kazi zipi zinazoathiriwa na diski

Kanuni moja inafafanua kazi hizi zote: kazi huathiriwa na diski pale tu inapongojea diski. Linux huhifadhi data ya faili iliyotumika hivi karibuni kwenye RAM, ndani ya page cache, hivyo usomaji wa pili wa faili haufiki kwenye hifadhi. Ikiwa data inayotumika inatoshea kwenye RAM, usomaji huwa ni usomaji wa kumbukumbu baada ya mara ya kwanza. Uandishi ni tofauti. Uandishi wowote ambao programu huufanyia flush kwa fsync() lazima uwe kwenye hifadhi thabiti kabla ya programu kuruhusiwa kuendelea.

Kazi zinazofanya commit. PostgreSQL, MySQL na SQLite huita fsync() au fdatasync() wakati wa commit, na kila commit husubiri kifaa kijibu. Kiwango cha commit cha muunganisho mmoja kwa hivyo huamuliwa na write latency, si kwa bandwidth. Kifaa kinachofanya flush kwa 0.2 ms huruhusu commit nyingi zaidi kwa sekunde kuliko kile kinachochukua 5 ms, na hakuna kiasi chochote cha throughput kinachoweza kubadilisha hilo. MySQL huonyesha hili kwenye error log wakati flush haiwezi kwenda kasi:

[Note] InnoDB: page_cleaner: 1000ms intended loop took 4589ms. The settings might not be optimal.

PostgreSQL huripoti hili kwenye mistari yake ya checkpoint, ambapo thamani kubwa ya sync= inamaanisha kuwa flush yenyewe ilikuwa ya polepole:

LOG:  checkpoint complete: wrote 8192 buffers (25.0%); write=27.694 s, sync=11.207 s, total=39.001 s

Kazi zinazogusa faili nyingi ndogo. Kila faili hubeba shughuli za metadata ambazo usomaji mmoja mkubwa wa mfululizo hauna. npm install, git clone ya repository kubwa, kufungua container images, Maildir mail store na backup inayopitia mti mkubwa wa faili zote hutumia muda wake kwenye random access ndogo. Kazi ya restic backup kwenye VPS husoma na kufanya hashing ya kila faili ambayo haijaiona awali, kwa hivyo muda wa saa wa backup ya zaidi ya faili milioni moja hufuata kwa karibu random read latency. Hali hiyo ni kweli kwa du -sh, ambayo husoma metadata pekee na si kingine.

Database zinazozidi ukubwa wa RAM pia huangukia hapa. Mara tu index inapokosa kutoshea kwenye page cache, kila lookup huwa ni random read, na diski hurudi kwenye critical path.

Ni workloads zipi hazioni tofauti ya diski

Blogu au tovuti ndogo ya kampuni. Kurasa zake ni ndogo, page cache huhifadhi kurasa zote baada ya ombi la kwanza, na kikwazo kikubwa huwa ni CPU kwa ajili ya rendering au bandwidth kwa ajili ya assets. LAMP stack kwenye Ubuntu 24.04 inayohudumia tovuti yenye trafiki ndogo haifanyi disk IO yoyote baada ya kuwa "warm".

Media streaming. Stream moja ya 4K kwa 40 Mbit/s husoma 5 MB/s. Streams kumi husoma 50 MB/s, kasi ambayo hata network block storage inaweza kuitoa bila shida. Jellyfin media server kwenye VPS hupata kikwazo kutokana na allowance yako ya network egress, na CPU wakati wa transcoding, si kutokana na aina ya storage.

Local model inference. Kuendesha Ollama kwenye VPS kwa ajili ya self-hosting ya LLM husoma faili la model mara moja, kisha hufanya kazi ndani ya RAM. NVMe hupunguza muda wa kupakia model ya 20 GB kutoka dakika hadi sekunde. Hii haibadilishi kasi ya tokens kwa sekunde, ambayo hutegemea memory bandwidth na CPU.

Huduma yoyote inayongojea huduma ya nje. Worker inayotumia 800 ms kwa kila kazi kusubiri HTTP request haitafanya kazi haraka zaidi kwa kutumia diski bora.

Kwa nini hypervisor ni muhimu kama ilivyo medium

Huwasiliani na kifaa moja kwa moja. Unawasiliana na diski pepe inayowasilishwa na hypervisor, kwa kawaida kupitia virtio, na maamuzi kadhaa katika safu hiyo ni muhimu zaidi kuliko NVMe dhidi ya SATA.

Huwezi kuona medium ukiwa ndani ya guest. lsblk -d -o NAME,ROTA,SIZE,MODEL inaonyesha vda ikiwa na model tupu, kwa sababu virtio haipitishi utambulisho wa diski. cat /sys/block/vda/queue/rotational inaripoti kile ambacho hypervisor inatangaza, kwa hivyo 0 hapo si uthibitisho wa flash. nvme list, kutoka kwenye kifurushi cha nvme-cli, haiorodheshi chochote kwenye VPS nyingi hata kama host imejaa diski za NVMe, kwa sababu diski yako ni kifaa cha virtio na si kifaa cha NVMe. Mpango unaosema NVMe kwa kawaida unaelezea kile ambacho host inacho. Volume yako inaweza bado kuwa imeunganishwa kupitia mtandao.

Host cache mode inabadilisha namba zaidi kuliko medium. Kwa kutumia writeback caching kwenye host, fsync() ya guest inaweza kurejesha majibu mara tu host inapokuwa na data kwenye RAM yake yenyewe. Hilo hutoa matokeo ya benchmark ambayo kifaa chochote cha kimwili hakiwezi kutoa. Pia inamaanisha kuwa crash ya host inaweza kupoteza data zilizoandikwa ambazo database yako inaamini kuwa ziko salama. Kwa cache mode ya none, namba huwa chini na za kweli.

Caps na burst credits. Watoa huduma wengi huweka kikomo cha IOPS kwa kila volume au kila mpango, na volumes nyingi za mtandao hutumia burst allowance. Burst allowance ni akiba ya credits: volume huenda kwa kasi wakati credits zipo, kisha hushuka hadi kiwango cha chini cha msingi. Dalili hii ni rahisi kuitambua. Uingizaji (import) au urejeshaji (restore) huenda haraka kwa dakika kadhaa, kisha hupungua kasi ghafla na kubaki polepole, bila kitu chochote kubadilika kwenye configuration yako. Umetumia credits hizo.

Majirani. Kwenye host inayoshirikiwa, latency ya diski yako hubadilika kulingana na kile ambacho guests wengine wanafanya. Hii ndiyo sababu ya kupima zaidi ya mara moja. Fanya jaribio lilelile asubuhi na tena jioni, kisha ulinganishe tofauti. Kwenye host yenye shughuli nyingi, tofauti kati ya majaribio mawili kwenye volume moja mara nyingi huwa kubwa kuliko tofauti iliyochapishwa kati ya media mbili.

Jinsi ya kupima diski iliyo kwenye VPS yako

Sakinisha fio, zana ya kawaida ya kupima IO, kisha ufanye vipimo. Zingatia maonyo matatu kwanza. Jaribio hili hutengeneza faili, kwa hivyo linatumia nafasi ya diski na linahesabika katika kikomo chochote cha IOPS unachotozwa. Weka muda wa majaribio uwe mfupi. Usiendeshe jaribio kwa queue depth kamili kwenye diski inayohudumia trafiki ya moja kwa moja, kwa sababu utashindana na programu yako mwenyewe.

sudo apt update && sudo apt install -y fio ioping sysstat
cd /var/tmp

Random read kwa queue depth ya 32, ambayo ndiyo kina kinachotumiwa na watoa huduma:

fio --name=randread --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 \
  --runtime=30 --time_based --group_reporting

Mstari muhimu unaanza na read:

  read: IOPS=184k, BW=719MiB/s (754MB/s)(21.1GiB/30001msec)

--direct=1 hupita pembeni ya guest page cache, kwa hivyo matokeo yanaelezea kifaa badala ya RAM yako. Ukiiondoa utapima kumbukumbu, jambo litakalotoa namba ambayo hakuna diski inayoweza kuifikia. Tumia --size=4G au kubwa zaidi ikiwa una nafasi, kwa sababu faili ya 1G inaweza kukaa yote ndani ya cache ya host na kutoa matokeo ya uongo.

Queue depth ya 1 inaonyesha latency ya moja kwa moja, ambayo ndiyo hali inayohisiwa na mchakato wa single-threaded:

fio --name=lat --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based

Jaribio la commit hutabiri tabia ya database. Huandika 4k na kuita fdatasync() baada ya kila uandishi, kwa hivyo kiwango kilichoripotiwa kinajumuisha flush:

fio --name=commit --filename=fio.test --size=1G --bs=4k --rw=randwrite \
  --ioengine=psync --fdatasync=1 --runtime=30 --time_based
rm -f fio.test

Takwimu ya IOPS kutoka kwa jaribio hilo inakaribia namba ya juu zaidi ya miamala midogo kwa sekunde ambayo muunganisho mmoja wa database unaweza kufanya commit, kwa sababu commit husubiri flush hiyo hiyo.

Kwa sampuli ya haraka bila kutumia fio:

ioping -c 20 .

--- . (ext4 /dev/vda1) ioping statistics ---
19 requests completed in 4.13 ms, 76 KiB read, 4.60 k iops, 17.9 MiB/s
min/avg/max/mdev = 174.2 us / 217.6 us / 386.1 us / 51.3 us

Thamani ya mdev, ambayo ni mean deviation, ina umuhimu sawa na wastani. Mkengeuko mkubwa kwenye seva isiyo na shughuli unamaanisha kuwa storage backend inashirikiwa na ina shughuli nyingi.

Jinsi ya kusoma matokeo

Kufikia Julai 2026, hizi ni thamani zinazokubalika kwa VPS ndogo. IOPS elfu makumi kadhaa za 4k random read katika queue depth ya 32, na latency ya chini ya 0.3 ms katika queue depth ya 1, ni viashiria vya flash ya ndani. Latency ya milisekunde kadhaa katika queue depth ya 1 inamaanisha kuna njia ya mtandao, bila kujali jina la mpango huo. Sequential reads zinazosimama karibu na 550 MB/s ni alama ya kiungo cha SATA. Namba iliyo juu sana kuliko uwezo wa kifaa chochote kimoja inamaanisha kuna caching kwenye njia hiyo, ambayo karibu kila mara huwa kwenye host.

Ili kuona kile ambacho workload yako ya sasa inafanya kwenye diski:

iostat -x 1 3
vmstat 1 5
cat /proc/pressure/io

Katika matokeo ya iostat -x, soma r_await na w_await, ambazo ni wastani wa milisekunde ambazo ombi lililazimika kusubiri, na aqu-sz, ambayo ni wastani wa urefu wa foleni (queue length). Puuza %util kwenye diski ya mtandaoni (virtual disk). Inaripoti sehemu ya muda ambapo angalau ombi moja lilikuwa likisubiri, jambo ambalo halisemi chochote kuhusu msongamano kwenye kifaa kinachohudumia maombi mengi kwa wakati mmoja; kwa hivyo %util ya 100 pamoja na r_await ya 0.2 ms ni diski yenye afya na inayofanya kazi vizuri. Katika vmstat, safu ya wa ni asilimia ya muda wa CPU uliotumika kusubiri IO. Ikiwa /proc/pressure/io ipo kwenye kernel yako, thamani yake ya some avg10= ni sehemu ya sekunde 10 zilizopita ambapo angalau kazi moja ilikwama kwenye IO, ambayo ndiyo jibu la moja kwa moja kwa swali la kama hifadhi (storage) ndiyo kikwazo chako.

Jinsi VPS inayokabiliwa na kikomo cha diski inavyoonekana

Load average ya juu huku CPU ikiwa haitumiki na wa kubwa katika vmstat inamaanisha kuwa michakato (processes) imepangwa kwenye foleni ikisubiri diski. Ishara iliyo wazi zaidi kutoka kwa kernel ni ujumbe huu katika dmesg -T:

INFO: task jbd2/vda1-8:194 blocked for more than 120 seconds.

Mstari huo unaonekana kwa sababu thread ya kernel ilisubiri zaidi ya dakika mbili kwa hifadhi (storage) kujibu, hivyo hung task watchdog ikauandika kwenye logi. jbd2 ni thread ya journal ya ext4, jambo linalomaanisha kuwa mfumo mzima wa faili ulikuwa unasubiri, si programu moja iliyoharibika. Kwenye VPS, hii kwa kawaida huashiria matatizo kwenye storage backend au kikomo cha IOPS kilichofikiwa.

Dalili za programu hufuata mtindo uleule. Muda wa wastani wa majibu (median response time) unabaki kuwa wa kuridhisha wakati maombi ya polepole zaidi yakionyesha ucheleweshaji mkubwa, kwa sababu ni maombi yanayohitaji diski pekee ndiyo yanayoathirika. apt upgrade hukwama kwenye Unpacking kwa dakika kadhaa, kwa sababu dpkg hufanya flush wakati wa kuandika. git status katika hazina (repository) kubwa huchukua sekunde nyingi. Hizi ni gharama za metadata na flush, hivyo kuongeza bandwidth hakutasaidia.

Nini cha kufanya wakati diski imefika kikomo

Nunua RAM kabla ya kununua IOPS. Ikiwa data inayotumika inatoshea kwenye page cache, usomaji huacha kufika kwenye diski kabisa. Kuongeza kumbukumbu mara nyingi ni bora kuliko kuhamia kwenye hifadhi ya kasi zaidi, na kwa kawaida hugharimu kidogo.

Punguza idadi ya flushes, pale data inaporuhusu. Katika PostgreSQL, synchronous_commit = off inaruhusu commit kurudi kabla ya data kuandikwa kwenye diski. Unaweza kupoteza sehemu ndogo ya mwisho ya miamala ikiwa seva itakufa. Database haiharibiki, kwa sababu write-ahead log bado inaandikwa kwa mpangilio. Biashara hiyo inafaa kwa nakala ya uchanganuzi na si sahihi kwa malipo. innodb_flush_log_at_trx_commit = 2 katika MySQL ni biashara ileile.

Fanya batch ya faili ndogo. Uhamishaji au backup ya mamilioni ya faili ndogo hutawaliwa na gharama ya kila faili, kwa hivyo kuhifadhi kwenye archive kwanza na kuhamisha mkondo mmoja ni haraka kwenye hifadhi yenye latency ya juu kuliko kunakili mti wa faili moja baada ya nyingine.

Weka discard ikifanya kazi kwenye thin volumes. Kwenye hifadhi ya thin provisioned, backend haijui kama block iko wazi hadi filesystem itakaposema hivyo, na volume ambayo haijawahi kufanyiwa trim hupoteza kasi ya uandishi polepole. Ubuntu inakuja na timer ya kila wiki kwa ajili ya hili:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av huchapisha baiti zilizofanyiwa trim kwa kila mount point. Ujumbe unaosema kuwa operesheni ya discard haitumiki inamaanisha kuwa diski ya mtandaoni haipitishi discard kwa host, kwa hivyo hakuna kitu unachoweza kurekebisha.

Ruka marekebisho ya IO scheduler. Kwenye diski ya virtio, cat /sys/block/vda/queue/scheduler kwa kawaida huonyesha none tayari, na scheduling halisi hutokea kwenye host, ambapo huna ufikiaji. Ruka noatime pia: Ubuntu hufanya mount na relatime kwa chaguo-msingi, ambayo tayari huepuka karibu kila uandishi wa atime.

Kuchagua mpango

Lipa kwa ajili ya NVMe wakati database, mail server, CI runner au build inayotumia vifurushi vingi inapoishi kwenye seva. Usilipe gharama ya ziada kwa ajili ya tovuti iliyohifadhiwa kwenye cache au programu ambayo muda wake mwingi hutumika kwenye maombi ya nje. Ikiwa huna uhakika, diski mara nyingi si kikwazo chako, kwa sababu mzigo wa kazi wa VPS ndogo nyingi huishiwa na RAM au bandwidth kwanza.

Pima siku ya kwanza, wakati unafanya kazi kupitia dakika kumi za kwanza kwenye VPS mpya, na uhifadhi matokeo kwenye faili. Baseline ndiyo njia unayotumia baadaye kuthibitisha kuwa mwenyeji (host) amepungua kasi badala ya msimbo wako. Pendelea watoa huduma wanaoeleza daraja la hifadhi na kikomo chochote cha IOPS kwa maandishi. Ikiwa mpango unasema NVMe na usomaji wa queue depth 1 unachukua 4 ms, una hifadhi ya mtandao kwenye host yenye NVMe. Hilo ni jambo la haki kuuza, na jambo tofauti kununua.

FAQ

Je, NVMe huwa na kasi zaidi kuliko SATA SSD kwenye VPS?

Hapana. Katika queue depth ya 1, zote mbili zinafanana, takriban mikrosekunde 80 hadi 150 kwa usomaji wa 4k, na programu inayotumia thread moja haiwezi kuzitofautisha. NVMe hupata faida wakati maombi mengi yanapokuwa hewani, kwa sababu AHCI hutoa queue moja yenye uwezo wa amri 32, wakati NVMe hutoa maelfu ya queue zenye kina kirefu zaidi. Kwenye seva ya pamoja, mzigo kutoka kwa watumiaji wengine unaweza kuathiri latency yako zaidi kuliko aina ya diski, kwa hivyo pima ujazo wako mwenyewe kwa kutumia fio badala ya kusoma jina la mpango wa huduma.

Ninawezaje kuhakiki kama VPS yangu inatumia NVMe kweli?

Huwezi kuhakiki moja kwa moja, kwa sababu virtio huficha kifaa cha kimwili. lsblk huonyesha vda bila kamba ya mfano (model string), nvme list hairudishi chochote, na /sys/block/vda/queue/rotational huripoti tu kile ambacho hypervisor inatangaza. Pima tabia ya diski badala yake. Usomaji wa 4k random wenye queue depth ya 1 chini ya 0.3 ms inamaanisha flash ya ndani. Milisekunde kadhaa inamaanisha kuna network hop kwenye njia hiyo. Usomaji wa mfululizo (sequential) unaoishia karibu na 550 MB/s unaashiria kiungo cha SATA.

Je, NVMe hufanya tovuti yangu kupakia haraka zaidi?

Kwa kawaida hapana. Baada ya ombi la kwanza, Linux huhudumia faili kutoka kwenye page cache iliyo kwenye RAM, kwa hivyo diski hubaki bila kazi. Kasi ya ukurasa kwenye VPS ndogo kwa kawaida hufungwa na muda wa CPU wa programu na bandwidth. Diski hurudi kwenye njia muhimu (critical path) ikiwa tovuti huandika kwenye kila ombi, kwa mfano database ya mkokoteni (cart) inayofanya commit mara kwa mara, kwa sababu kila commit husubiri flush ikamilike.

Ni matokeo gani mazuri ya fio kwa VPS?

Kufikia Julai 2026, VPS ndogo kwenye flash ya ndani kwa kawaida hurudisha makumi ya maelfu ya 4k random read IOPS kwenye queue depth ya 32, na latency ya queue depth ya 1 chini ya 0.3 ms. Hifadhi ya mtandao (network block storage) kwa kawaida hurudisha maelfu machache ya IOPS kwa latency ya milisekunde chache. Endesha jaribio mara tatu kwa saa tofauti. Tofauti kubwa kati ya majaribio inakuambia zaidi kuliko wastani, kwa sababu inaonyesha jinsi watumiaji wengine kwenye seva hiyo wanavyokuathiri.

Je, niweke database yangu kwenye network block storage?

Unaweza, na huduma nyingi zilizosimamiwa hufanya hivyo, lakini njia ya commit hulipia gharama hiyo. Kila flush huvuka mtandao, kwa hivyo muunganisho mmoja hufanya commit ya miamala midogo michache kwa sekunde kuliko ingekuwa kwenye flash ya ndani. Unapata uimara (durability) unaoweza kuhimili kupotea kwa seva badala yake. Ikiwa utachagua hifadhi ya mtandao kwa database inayofanya uandishi mwingi, panga kazi katika miamala mikubwa zaidi ili flush chache zibebe safu nyingi zaidi.