पूरी रिपोर्ट
आम और सबसे धीमे पेज, एक साथ
आम पेज (p50) और सबसे धीमे 5% (p95) का समय खरीदारों के देश से शुरू से अंत तक मापा गया है। उसी टेस्ट के server समय, सफलता दर और मेमोरी भी साथ दिए गए हैं।
परफ़ॉर्मेंस रिपोर्ट
असली स्टोर पर किया गया माप।छोटे से हार्डवेयर पर भी तेज़।
हमने एक लाइव फैशन स्टोर को उसके अपने 2 vCPU server पर लोड-टेस्ट किया। असली खरीदारी रास्ते खरीदारों के अपने देश से चलाए गए। यह कितना संभाला, हमने कैसे मापा और आपका कारोबार बढ़ने पर भी यह तेज़ क्यों रहता है—यह सब यहाँ है।
लाइव स्टोर और कैटलॉगखरीदारों के अपने देश से भेजा गयाPage cache के बिना server समयसादा PHP-FPM
फ़िल्म देखें
2 vCPU पर load test।
2 vCPU पर एक साथ 40 shoppers: typical page ≈0.4 s, server time 83–89 ms, और 99.97% requests में कोई error नहीं।
83–89 msहर पेज का server समय, बिना page cache
0.24–0.52 sएक साथ 20–30 खरीदार: आम पेज
≈0.4 sएक साथ 40 खरीदार: आम पेज
99.97%बिना किसी त्रुटि के 7,714 अनुरोध संभाले गए
टेस्ट में क्या निकला आया
छोटा server, और उसमें काफ़ी जगह बची।
एप्लिकेशन, PostgreSQL, Redis और बैकग्राउंड workers—सब एक ही 2 vCPU server पर चले, जिसमें 3.8 GB RAM था।
एक साथ 20–30 खरीदार
आम पेज में 0.24–0.52 s लगा, जबकि सबसे धीमे 5% अनुरोध 1.5 s के भीतर रहे; CPU का load आधा या उससे कम रहा।
एक साथ 40 खरीदार
आम पेज में लगभग 0.4 s लगा; CPU पर 58–83% load रहा और जगह अभी भी बची।
हर घंटे 43,000–50,000 अनुरोध
12–14 अनुरोध प्रति सेकंड पर भी वही छोटा server व्यस्त खरीदारी के घंटे को आराम से संभाल लेता है।
मेमोरी स्थिर रहती है
पूरे टेस्ट के दौरान वेब container 225–262 MiB पर रहा, जबकि RAM में 2.4 GB से ज़्यादा खाली रहा।
server पर 83–89 ms
लॉगिन किए ग्राहक के लिए, page cache बिना—server की सबसे मुश्किल हालत।
search लगभग 170 ms में
उसी छोटे server पर product search का जवाब लगभग 170 ms server time में।
हमने कैसे मापा
असली store, असली journeys, असली दूरी
भरोसेमंद numbers तभी मिलते हैं जब test की हालतें आपको पहचानी हों। इसलिए हमने वैसे ही measure किया जैसे आपके ग्राहक सचमुच आते हैं।
1
असली store
असली fashion catalog और checkout, 2 vCPU, 3.8 GB server पर—सब कुछ एक ही box पर।
2
असली journeys
70% नए visitors—हर visitor one to four pages देखता है, search करता है, cart में जोड़ता है और क्लिक्स के बीच 5–15 seconds पढ़ता है।
3
असली दूरी
k6 ने shoppers के अपने देश से traffic भेजा, gzip on रहा, और हर virtual shopper का अपना session था।
4
ईमानदार timing
Page times में network और TLS शामिल थे; server times में page cache नहीं था; setup सादा PHP-FPM था, OPcache के साथ।
तेज़ क्यों रहता है
हल्का बनाया गया, हर रिलीज़ में जाँचा गया।
रफ़्तार बढ़ाने के लिए हम आपसे server अपग्रेड खरीदने को नहीं कहते। यह रफ़्तार एप के बनने और जाँच के तरीक़े से आती है।
बनावट से ही हल्का
हमने मापा, फिर इसे हल्का और तेज़ बनाया।
हर पेज server पर बनता है और कोई भी स्क्रिप्ट चलने से पहले उसकी सामग्री पढ़ी जा सकती है। हर आने वाले के लिए एक जैसा डेटा कैश की हुई फ़ाइलों के रूप में मिलता है, और modules तभी चालू होते हैं जब किसी रिक्वेस्ट को उनकी ज़रूरत होती है।
- स्टोरफ़्रंट पेज का साइज़ 501 KB से घटकर 78 KB हुआ
- ऐप जवाब देने के लिए 87–92 ms में तैयार होता है, पहले यह 480–770 ms लेता था
- गेस्ट पेज हर होस्ट और भाषा के लिए कैश होते हैं, इसलिए दोबारा आने पर डेटाबेस रीड नहीं लेना पड़ता।
- इमेज WebP में बदले गए और हर स्लॉट के लिए सही साइज़ में सेट किए गए।
कोई खास runtime नहीं
आम server पर भी तेज़।
ये रफ़्तार आम PHP-FPM और OPcache से आती है। Octane, Swoole, FrankenPHP या JIT नहीं हैं, इसलिए Docker वाले किसी भी Linux server पर वही रफ़्तार मिलेगी और न कुछ अलग संभालना पड़ेगा।
सादा PHP-FPMवही runtime जो हर PHP host में पहले से चलता है
OPcache की सही tuningबड़े ऐप के लिए भी अलग setup के बिना तैयार
हल्की और साफ़ queriesजुड़ा हुआ data पहले ही एक साथ लोड होता है, एक-एक row नहीं
Edge पर cache किया गयाबिना login वाले पेज के आगे चाहें तो CDN
गुणवत्ता
हर release वही जाँचों से गुज़रता है।
Release बनने से पहले static analysis और 14,000 से ज़्यादा automated tests चलते हैं। इसलिए नया बदलाव आपकी स्टोर को चुपचाप न धीमा बनाता है, न कम भरोसेमंद।
बढ़ने की गुंजाइश
ग्राहक बढ़े? server की क्षमता बढ़ाएँ, कोड दोबारा न लिखें।
App का ज़्यादातर काम CPU पर होता है और वह कोई local state नहीं रखता, इसलिए cores जितने बढ़ेंगे, server की क्षमता उतनी बढ़ेगी: पहले 4 vCPU पर जाएँ, database को अपना server दें, फिर load balancer के पीछे app servers जोड़ें।
Speed से जुड़े सवाल
Speed पर सीधे जवाब
क्या मेरे server पर भी इतनी speed मिलेगी?
तुलनीय 2 vCPU server पर हाँ, अगर वह आपके ग्राहकों के पास हो। Page खुलने में network का time भी शामिल होता है, इसलिए server कितना बड़ा और hosting कितनी दूर—दोनों speed पर उतना ही असर डालते हैं।
एक साथ कितने ग्राहक आएं?
एक ही समय पर लोग store में browse कर रहे होते हैं। हर click के बाद 5–15 seconds तक पढ़ते हैं। किसी store में एक साथ ऐसे 40 ग्राहक हों, तो उस store को रोज़ हज़ारों visitors संभालने होते हैं।
Traffic बढ़े तो क्या करें?
पहले 4 vCPU पर जाएँ, फिर database को अपना server दें और load balancer के पीछे app servers जोड़ें। हर बार software और data वही रहते हैं।
क्या pages cache किए जाते हैं?
हाँ। Guest pages हर host और language के हिसाब से cache होती हैं, इसलिए दोबारा visit पर database नहीं जाता। आप चाहें तो इसके आगे CDN भी जोड़ सकते हैं। इस page पर दिखाए गए server times page cache बंद होने पर नापे गए हैं।
Octane या Swoole की ज़रूरत क्यों नहीं?
आपको इनकी ज़रूरत नहीं। Standard PHP-FPM से hosting आसान रहती है और speed का अंदाज़ा साफ़ रहता है। App पहले से इतना हल्का है कि किसी खास runtime के बिना भी तेज़ चलता है।
अपने server पर इसे आज़माइए।
अपना plan बनाएं, Docker के साथ deploy करें और अपने catalog पर इसे चलाकर speed देखें।