VPS में NVMe बनाम SSD: क्या सच में फर्क है?

क्या VPS पर NVMe का महत्व है?

VPS पर NVMe तब महत्वपूर्ण होता है, जब आपका software कई छोटे read और write अनुरोध भेजता है और हर अनुरोध के पूरा होने की प्रतीक्षा करता है। Cached pages परोसने वाली site के लिए इसका प्रभाव बहुत कम होता है। ऐसे program के लिए भी इसका प्रभाव बहुत कम होता है, जो अपना समय network की प्रतीक्षा में बिताता है। Storage medium केवल एक कारक है। Disk के सामने मौजूद hypervisor और उसी host को साझा करने वाले अन्य guests आपकी वास्तविक अधिकतम performance निर्धारित करते हैं।

NVMe क्या बदलता है, और क्या नहीं

NVMe (non-volatile memory express) flash memory का कोई प्रकार नहीं है। यह flash तक पहुंचने के लिए उपयोग किया जाने वाला protocol और connection है। NVMe device PCIe (peripheral component interconnect express) lanes पर जुड़ा होता है और NVMe protocol का उपयोग करता है। SATA (serial ATA) SSD SATA link पर जुड़ा होता है और AHCI (advanced host controller interface) का उपयोग करता है। आपके bytes रखने वाली memory chips दोनों में एक जैसी हो सकती हैं।

दो चीज़ें अलग होती हैं, और दोनों storage से अधिक command path से संबंधित हैं।

Queues। AHCI kernel को एक command queue देता है, जिसमें 32 commands रखे जा सकते हैं। NVMe हजारों queues की अनुमति देता है। व्यवहार में प्रत्येक CPU core के लिए एक queue हो सकती है, और प्रत्येक queue 32 से कहीं अधिक गहरी होती है। एक process जो एक समय में एक block पढ़ता है, वह यह अंतर नहीं देख सकता। 64 reads लंबित रखने वाला database इसे देख सकता है: SATA पर 33rd request queue slot के लिए प्रतीक्षा करती है, device के उसे देखने से पहले ही, जबकि NVMe device सभी requests स्वीकार करके उन पर एक साथ काम करता है।

Link width। SATA III link 6 Gbit/s की गति से चलता है। Protocol overhead के बाद वास्तविक data की गति लगभग 550 MB/s होती है। यह एक निश्चित सीमा है, चाहे इसके पीछे कोई भी flash लगा हो। Four PCIe lanes कई gigabytes per second ले जाती हैं, इसलिए link सीमा नहीं रह जाता।

Latency में अपेक्षाएँ आमतौर पर गलत होती हैं। Queue depth 1 पर, यानी एक समय में केवल एक request चल रही हो, SATA SSD 4k read का उत्तर लगभग 100 से 150 microseconds में देता है। NVMe लगभग 80 से 100 microseconds में उत्तर देता है। दोनों तेज़ हैं, और आपके द्वारा चलाया जाने वाला कोई भी काम एक request पर यह अंतर महसूस नहीं करेगा। Concurrency बढ़ने पर अंतर स्पष्ट होता है। Queue depth, यानी एक समय में चल रही requests की संख्या, यह तय करती है कि दोनों media एक जैसे दिखेंगे या बहुत अलग।

Network block storage अलग physics वाली तीसरी श्रेणी है। Write network के माध्यम से storage cluster तक जाती है और केवल तब acknowledge होती है जब cluster उसे अपने पास रख लेता है। इसलिए इसकी latency microseconds के बजाय milliseconds में मापी जाती है। इस latency के बदले आपको durability मिलती है: volume उस host से अधिक समय तक बना रहता है जिससे वह attached है, और उसका snapshot लिया तथा उसका आकार बदला जा सकता है।

सामान्य प्रकाशित आंकड़े: NVMe, SATA SSD और नेटवर्क स्टोरेज

[
  {
    "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"
  }
]

एक स्थानीय NVMe डिवाइस को queue depth 32 पर सामान्यतः 184,000 random 4k read IOPS (input/output operations per second) के लिए उद्धृत किया जाता है। SATA SSD पर यही परीक्षण लगभग 90,000 का परिणाम देता है। इसका प्रदर्शन single AHCI queue और 6 Gbit/s link से सीमित रहता है। Network block storage आमतौर पर hardware के बजाय provider द्वारा सीमित होता है, और 12,500 एक सामान्य documented ceiling है।

Latency उसी बात को उस इकाई में दिखाती है जिसे आपके users महसूस करते हैं। p99 read latency, अर्थात requests के सबसे धीमे 1 प्रतिशत की latency, स्थानीय NVMe पर लगभग 0.4 ms और SATA पर 1.2 ms होती है। Path में network जोड़ने पर यह 6.5 ms हो जाती है, जो NVMe के आंकड़े से दस गुना से अधिक है।

Sequential reads में अंतर सबसे बड़ा होता है, लेकिन यह सबसे कम उपयोगी माप है: 3,400 MB/s की तुलना में 550 MB/s। Server पर लगभग कोई भी प्रक्रिया एक बड़ी file को शुरू से अंत तक पूरी गति से नहीं पढ़ती। Random column और latency column बताते हैं कि database, mail queue या package manager वास्तव में क्या करता है।

डिस्क को प्रभावित करने वाले वर्कलोड

एक नियम इन सभी को समझाता है: कोई वर्कलोड तभी डिस्क के प्रभाव को महसूस करता है, जब वह डिस्क के लिए प्रतीक्षा करता है। Linux हाल ही में उपयोग किए गए फ़ाइल डेटा को RAM में page cache में रखता है, इसलिए किसी फ़ाइल का दूसरा read storage तक नहीं पहुंचता। यदि working set, यानी वास्तव में उपयोग में आने वाला डेटा, RAM में समा जाता है, तो पहली बार पढ़ने के बाद reads memory reads बन जाते हैं। Writes अलग होते हैं। Application द्वारा fsync() से flush की गई प्रत्येक write stable storage पर होनी चाहिए, तभी application को आगे बढ़ने की अनुमति मिलती है।

Commit करने वाला work। PostgreSQL, MySQL और SQLite commit पर fsync() या fdatasync() को call करते हैं, और प्रत्येक commit device के उत्तर की प्रतीक्षा करता है। इसलिए एक connection की commit rate bandwidth से नहीं, बल्कि write latency से निर्धारित होती है। 0.2 ms में flush करने वाला device, 5 ms लेने वाले device की तुलना में प्रति सेकंड कहीं अधिक commits की अनुमति देता है। Throughput की कोई भी मात्रा इस अंतर को नहीं बदलती। जब flush की गति पर्याप्त नहीं रहती, तो MySQL error log में यह दर्ज करता है:

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

PostgreSQL इसे अपनी checkpoint lines में report करता है। वहां बड़ा sync= value बताता है कि flush स्वयं धीमा था:

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

कई छोटी files को छूने वाला work। प्रत्येक file में metadata operations होते हैं, जो एक बड़े sequential read में नहीं होते। npm install, git clone किसी बड़े repository के, container images को unpack करना, Maildir mail store और बड़े tree पर चलने वाला backup अपना समय छोटे random access पर खर्च करते हैं। किसी VPS पर restic backup job में पहले से न देखी गई प्रत्येक file को read और hash किया जाता है। इसलिए million files वाले backup का wall-clock time random read latency के साथ closely track करता है। यही बात du -sh पर भी लागू होती है, जो केवल metadata read करता है।

जो databases RAM से बड़े हो जाते हैं, वे भी इसी श्रेणी में आते हैं। जब index page cache में fit नहीं होता, तो प्रत्येक lookup random read बन जाता है और disk फिर से critical path में आ जाती है।

किन वर्कलोड पर डिस्क का प्रभाव नहीं पड़ता

ब्लॉग या छोटी कंपनी की साइट। पृष्ठ छोटे होते हैं। पहले अनुरोध के बाद page cache में सभी पृष्ठ आ जाते हैं। सीमा rendering के लिए CPU या assets के लिए bandwidth होती है। कम ट्रैफ़िक वाली साइट पर Ubuntu 24.04 पर LAMP stack warm होने के बाद लगभग कोई disk IO नहीं करती।

Media streaming। एक 4K stream 40 Mbit/s पर 5 MB/s पढ़ती है। ऐसी दस streams 50 MB/s पढ़ती हैं। Network block storage भी इसे आसानी से संभाल लेता है। VPS पर Jellyfin media server की सीमा आपके network egress allowance और transcoding के समय CPU से निर्धारित होती है, storage medium से नहीं।

Local model inference। LLM को self-host करने के लिए VPS पर Ollama चलाना model file को एक बार पढ़ता है और उसके बाद RAM में काम करता है। NVMe, 20 GB model के load time को minutes से seconds तक घटा देता है। इससे tokens per second नहीं बदलते, क्योंकि यह memory bandwidth और CPU पर निर्भर होता है।

ऐसा कोई भी कार्य जो external service की प्रतीक्षा करता है। जो worker प्रत्येक job में HTTP request पर 800 ms खर्च करता है, वह बेहतर disk पर तेज नहीं चलेगा।

माध्यम जितना महत्वपूर्ण है, हाइपरवाइज़र भी उतना ही महत्वपूर्ण है

आप सीधे डिवाइस से संपर्क नहीं करते। आप उस वर्चुअल डिस्क से संपर्क करते हैं जिसे हाइपरवाइज़र प्रस्तुत करता है, आमतौर पर virtio के माध्यम से। इस परत के कई निर्णय NVMe और SATA के बीच के अंतर से अधिक महत्वपूर्ण होते हैं।

आप guest के अंदर से माध्यम को नहीं देख सकते। lsblk -d -o NAME,ROTA,SIZE,MODEL, खाली model के साथ vda दिखाता है, क्योंकि virtio ड्राइव की पहचान को आगे नहीं भेजता। cat /sys/block/vda/queue/rotational वह जानकारी दिखाता है जिसका हाइपरवाइज़र विज्ञापन करता है, इसलिए वहां 0 होना flash का प्रमाण नहीं है। nvme list, nvme-cli package से, अधिकांश VPS पर कुछ भी सूचीबद्ध नहीं करता, भले ही host में बहुत से NVMe drives हों, क्योंकि आपकी disk virtio device है, NVMe device नहीं। जिस plan में NVMe लिखा होता है, वह आमतौर पर host में मौजूद हार्डवेयर का वर्णन करता है। आपका volume फिर भी network attached हो सकता है।

Host cache mode, माध्यम की तुलना में, संख्याओं को अधिक बदलता है। Host पर writeback caching चालू होने पर, guest का fsync() तब लौट सकता है जब host ने data को अपनी RAM में रख लिया हो। इससे ऐसा benchmark परिणाम मिलता है जिसे कोई भौतिक device दे ही नहीं सकता। इसका अर्थ यह भी है कि host crash होने पर वे writes खो सकती हैं जिन्हें आपका database सुरक्षित मानता है। none cache mode में संख्याएं कम और वास्तविक होती हैं।

सीमाएं और burst credits। कई providers प्रति volume या plan IOPS की सीमा लगाते हैं। कई network volumes burst allowance का उपयोग करते हैं। Burst allowance credits का एक pool होता है। Credits उपलब्ध रहने तक volume तेज चलता है। उसके बाद वह बहुत कम baseline पर आ जाता है। इसका लक्षण आसानी से पहचाना जा सकता है। कोई import या restore कई मिनट तक तेजी से चलता है। फिर वह अचानक बहुत धीमा हो जाता है और धीमा ही रहता है, जबकि आपके configuration में कोई बदलाव नहीं हुआ है। आपके credits समाप्त हो गए।

अन्य users। Shared host पर आपकी disk latency इस बात के अनुसार बदलती है कि अन्य guests क्या कर रहे हैं। इसी कारण एक से अधिक बार measurement करना चाहिए। वही test सुबह चलाएं और फिर शाम को चलाएं। इसके बाद दोनों परिणामों के अंतर की तुलना करें। Busy host पर उसी volume पर दो runs के बीच का अंतर अक्सर दो माध्यमों के प्रकाशित अंतर से भी बड़ा होता है।

आपके VPS में वास्तव में उपलब्ध डिस्क को कैसे मापें

मानक IO बेंचमार्क fio इंस्टॉल करें और माप लें। पहले तीन सावधानियां ध्यान रखें। यह परीक्षण एक फ़ाइल बनाता है, इसलिए यह डिस्क स्थान का उपयोग करता है और आपके बिल में शामिल किसी भी IOPS सीमा में गिना जाता है। रन छोटे रखें। जिस वॉल्यूम से लाइव ट्रैफ़िक संभाला जा रहा हो, उस पर इसे पूर्ण queue depth के साथ न चलाएं, क्योंकि इससे आपका अपना एप्लिकेशन उसी संसाधन के लिए प्रतिस्पर्धा करेगा।

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

queue depth 32 पर रैंडम रीड, जो vendors द्वारा बताई जाने वाली depth है:

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

महत्वपूर्ण पंक्ति read: से शुरू होती है।

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

--direct=1 guest page cache को बायपास करता है, इसलिए परिणाम आपकी RAM के बजाय device का वर्णन करता है। इसे हटाने पर आप memory को मापेंगे, जो ऐसा परिणाम देती है जिसे कोई disk प्राप्त नहीं कर सकती। यदि आपके पास पर्याप्त स्थान है, तो --size=4G या उससे बड़ी value का उपयोग करें, क्योंकि 1G फ़ाइल पूरी तरह host के cache में रह सकती है और परिणाम को वास्तविकता से बेहतर दिखा सकती है।

queue depth 1 raw latency दिखाता है, जिसे single-threaded process अनुभव करता है:

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

commit test database के व्यवहार का अनुमान देता है। यह 4k लिखता है और हर write के बाद fdatasync() को call करता है, इसलिए रिपोर्ट की गई दर में 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

उस रन का IOPS आंकड़ा लगभग उस छोटे transactions प्रति सेकंड की अधिकतम संख्या के बराबर होता है जिसे एक database connection commit कर सकता है, क्योंकि commit उसी flush के पूरा होने की प्रतीक्षा करता है।

fio के बिना त्वरित sample के लिए:

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

mdev value, यानी mean deviation, average जितनी ही महत्वपूर्ण है। निष्क्रिय box पर बड़ा deviation यह दर्शाता है कि storage backend साझा है और व्यस्त है।

परिणाम कैसे पढ़ें

July 2026 तक, छोटे VPS के लिए ये उचित निष्कर्ष हैं। Queue depth 32 पर 4k random read के दसियों हजार IOPS और queue depth 1 पर लगभग 0.3 ms से कम latency, local flash के अनुरूप हैं। Queue depth 1 पर कई milliseconds की latency का अर्थ network path है, चाहे plan का नाम कुछ भी हो। Sequential read का लगभग 550 MB/s पर रुकना SATA link का संकेत है। किसी एक device की क्षमता से बहुत अधिक संख्या का अर्थ है कि path में caching मौजूद है, लगभग हमेशा host पर।

यह देखने के लिए कि आपका live workload disk पर क्या प्रभाव डाल रहा है:

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

iostat -x output में r_await और w_await पढ़ें। ये request के लिए प्रतीक्षा किए गए औसत milliseconds हैं। aqu-sz औसत queue length है। Virtual disk पर %util को अनदेखा करें। यह उस समय का अनुपात बताता है जिसमें कम से कम एक request लंबित थी। इससे ऐसे device पर saturation का पता नहीं चलता जो एक साथ कई requests पूरी करता है। इसलिए r_await 0.2 ms के साथ %util का 100 होना व्यस्त लेकिन स्वस्थ disk को दर्शाता है। vmstat में wa column, IO की प्रतीक्षा में बिताए गए CPU time का प्रतिशत है। यदि आपके kernel में /proc/pressure/io मौजूद है, तो उसका some avg10= value पिछले 10 seconds में उस समय का अनुपात है जिसमें कम से कम एक task IO पर अटका था। इससे सबसे सीधे पता चलता है कि storage आपका bottleneck है या नहीं।

डिस्क-निर्भर VPS कैसा दिखता है

Idle CPU के साथ high load average और vmstat में बड़ा wa यह दर्शाता है कि processes disk के पीछे queue में हैं। Kernel का सबसे स्पष्ट signal dmesg -T में यह message है:

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

यह line इसलिए दिखाई देती है क्योंकि एक kernel thread ने storage के उत्तर की प्रतीक्षा 2 मिनट से अधिक की। इसलिए hung task watchdog ने इसे log किया। jbd2 ext4 journal thread है। इसका अर्थ है कि पूरा filesystem प्रतीक्षा कर रहा था, न कि केवल कोई गलत तरीके से चल रहा program। VPS पर यह आमतौर पर storage backend या समाप्त हो चुके IOPS allowance की ओर संकेत करता है।

Application के symptoms भी यही pattern दिखाते हैं। Median response time स्वीकार्य रहता है, जबकि सबसे धीमे requests की tail लंबी होती जाती है। ऐसा इसलिए होता है क्योंकि केवल वे requests disk access पर निर्भर होते हैं। apt upgrade Unpacking पर कई मिनट तक रहता है, क्योंकि dpkg लिखते समय data flush करता है। बड़े repository में git status को seconds लगते हैं। ये metadata और flush costs हैं। इसलिए अधिक bandwidth से समस्या हल नहीं होगी।

जब डिस्क सीमा बन जाए तो क्या करें

IOPS खरीदने से पहले RAM खरीदें। यदि working set page cache में समा जाता है, तो reads डिस्क तक पहुंचते ही नहीं हैं। Memory को दोगुना करना अक्सर तेज storage class पर जाने से अधिक प्रभावी होता है और आमतौर पर इसकी लागत भी कम होती है।

जहां data इसकी अनुमति दे, वहां flush की संख्या घटाएं। PostgreSQL में, synchronous_commit = off commit को write के डिस्क पर पहुंचने से पहले लौटने देता है। यदि server बंद हो जाए, तो आप transactions के अंतिम fraction of a second को खो सकते हैं। Database corrupt नहीं होता, क्योंकि write-ahead log अब भी क्रम में लिखा जाता है। यह trade analytics copy के लिए सही है, लेकिन payments के लिए गलत है। MySQL में innodb_flush_log_at_trx_commit = 2 भी यही trade है।

छोटी files को batch करें। एक million छोटी files का transfer या backup per-file cost से प्रभावित होता है। इसलिए पहले archive बनाकर एक stream को स्थानांतरित करना high-latency storage पर tree को file-by-file copy करने से तेज होता है।

Thin volumes पर discard को काम करते रखें। Thin provisioned storage पर backend को तब तक पता नहीं चलता कि कोई block खाली है, जब तक filesystem ऐसा न बताए। जिस volume पर कभी trim नहीं किया जाता, उसकी write performance धीरे-धीरे घटती जाती है। Ubuntu इसके लिए weekly timer देता है:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av प्रत्येक mount point के लिए trimmed bytes दिखाता है। यह संदेश कि discard operation supported नहीं है, इसका अर्थ है कि virtual disk discard को host तक forward नहीं करती। इसलिए आपको कुछ ठीक करने की आवश्यकता नहीं है।

IO scheduler tuning छोड़ दें। virtio disk पर cat /sys/block/vda/queue/scheduler आमतौर पर पहले से none दिखाता है। वास्तविक scheduling host पर होती है, जहां आपके पास access नहीं होता। noatime को भी छोड़ दें। Ubuntu default रूप से relatime के साथ mount करता है, जिससे लगभग सभी atime writes पहले ही बच जाती हैं।

प्लान चुनना

जब सर्वर पर database, mail server, CI runner या package-heavy build चलता हो, तब NVMe के लिए भुगतान करें। Cached website या ऐसे app के लिए premium न दें, जिसका अधिकांश समय external calls में जाता है। यदि आप निश्चित नहीं हैं, तो संभवतः disk आपकी सीमा नहीं है, क्योंकि अधिकांश छोटे VPS workloads में पहले RAM या bandwidth समाप्त होती है।

पहले दिन माप लें, जब आप नए VPS पर पहले दस मिनट की प्रक्रिया पूरी कर रहे हों, और output को किसी file में रखें। Baseline से आप बाद में साबित कर सकते हैं कि host धीमा हुआ है, न कि आपका code। ऐसे providers को प्राथमिकता दें, जो storage class और किसी भी IOPS cap को लिखित रूप में बताते हों। यदि किसी plan में NVMe लिखा है और queue depth 1 read में 4 ms लगते हैं, तो आपके पास NVMe-equipped host पर network storage है। इसे बेचना उचित है, लेकिन इसे खरीदना अलग बात है।

FAQ

क्या NVMe हमेशा VPS पर SATA SSD से तेज़ होता है?

नहीं। queue depth 1 पर दोनों का प्रदर्शन लगभग समान होता है। 4k read के लिए latency लगभग 80 से 150 microseconds रहती है। single-threaded program दोनों के बीच अंतर नहीं बता सकता। जब कई requests in flight होती हैं, तब NVMe आगे निकलता है। इसका कारण यह है कि AHCI में 32 commands की गहराई वाली एक queue होती है, जबकि NVMe में अधिक गहराई वाली हजारों queues होती हैं। shared host पर अन्य guests का load आपके latency को storage medium से अधिक प्रभावित कर सकता है। इसलिए plan name देखने के बजाय अपने volume का fio से मापन करें।

मैं कैसे जांचूं कि मेरा VPS वास्तव में NVMe का उपयोग करता है?

आप इसकी सीधे जांच नहीं कर सकते, क्योंकि virtio physical device को छिपा देता है। lsblk में vda दिखाई देता है, लेकिन model string नहीं होती। nvme list कुछ भी वापस नहीं करता। /sys/block/vda/queue/rotational केवल वही report करता है, जो hypervisor advertise करता है। इसके बजाय व्यवहार का मापन करें। queue depth 1 पर random 4k read की latency लगभग 0.3 ms से कम हो, तो इसका अर्थ local flash है। कई milliseconds की latency का अर्थ है कि path में network hop है। यदि sequential reads लगभग 550 MB/s पर रुकती हैं, तो यह SATA link का संकेत है।

क्या NVMe मेरी website को तेज़ी से load कराता है?

आमतौर पर नहीं। पहली request के बाद Linux files को RAM में page cache से serve करता है, इसलिए disk idle हो जाती है। छोटे VPS पर page speed सामान्यतः application CPU time और bandwidth से सीमित होती है। यदि site हर request पर write करती है, तो disk फिर critical path में आ जाती है। उदाहरण के लिए, database-backed cart बार-बार commit करता है, क्योंकि प्रत्येक commit पूरा होने के लिए flush का इंतजार करता है।

VPS के लिए अच्छा fio result क्या होता है?

July 2026 तक, local flash वाले छोटे VPS पर queue depth 32 में आमतौर पर 4k random read के लिए tens of thousands of IOPS मिलते हैं। queue depth 1 पर latency 0.3 ms से कम रहती है। Network block storage पर आमतौर पर कुछ thousand IOPS मिलते हैं और latency कुछ milliseconds होती है। यह test अलग-अलग hours में तीन बार चलाएं। अलग-अलग runs के बीच बहुत अधिक अंतर average से अधिक महत्वपूर्ण जानकारी देता है, क्योंकि इससे पता चलता है कि host पर मौजूद अन्य guests आपको कितना प्रभावित करते हैं।

क्या मुझे अपना database network block storage पर रखना चाहिए?

आप ऐसा कर सकते हैं और कई managed services ऐसा करती हैं, लेकिन commit path की performance घटती है। प्रत्येक flush network से होकर गुजरता है। इसलिए एक single connection local flash की तुलना में प्रति second कम small transactions commit करता है। इसके बदले आपको ऐसी durability मिलती है, जो host के विफल होने पर भी बनी रहती है। यदि आप write-heavy database के लिए network storage चुनते हैं, तो work को बड़ी transactions में group करें। इससे कम flushes में अधिक rows लिखी जाती हैं।