<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[VPS Rankings]]></title><description><![CDATA[VPS Rankings]]></description><link>https://bobtong.hashnode.dev</link><generator>RSS for Node</generator><lastBuildDate>Mon, 02 Nov 2026 21:35:13 GMT</lastBuildDate><atom:link href="https://bobtong.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[Why 2 vCPUs & 4GB RAM Costs $5 on Provider A and $25 on Provider B: An Engineer's Guide to Cloud VPS Overselling]]></title><description><![CDATA[Every developer building side projects, hosting Docker stacks, or deploying microservices has faced this pricing dilemma: • Budget Host X: 2 vCPUs, 4GB…]]></description><link>https://bobtong.hashnode.dev/why-2-vcpus-4gb-ram-costs-5-on-provider-a-and-25-on-provider-b-an-engineer-s-guide-to-cloud-vps-overselling</link><guid isPermaLink="true">https://bobtong.hashnode.dev/why-2-vcpus-4gb-ram-costs-5-on-provider-a-and-25-on-provider-b-an-engineer-s-guide-to-cloud-vps-overselling</guid><category><![CDATA[vps]]></category><dc:creator><![CDATA[Bob Tong]]></dc:creator><pubDate>Wed, 14 Oct 2026 08:01:53 GMT</pubDate><content:encoded><![CDATA[<p>Every developer building side projects, hosting Docker stacks, or deploying microservices has faced this pricing dilemma:</p>
<p>• Budget Host X: 2 vCPUs, 4GB RAM, 80GB NVMe SSD — \(4.99/mo • Cloud Platform Y (DigitalOcean / Vultr / Linode): 2 vCPUs, 4GB RAM, 80GB SSD — \)24.00/mo</p>
<p>On paper, the specs are identical: same core count, identical RAM, both touting modern NVMe storage.</p>
<p>Yet when you run a production workload—say, compiling a Rust binary, running automated CI tests, or handling a traffic spike on a Postgres database—the $5 box throttles to a crawl while the $24 instance churns through effortlessly.</p>
<p>Why does this 5x price difference exist? Is it just brand markup, or are you actually buying fundamentally different compute hardware?</p>
<p>Let’s look under the hood of KVM hypervisors, kernel CPU schedulers, distributed storage latency, and transit network routing.</p>
<p>The Core Virtualization Trap: vCPU Overcommit &amp; %steal When you purchase a cloud instance, you are rarely renting physical silicon. You are renting timeslices on a hypervisor (typically KVM/QEMU) managed by the host OS kernel.</p>
<p>The Physics of Overcommit (vCPU to pCPU Ratio)</p>
<p>A typical dual-socket AMD EPYC 9654 server offers 192 physical cores (384 threads).</p>
<p>• Enterprise Cloud Infrastructure: Providers typically cap their overcommit ratio between 1.5:1 and 3:1. A 384-thread host serves between 570 and 1,150 vCPUs. Every vCPU gets fair, predictable CPU scheduler quota via Linux cgroups. • Deep-Discount Budget Hosts: Providers often push overcommit ratios to 8:1 or even 12:1. That same 384-thread machine might be packed with 3,000+ vCPUs.</p>
<p>How to Diagnose CPU Steal (%st)</p>
<p>When other tenants on the same physical host demand compute, the hypervisor’s CFS (Completely Fair Scheduler) is forced to starve your virtual machine.</p>
<p>This latency penalty is measured in your Linux kernel as CPU Steal Time (%st).</p>
<p>Run mpstat or top inside your instance during a build:</p>
<p>Check CPU utilization breakdown every 2 seconds top -b -n 1 | grep “%Cpu”</p>
<p>Or using sysstat mpstat -P ALL 1 5</p>
<p>Look at the %st column: • 0.0% – 0.5%: Healthy hypervisor. Your vCPU is getting CPU cycles when requested. • 1.0% – 4.0%: Moderate overcommit. Background cron jobs or compile tasks will take ~20% longer. • &gt; 10.0%: Dangerous overselling. Your process is ready to run, but the host cannot allocate CPU registers. High HTTP latency and API timeouts will occur.</p>
<p>Storage Architecture: Local NVMe RAID10 vs. Distributed Ceph/EBS “NVMe Storage” is the most abused term in modern cloud hosting. There are two completely distinct architectures marketed under this same label:</p>
<p>• Dedicated Local NVMe (RAID 10): Mounted directly on PCI-e bus inside the chassis. Random 4K read latency is 20 – 60 microseconds (μs) with 80,000+ IOPS. • Network Distributed Block Storage (Ceph / SAN): Connected via Top-of-Rack Network switches. Random 4K read latency is 800 – 3,500 microseconds (μs) and IOPS are heavily throttled.</p>
<p>The 4K Random I/O Benchmark Test</p>
<p>Never rely on sequential dd commands. Databases like PostgreSQL, MySQL, and SQLite live and die on 4K Direct Random I/O.</p>
<p>Run this fio benchmark to uncover the truth:</p>
<p>fio --name=randwrite --ioengine=libaio --direct=1 --rw=randwrite --bs=4k --size=1G --numjobs=4 --iodepth=64 --runtime=30 --time_based --group_reporting</p>
<p>If your 4K sync write latency spikes over 5ms, you are running on a saturated network storage pool. A budget $5 VPS might give you 3,000 MB/s sequential bursts, but its 4K random write will crawl at 12 MB/s once write buffers fill up.</p>
<p>Network Transit: Transit vs. Peering vs. Route Optimization Bandwidth pricing is another hidden cost driver. 1 Gbps of raw transit can cost a provider anywhere from \(0.15/Mbps to \)15.00/Mbps.</p>
<p>Cogent / Hurricane Electric (HE): Low-cost global tier-1 transit. Excellent for bulk bandwidth in North America and Western Europe, but prone to packet loss and high jitter during peak evening hours across the Atlantic and Pacific. Telia (Arelion) / NTT / Lumen: Premium tier-1 carriers with SLA guarantees, lower packet loss, and robust peering at IX points. Route-Optimized Backbones (CN2 GIA / AS9929 / CMIN2): Dedicated trans-Pacific or Asian enterprise lines with strict QoS routing that bypass congested public nodes. If you are serving international developers or cross-border users, a cheap VPS with 10TB bandwidth will often drop 15% of packets between 8 PM and 11 PM, ruining WebSockets, SSH terminals, and live streaming.</p>
<p>The Engineering Checklist: Automated Verification Script Before deploying production services to any new VPS provider, run this lightweight validation suite to inspect your actual hardware allocation:</p>
<p>#!/usr/bin/env bash</p>
<p>Quick VPS Quality Check set -e</p>
<p>echo “=== 1. CPU Model &amp; Hypervisor Check ===” lscpu | grep -E “Model name|Virtualization|Hypervisor vendor”</p>
<p>echo -e “\n=== 2. Memory &amp; Swap Configuration ===” free -h</p>
<p>echo -e “\n=== 3. 4K Random Disk Performance ===” if command -v fio &gt;/dev/null 2&gt;&amp;1; then fio --name=quick_test --ioengine=libaio --direct=1 --rw=randrw --bs=4k --size=512M --numjobs=2 --iodepth=32 --runtime=15 --time_based --group_reporting | grep -E “IOPS|lat.*avg” else echo “fio not installed. Run: apt install -y fio” fi</p>
<p>echo -e “\n=== 4. Upstream Network Latency ===” for target in 1.1.1.1 8.8.8.8; do ping -c 4 $target | tail -1 done</p>
<p>Decision Framework: When to Buy What? So, should you always buy the $24/mo instance? Absolutely not. It all depends on your architecture:</p>
<p>When Budget ($3 – $6/mo) is Ideal: • Lightweight personal VPNs / WireGuard relays • Staging environments with zero concurrent users • Headless cron job runners that don’t need real-time guarantees • Static sites with Cloudflare edge caching in front</p>
<p>When Developer Cloud ($12 – $25/mo) is Non-Negotiable: • Running Docker engines with CI/CD runners (GitLab Runner / GitHub Actions) • Production relational databases (PostgreSQL, MariaDB) requiring sub-millisecond 4K I/O • Real-time WebSocket servers or chat infrastructure • Fast API response times where P99 latency matters</p>
<p>Further Reading &amp; Benchmark Datasets</p>
<p>If you are evaluating providers for your tech stack, check out these community resources: • 5 Best VPS for Developers of 2026: <a href="https://vpsrankings.com/en/vps/best-dev-vps">https://vpsrankings.com/en/vps/best-dev-vps</a> — A curated breakdown of API-driven platforms, Docker support, and hourly billing flexibility. • VPS Benchmarks Database: <a href="https://vpsrankings.com/benchmarks">https://vpsrankings.com/benchmarks</a> — Public Geekbench 6 and FIO metrics across major cloud hosts.</p>
<p>What are your go-to tests when validating a new cloud provider? Have you ever been burned by bad %steal times? Let’s discuss in the comments.</p>
]]></content:encoded></item><item><title><![CDATA[What Oracle's Silent Free-Tier Cut Teaches Us About Depending on 'Free' Cloud Infrastructure]]></title><description><![CDATA[In mid-June 2026, Oracle quietly changed the numbers in its Ampere A1 Always Free documentation. No blog post, no changelog entry, no email to existing…]]></description><link>https://bobtong.hashnode.dev/what-oracle-s-silent-free-tier-cut-teaches-us-about-depending-on-free-cloud-infrastructure</link><guid isPermaLink="true">https://bobtong.hashnode.dev/what-oracle-s-silent-free-tier-cut-teaches-us-about-depending-on-free-cloud-infrastructure</guid><dc:creator><![CDATA[Bob Tong]]></dc:creator><pubDate>Fri, 21 Aug 2026 04:46:33 GMT</pubDate><enclosure url="https://cdn.hashnode.com/uploads/covers/6a6ec30ce0c148d333f5840d/c6363e2f-070c-4d0f-991b-530a871d0c9c.jpg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<hr />
<p>In mid-June 2026, Oracle quietly changed the numbers in its Ampere A1 Always Free documentation. No blog post, no changelog entry, no email to existing users. Just updated figures on a docs page that most people only check when they're setting something up for the first time. By the time enforcement actually kicked in on August 18, plenty of people running production-ish workloads on that free tier had no idea anything had changed until their instance stopped responding.</p>
<p>This is a useful case study in why "free forever" cloud tiers deserve more architectural skepticism than we usually give them.</p>
<h2>The Change, Briefly</h2>
<p>Oracle cut the Always Free A1 compute budget in half:</p>
<ul>
<li><p><strong>Before:</strong> 4 OCPUs, 24GB RAM (3,000 OCPU-hours / 18,000 GB-hours per month)</p>
</li>
<li><p><strong>Now:</strong> 2 OCPUs, 12GB RAM (1,500 OCPU-hours / 9,000 GB-hours per month)</p>
</li>
</ul>
<p>This is a tenancy-wide total, not a per-VM limit — you can split it across multiple smaller instances however you like, as long as the sum stays under 2 OCPU / 12GB. The two AMD <code>E2.1.Micro</code> instances (1/8 OCPU + 1GB each) are unaffected.</p>
<h2>The Enforcement Gap Is the Interesting Part</h2>
<p>What makes this worth writing about isn't the resource cut itself — providers adjust free tiers, that's not new. It's the six-to-eight-week gap between the docs changing and enforcement actually starting, during which:</p>
<ul>
<li><p>Over-quota instances kept running normally</p>
</li>
<li><p>Cost estimates in the console still showed $0</p>
</li>
<li><p>The instance-creation flow didn't reflect the new limits</p>
</li>
</ul>
<p>In other words, the system gave every signal that nothing had changed, right up until it started disabling instances. Some users on Cloud Customer Connect report instances that were <em>already within the new 2/12 limit</em> getting disabled anyway during the enforcement sweep, requiring a support ticket to restore. That's anecdotal, not a confirmed systemic bug — but it's common enough in the community threads to be worth taking seriously if you're managing anything you can't afford to lose.</p>
<p>There's also an unresolved thread around Pay-As-You-Go accounts: some Oracle support responses say PAYG tenancies keep the old 4/24 allowance under Always Free terms, others say the new cap applies universally. The public docs don't clarify this either way.</p>
<h2>The Actual Lesson for Architecture Decisions</h2>
<p>None of this means Oracle's free tier is bad — 2 OCPU / 12GB ARM plus two x86 micro instances is still generous compared to most competitors, and it still comfortably runs WordPress, Docker workloads, n8n, small databases, and reverse proxies. The lesson is narrower and more practical:</p>
<p><strong>If a resource is free, its terms can change with effectively zero notice, and enforcement can lag or misfire in ways that catch compliant setups too.</strong> That's fine for a homelab. It's a liability if it's sitting anywhere near your critical path.</p>
<p>Concretely, that means:</p>
<ul>
<li><p>Don't put anything you can't lose on a free tier without a backup or migration plan</p>
</li>
<li><p>Check quota pages against current docs periodically — not against what you remember from signup</p>
</li>
<li><p>If you're on ARM, verify ARM64 support for your stack before committing, since architecture mismatches cause more friction than the resource cut itself</p>
</li>
<li><p>Treat "compliant" as necessary but not sufficient — verify actual running status, don't just trust your own math</p>
</li>
</ul>
<p>I go deeper into the tenancy-total math, the exact console steps to check your own account, and how to fix an over-quota setup in the full writeup: <a href="https://vpsrankings.com/en/articles/1t9g1431-oracle-cloud-always-free-tier-changes-arm-a1-instances">Oracle Cloud Always Free Tier Changes — full breakdown</a></p>
]]></content:encoded></item><item><title><![CDATA[Behind the Scenes: My Complete VPS Benchmarking Methodology]]></title><description><![CDATA[Running a VPS review platform means I constantly get questions about exactly how I evaluate server performance. To keep things completely transparent, here…]]></description><link>https://bobtong.hashnode.dev/behind-the-scenes-my-complete-vps-benchmarking-methodology</link><guid isPermaLink="true">https://bobtong.hashnode.dev/behind-the-scenes-my-complete-vps-benchmarking-methodology</guid><dc:creator><![CDATA[Bob Tong]]></dc:creator><pubDate>Sun, 02 Aug 2026 04:50:49 GMT</pubDate><content:encoded><![CDATA[<p>Running a VPS review platform means I constantly get questions about exactly <em>how</em> I evaluate server performance. To keep things completely transparent, here is the exact testing stack I deploy for every server:</p>
<h3>Hardware Stress Tests</h3>
<ul>
<li><p><strong>CPU Performance</strong>: Geekbench 6 (evaluating both single and multi-core capabilities)</p>
</li>
<li><p><strong>Storage I/O</strong>: FIO (stress testing 4K random read/write speeds, plus 1M sequential)</p>
</li>
<li><p><strong>Memory Speed</strong>: Sysbench memory benchmark</p>
</li>
</ul>
<h3>Network &amp; Routing Evaluation</h3>
<ul>
<li><p><strong>Global Throughput</strong>: iperf3 testing across 5 distinct international endpoints</p>
</li>
<li><p><strong>Latency &amp; Routing</strong>: Ping and traceroute diagnostics across 3 major ISPs</p>
</li>
<li><p><strong>Real-World Application</strong>: Measuring Time to First Byte (TTFB) via curl on a fresh WordPress deployment</p>
</li>
</ul>
<h3>Why This Approach Matters</h3>
<p>The web is full of "review" platforms that simply regurgitate marketing specs from a provider's sales page. I take a different route: I anonymously purchase the entry-level plan and put the servers through this exact gauntlet myself.</p>
<p>I believe in data, not marketing. You can check out all my published benchmark results on vpsrankings.com — I make all the raw data public so you can verify the performance for yourself.</p>
<p><em>Originally published on</em> <a href="https://vpsrankings.com/en"><em>VPS Rankings</em></a></p>
]]></content:encoded></item></channel></rss>