हाई ट्रैफ़िक के लिए वेबसाइट को स्केल कैसे करें

लोड के नीचे वेबसाइटें क्यों धराशायी हो जाती हैं

जब किसी कैंपेन लॉन्च, फ़्लैश सेल, या किसी वायरल पल के दौरान कोई साइट रेंगने की गति तक धीमी हो जाती है, तो इसका कारण लगभग हमेशा एक ही संतृप्त (saturated) संसाधन होता है: CPU 100% पर अटका हुआ, बहुत अधिक खुले कनेक्शन वाला डेटाबेस, या असंपीड़ित (uncompressed) इमेज परोसते-परोसते अधिकतम सीमा तक भरा हुआ नेटवर्क लिंक। स्केलिंग वह अनुशासन है जिसमें उस बॉटलनेक को ढूँढा जाता है, उसे हटाया जाता है, और अगले के लिए हेडरूम बनाया जाता है।

यह गाइड हाई ट्रैफ़िक के लिए वेबसाइट को स्केल करने की व्यावहारिक परतों को उसी क्रम में समझाती है जिस क्रम में आपको इन्हें संभालना चाहिए। तकनीकें प्लेटफ़ॉर्म-निरपेक्ष हैं, लेकिन यहाँ दी गई हर कमांड और कॉन्फ़िग ऐसी है जिसे आप आज ही Skyline Cloud VPS या क्लाउड सर्वर पर चला सकते हैं, जहाँ आपका डेटा किंगडम के भीतर रहता है और PDPL/NCA अनुपालन आपके लिए संभाल लिया जाता है।

चरण 1: स्केल करने से पहले मापें

कभी भी बिना देखे ऑप्टिमाइज़ न करें। एक बेसलाइन स्थापित करें ताकि आपको पता हो कि "पर्याप्त तेज़" का क्या मतलब है और समय कहाँ खर्च होता है।

k6 का उपयोग करके किसी अलग मशीन से एक लोड टेस्ट चलाएँ:

# install on Ubuntu/Debian
sudo apt-get install -y gnupg ca-certificates
curl -s https://dl.k6.io/key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/k6-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update && sudo apt-get install -y k6

// load.js — ramp to 200 virtual users over 3 minutes
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '1m', target: 50 },
    { duration: '1m', target: 200 },
    { duration: '1m', target: 0 },
  ],
};

export default function () {
  const res = http.get('https://example.com/');
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}

इसे k6 run load.js के साथ चलाएँ और http_req_duration तथा एरर रेट पर नज़र रखें। सर्वर पर htop, iostat -x 2, और अपने डेटाबेस का स्लो-क्वेरी लॉग खुला रखें। जो संसाधन सबसे पहले संतृप्त होता है, वही आपका बॉटलनेक है — किसी अनुमान को नहीं, उसी को ठीक करें।

चरण 2: आक्रामक रूप से कैश करें — सबसे बड़े लाभ वाला कदम

अधिकांश रीड-हेवी (read-heavy) साइटें अधिकांश अनुरोधों को बिना ऐप्लिकेशन या डेटाबेस को छुए ही परोस सकती हैं।

पेज और ऑब्जेक्ट कैशिंग। WordPress पर, Redis द्वारा समर्थित एक ऑब्जेक्ट कैश दोहराई जाने वाली डेटाबेस क्वेरियों को हटा देता है। Redis और Redis Object Cache प्लगइन इंस्टॉल करें:

sudo apt-get install -y redis-server php-redis
sudo systemctl enable --now redis-server

wp-config.php में जोड़ें:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );

आपके ऐप के किनारे पर HTTP कैशिंग। Cache-Control हेडर सेट करें ताकि ब्राउज़र और कोई भी डाउनस्ट्रीम कैश रिस्पॉन्स को दोबारा उपयोग कर सकें। Nginx में, स्टैटिक एसेट्स को मज़बूती से कैश करें और HTML को रीवैलिडेट होने दें:

location ~* \.(jpg|jpeg|png|webp|css|js|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
}

एक सही ढंग से कॉन्फ़िगर की गई कैश परत आमतौर पर ऑरिजिन लोड को 70–90% तक घटा देती है। बड़े सर्वर खरीदने से पहले यह करें।

चरण 3: जो आपके पास पहले से है उसे ट्यून करें (स्केल अप)

वर्टिकल स्केलिंग — अधिक CPU, RAM, और तेज़ NVMe डिस्क — सबसे सरल कदम है और अक्सर सही पहला कदम भी। Skyline Cloud पर आप एक VPS को कुछ ही मिनटों में रीसाइज़ कर सकते हैं। लेकिन सॉफ़्टवेयर को भी ट्यून करें:

• PHP-FPM: pm.max_children को (available RAM for PHP) / (average process size) के अनुसार सेट करें। प्रोसेस का आकार जाँचें ps --no-headers -o "rss" -C php-fpm8.2 | awk '{s+=$1} END {print s/NR/1024" MB"}' से।
• MySQL/MariaDB: एक समर्पित डेटाबेस होस्ट पर innodb_buffer_pool_size को RAM के लगभग 60–70% पर सेट करें ताकि वर्किंग सेट मेमोरी में रहे।
• कनेक्शन: एक कनेक्शन पूलर जोड़ें। PostgreSQL के लिए pgbouncer का उपयोग करें; MySQL के लिए परसिस्टेंट कनेक्शन को छोटा और सीमित (capped) रखें।

चरण 4: लोड बैलेंसर के साथ स्केल आउट करें (हॉरिज़ॉन्टल स्केलिंग)

एक अकेले सर्वर की एक सीमा होती है। आगे बढ़ने के लिए, एक लोड बैलेंसर के पीछे कई समान ऐप्लिकेशन सर्वर चलाएँ। इससे लचीलापन (resilience) भी बेहतर होता है: यदि कोई एक नोड बंद हो जाए, तो ट्रैफ़िक दूसरों पर स्थानांतरित हो जाता है।

एक न्यूनतम Nginx लोड बैलेंसर कॉन्फ़िग:

upstream app_backend {
    least_conn;
    server 10.10.0.11:80 max_fails=3 fail_timeout=10s;
    server 10.10.0.12:80 max_fails=3 fail_timeout=10s;
    server 10.10.0.13:80 max_fails=3 fail_timeout=10s;
}

server {
    listen 443 ssl;
    server_name example.com;
    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

इसके काम करने के लिए, आपका ऐप स्टेटलेस (stateless) होना चाहिए: सेशन को लोकल डिस्क पर नहीं, बल्कि Redis या डेटाबेस में स्टोर करें, और यूज़र अपलोड्स को किसी एक सर्वर के फ़ाइलसिस्टम के बजाय साझा ऑब्जेक्ट स्टोरेज में रखें। एक बार जब अनुरोध सुरक्षित रूप से किसी भी नोड पर पहुँच सकें, तो आप नोड्स को स्वतंत्र रूप से जोड़ या हटा सकते हैं।

चरण 5: डेटाबेस को स्केल करें (अक्सर असली बॉटलनेक यही होता है)

ऐप्लिकेशन सर्वरों को क्लोन करना आसान है; डेटाबेस को नहीं। इन तकनीकों का इस क्रम में उपयोग करें:

अपनी सबसे धीमी क्वेरियों पर EXPLAIN से शुरुआत करें और गायब इंडेक्स जोड़ें — यह अक्सर लगभग शून्य प्रयास में 10 गुना लाभ देता है। फिर रीड रेप्लिका जोड़ें: SELECT ट्रैफ़िक को एक या अधिक रेप्लिका की ओर निर्देशित करें और INSERT/UPDATE/DELETE को प्राइमरी पर भेजें। शार्डिंग की ओर तभी बढ़ें जब एक अकेला प्राइमरी वास्तव में राइट वॉल्यूम को सहन न कर पाए।

चरण 6: एक CDN सामने लगाएँ

एक CDN स्टैटिक एसेट्स — और अधिकाधिक रूप से पूरे पेज — को यूज़र्स के नज़दीकी एज लोकेशनों पर कैश करता है। GCC दर्शकों के लिए, इमेज, CSS, और JavaScript को नज़दीकी एज से परोसना लेटेंसी घटाता है और आपके ऑरिजिन से भारी मात्रा में बैंडविड्थ का बोझ हटा देता है। अपने CDN को अपने ऑरिजिन की ओर इंगित करें, फिर डायनामिक, पर्सनलाइज़्ड रूट्स (कार्ट, चेकआउट, अकाउंट) को अनकैश्ड या प्रति-यूज़र कैश्ड रखें।

चरण 7: ऑटोस्केलिंग के साथ स्वचालित करें

अंतिम परत स्केलिंग को स्वचालित बनाना है। एक स्केलिंग ग्रुप परिभाषित करें जो औसत CPU के, मान लीजिए, पाँच मिनट तक 65% पार करने पर ऐप्लिकेशन नोड्स जोड़ता है, और लोड घटने पर उन्हें हटाता है। इसे लोड बैलेंसर पर एक हेल्थ चेक के साथ जोड़ें ताकि अस्वस्थ नोड्स स्वचालित रूप से रोटेशन से बाहर खींच लिए जाएँ। यह आपको स्पाइक्स के दौरान तेज़ और शांत घंटों के दौरान किफ़ायती रखता है — जो क्लाउड का मूल आर्थिक लाभ है।

एक समझदार स्केलिंग क्रम

1. मापें और असली बॉटलनेक ढूँढें।
2. कैश करें (ऑब्जेक्ट, HTTP, CDN)।
3. स्केल अप करें और सॉफ़्टवेयर को ट्यून करें।
4. लोड बैलेंसर के पीछे ऐप टियर को स्केल आउट करें।
5. डेटाबेस को इंडेक्स, रेप्लिका, फिर शार्डिंग के साथ स्केल करें।
6. ऑटोस्केलिंग के साथ स्वचालित करें।

हर कदम हेडरूम देता है; कैशिंग के बिना सीधे चरण 4 पर कूद जाना केवल एक बड़े महँगे क्लस्टर से वह काम करवाता है जिससे बचा जा सकता था।

इसे Skyline Cloud पर चलाएँ

ऊपर बताई गई हर चीज़ मानक Linux पर चलती है, इसलिए यह पूरी तरह पोर्टेबल है। Skyline Cloud जो अंतर जोड़ता है वह स्थानीय है: PDPL, NCA, और SDAIA अनुपालन के लिए आपका डेटा सऊदी अरब के भीतर रहता है, आपको अरबी-भाषी सपोर्ट मिलता है, और आप माँग पर VPS इंस्टेंस रीसाइज़ कर सकते हैं या लोड-बैलेंस्ड नोड्स जोड़ सकते हैं। प्लेटफ़ॉर्म को हमारे cloud hosting page पर एक्सप्लोर करें, Cloud Hosting in Saudi Arabia हब में और अधिक गाइड ब्राउज़ करें, और यदि आपको उसी डोमेन के लिए विश्वसनीय business email hosting चाहिए, तो हम वह भी कवर करते हैं।

क्या आप कुछ ऐसा बनाने के लिए तैयार हैं जो अपने सबसे व्यस्त दिन को बिना किसी परेशानी के संभाल ले? अपना Skyline Cloud अकाउंट बनाएँ और कुछ ही मिनटों में अपना पहला स्केलेबल सर्वर शुरू करें।