OpenFreeMap ने प्रति सेकंड 1 लाख requests संभालने का अनुभव साझा किया

(blog.hyperknot.com)

5 पॉइंट द्वारा GN⁺ 2025-08-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें

OpenFreeMap ने प्रति सेकंड 1 लाख requests और प्रति दिन करीब 30 करोड़ (300 मिलियन) ट्रैफिक सफलतापूर्वक संभाला
Wplace.live की अचानक बढ़ी लोकप्रियता और automated bulk requests ट्रैफिक स्पाइक के कारण बने
Cloudflare की CDN cache rate 99.4%, और server ने अतिरिक्त 1,000 rps भी आराम से संभाल लिया
इससे केवल tile miss जैसी छोटी-मोटी समस्याएँ आईं, बाकी सेवा लगभग पूरी तरह सामान्य रही
आगे referer-based bandwidth throttling जैसे automated traffic management सुधार लागू करने की योजना है

OpenFreeMap के पिछले 10 महीने और हाई-ट्रैफिक का अनुभव

OpenFreeMap ने पिछले 10 महीनों में बेहद स्थिर संचालन का अनुभव किया। Cloudflare की bandwidth sponsorship, Hetzner server reliability, Btrfs पर tile service और nginx की efficiency की वजह से सिस्टम की reliability साबित हुई। लेकिन एक दिन अचानक कुछ tiles load नहीं होने की रिपोर्ट आई। आम तौर पर यह algorithm bug की वजह से होता है, लेकिन इस बार open() "Too many open files" error nginx logs में मिली।

ट्रैफिक मॉनिटरिंग टूल से देखा गया कि 24 घंटे में 30 अरब requests हुए और सिर्फ छोटे tile files से भी 215TB traffic record हुआ। हाल के 5 मिनट में 3 करोड़ requests यानी प्रति सेकंड करीब 10 लाख requests का spike आया। यह traffic किसी भी commercial map service में प्रति माह 600,000 USD से ज्यादा खर्च करा सकता था।

Cloudflare डैशबोर्ड पर 96% requests को 200 OK response मिला, जबकि केवल 3.6% abnormal थे (206 Partial Content)। यानी ज्यादातर requests ठीक से serve हुए, और कुछ missing tiles को छोड़कर बाकी सिस्टम सामान्य काम कर रहा था।

ट्रैफिक स्पाइक का कारण: Wplace.live

इस स्पाइक का कारण नया collaborative drawing website Wplace.live था। लॉन्च के बाद अचानक बहुत सारे users आ गए और इसे OpenFreeMap-based map use करने के लिए design किया गया था। users ने 1-pixel/30-second limit को bypass करने के लिए automation tools (जैसे Puppeteer/Chromium, IP rotation आदि) से bulk requests भेजीं।

ऐडमिन ने पुराने अनुभव Neal.fun से बताया कि traffic आने से पहले communication कितना important होता है। इस बार सेवा प्रभावित होने पर Cloudflare rules पहली बार लागू करके block करना पड़ा। आगे referer या custom header आधारित automated traffic control (Cloudflare API के साथ) पर काम करने की योजना है。

Cloudflare की मदद और OpenFreeMap architecture का परिणाम

Cloudflare ने bandwidth sponsorship बहुत तेज़ी से approve की—वीकेंड समेत करीब 48 घंटे के भीतर—और architecture fit पर engineers के साथ discussion भी हुआ। इतने बड़े enterprise होने के बाद भी उन्होंने बहुत agile response दिखाया।

ऑपरेटर ने 99.4% CDN cache rate पाने पर गर्व जताया और कहा कि server ने 1,000 rps का load भी अच्छी तरह संभाला। साप्ताहिक data अपडेट देने वाली services के लिए यह काफ़ी अच्छा result है।

Wplace.live developer से बातचीत और समाधान सुझाव

इसके बाद Wplace.live developer से संपर्क हुआ, जिन्होंने अचानक 20 लाख users बढ़ने से तैयारी की कमी को समझा। उनसे OpenFreeMap self-hosting instance support पर चर्चा हुई ताकि traffic concentration घटे और efficiency बढ़े।

साथ ही वास्तविक 20 लाख users के हिसाब से 30 करोड़ requests आना दिखाता है कि script-based bulk requests ही ज़्यादातर कारण थे। सामान्य उपयोगकर्ता केवल 10-20 requests ही करते हैं, इसलिए सेवा नीति बदलकर गैर-जरूरी automated requests रोकने की सलाह दी गई।

आगे सुधार और सीख

ऑपरेटर ने दो सुधार मुद्दे बताए:

Referer-based bandwidth limiting
- Cloudflare में referer के हिसाब से requests को 24 घंटे में 100M-200M तक limit करने की योजना है
- native apps को custom header इस्तेमाल की तरफ़ ले जाने का plan है
Tile miss handling और server configuration सुधार
- गलत server सेटिंग से बनने वाली खाली tiles को रोकने के कदम लिए जाएँगे

OpenFreeMap अभी महीने में 500 USD की donations पर चल रहा है। infrastructure cost लगभग पूरी तरह कवर हो जाती है, लेकिन नई development काम सीमित personal time पर निर्भर है। अतिरिक्त support मिलने पर development speed और service stability दोनों बढ़ेंगी।

GitHub sponsorship के जरिए project support किया जा सकता है: https://github.com/sponsors/hyperknot

1 टिप्पणियां

GN⁺ 2025-08-10

Hacker News टिप्पणी

कुछ इमेज देखकर लगता है कि शायद ये script kiddies ने बनाई हैं। इस साइट पर हर यूज़र को 30 सेकंड में सिर्फ 1 pixel ड्रॉ करने की अनुमति थी, इसलिए शायद सभी लोगों ने Puppeteer या Chromium से नया browser खोलकर pixel क्लिक किया और फिर browser बंद करके automation चलाया। IP address rotate भी किया गया होगा, हालाँकि शायद उसकी जरूरत भी नहीं थी। यह जो growth एक ही रात में भारी स्केल पर गई, उसे कम करके नहीं आँकना चाहिए। मैंने अपने घर के आसपास बने ड्रॉइंग के बारे में कुछ लोगों को बताया; वेबसाइट का नाम लिए बिना ही सभी तुरंत समझ गए कि मैं किस बारे में बोल रहा हूँ। लोग /r/place किस्म के प्रोजेक्ट्स को बहुत पसंद करते हैं, और इस बार दुनिया के नक्शे पर सीधे ड्रॉ करके अपने घर के आसपास जगह बना पाने की सुविधा शायद बहुत अच्छी response लाई।
अगर maplibre सीधे static pmtiles फाइलें read करने वाला तरीका अपनाता, तो फर्क क्या होता? Bunnycdn से pmtiles को range request से fetch करते समय मुझे वास्तविक tile server से लगभग वही response speed मिली।
- मुझे लगता है wplace शायद केवल एक custom static pmtile से पूरी requirement कवर कर सकता था। इस केस में 150GB OSM डेटा process करने की जरूरत नहीं पड़ती।
- संबंधित लिंक साझा किया।
इतनी detailed explanation और transparency के लिए धन्यवाद। मैं StatusGator के outage map में MapTiler की जगह OpenFreeMap पर migrate करने पर विचार कर रहा हूँ।
- जब चाहो migrate कर सकते हो। अगर high availability की चिंता हो तो self-host कर सकते हो। मैं public instance को जितना stable रखा जा सके उतना रखने की कोशिश में लगा हूँ।
सिर्फ screenshots देखकर लगा था कि एक VPS से भी पर्याप्त होगा, और डिज़ाइन शायद बहुत complex लग रही थी। फिर ध्यान आया कि pixels पूरे ग्लोब मैप पर spread हैं। peak request throughput कितना होगा, यही सोचना है। शायद किसी benchmark-friendly web server से बस संभल सकता हो। निश्चित ही app के nature की वजह से कहीं बड़ा performance drop हो सकता है। 1km में 64 pixels होने पर बिना compression के पूरी global color cover के लिए लगभग 8TB चाहिए (लंबे समय में देखने वाला मुद्दा!). Hetzner में 10TB box की कीमत लगभग 20 यूरो/माह है, इसलिए caching जरूरी लगेगी। wplace drawing layer में 1000x1000 pixel PNG यूज़ करती है, चित्र तुरंत दिखता है लेकिन map बहुत धीमी है और कुछ हिस्से तो बिल्कुल नहीं दिखते।
- Hetzner में 20 यूरो/माह ठीक लगता है, लेकिन वास्तविक जरूरत के समय हर वक्त सही चलेगा, यह अलग बात है।
लगता है open files की सीमा ही समस्या रही होगी; अगर सिर्फ वही limit बढ़ाई जाती तो शायद संभाला जा सकता था। spam traffic ब्लॉक करना समझ में आता है, लेकिन theory में सिर्फ limit बढ़ाकर शायद ज्यादा process नहीं कर सकते थे—यह सवाल है।
- कई LLMs और लंबी debugging के बाद nginx community forum पर प्रश्न पोस्ट किया। अभी लगता है कारण multi_accept, open_file_cache और worker_rlimit_nofile के combination में है। विवरण के लिए यहाँ देखें। server पहले ही 200 Mbps तक प्रयोग पर था, इसलिए limit बढ़ाने पर भी शायद लंबे समय तक नहीं टिकता।
जिन साइटों में caching नहीं होता, क्या वे बस 'तंग आकर' ऐसा छोड़ देती हैं? जब wplace.live इतना traffic सीधे openfreemap पर भेजता है, तो क्या अपनी server पर सिर्फ एक caching server रखकर openfreemap से तेज़ या लगभग समान service नहीं दे सकता?
- openfreemap CDN के पीछे है, और homepage पर ऐसा लिखा है: "Public instance free, नो views/requests की limit नहीं, sign-up/cookie/API key की जरूरत नहीं। खर्च donations से cover होता है। commercial use allowed।" इसे पढ़कर लगता है कि सीधे इस्तेमाल करने के लिए ही बना है। CDN के आगे cache server रखने की जरूरत शायद नहीं लगती। bandwidth देख कर निर्णय लिया जा सकता है, लेकिन unexpected virality में दूसरे काम भी आ सकते हैं।
- इस प्रश्न का सीधा जवाब शायद यही है: प्राथमिकता। मैं एक काफ़ी popular auction site run कर रहा हूँ और map tiles stadia maps से लेता हूँ। मैं महीने के $80 देता हूँ; मुझे पता है कि tiles को cache करके proxy में serve करूँ तो सस्ता पड़ सकता है, लेकिन हमेशा कुछ ज्यादा ज़रूरी काम रहता है इसलिए अभी तक caching नहीं की।
- यहाँ handled data की मात्रा भारी है। एक बार 56Gbps spike दिखा था (56 सर्वर 100% traffic consumption पर थे)। केवल एक सामान्य caching server से इसे cover करना संभव नहीं। ऐसा load CDN network (Cloudflare जैसी) के level पर ही handle किया जा सकता है।
- साइट शायद entertaining और non-profit लगती है। ऐसी साइटों में फोकस आमतौर पर "बस चलता रहे" पर होता है, और large-scale traffic handling पहले नंबर पर नहीं होता। यूजर base एक रात में दो गुना बढ़ गया था, और शायद maintenance अकेला या बहुत छोटा समूह कर रहा है।
मैंने सीधे Cloudflare use नहीं किया और web map tech में भी उतना comfort नहीं है। अगर साइट की ज़्यादातर चीज़ें static files हैं, तो फिर Hetzner क्यों continue करना चाहिए? क्या इसे पूरी तरह Cloudflare Pages पर shift नहीं किया जा सकता?
- Tile rendering की जरूरत है। अक्सर इस्तेमाल होने वाले tiles पहले से cache हो जाते हैं, और ये cache role Cloudflare संभालता है। theory में tileserver को Cloudflare Pages पर port किया जा सकता है, लेकिन आख़िर में porting का काम करना होगा और शायद cost कम नहीं होगा।
Referrer-based limit अजीब choice लगती है। अगर normal user प्रति मिनट 10~20 requests करे, तो per IP 100 requests/minute (average का 5x) रखकर अधिकांश रोक नहीं सकते? या कुछ malicious users को JA4/JA3 pattern से रोकना आसान नहीं होगा?
- कोई उपयोगकर्ता सच में दुनिया के अलग-अलग जगह explore करना चाहता है। पहले मैंने Google Earth में आधा दिन explore किया था। मुझे लगता है referrer-based limit बेहतर है; (बहुत traffic वाले) users को सीधे public instance की जगह self-hosting suggest किया जा सकता है।
- referrer-based limiting अच्छा पहला step है (मुख्य पेज का संदेश शायद बदलना पड़े)। साइट-स्तर पर usage track करना ज्यादा effective लगेगा। साइट से request pattern बदलने को कहा जा सकता है, लेकिन individual users के लिए कठिन होगा। IP-based limit जोड़ना अच्छा है, पर बहुत low रखी तो ऐसे मामलों में असर नहीं दिखेगा।
लगता है आपने अच्छा block किया। ये ddos attack था। bandwidth charges अलग से नहीं देने पड़े, अच्छा हुआ, वरना ये सच में 'wallet-draining' attack हो जाता।
cache hit rate बहुत उच्च है। कोई खास तकनीक खास तौर पर implement की गई है क्या?
- पूरी route structure और location block को cache ध्यान में रखकर हमने खुद design किया। देखना चाहें तो nginx.conf का उदाहरण देखिए।