अच्छा सुझाव देने के लिए धन्यवाद। आपने जो कहा कि “लेटेंसी कम करने के लिए state की ज़रूरत होती है”, वह हमारे architecture के एक प्रमुख trade-off को बिल्कुल सही ढंग से पकड़ लिया।
सबसे पहले query latency की बात करूँ तो, हमारे benchmark में p99 (99th percentile) लगभग 130-210ms के स्तर पर होता है। शायद आपने जो 100x फर्क का ज़िक्र किया, वह पोस्ट में बताए गए “cold start में कई सेकंड लग सकते हैं” वाले सबसे खराब (worst-case) केस को देखकर कहा है। जैसा आपने इंगित किया, यह निश्चित ही हमारे architecture की कमजोरी है, और जैसा पोस्ट में उल्लेखित है, production में यह 0.01% से कम (P99.99) पर होता है। बाकी ज्यादातर queries प्रत्येक lambda के local memory और disk को cache की तरह इस्तेमाल करके स्थिर performance देने के लिए design की गई हैं।
इसलिए जैसा आपने कहा, सभी queries के 10ms से नीचे गारंटी होनी जरूरी हो ऐसे ultra-low-latency वित्तीय ट्रेडिंग सिस्टम जैसे मामलों में यह architecture शायद उपयुक्त नहीं हो। लेकिन अधिकांश AI-आधारित search और recommendation applications में P99 के हिसाब से 100-200ms latency पर्याप्त अच्छी performance मानी जा सकती है, और infrastructure खर्च तथा operational overhead को 90% से अधिक घटाने का फायदा इससे कहीं ज्यादा बड़ा है।
एक बार फिर से आपके thoughtful feedback के लिए धन्यवाद।
"डेवलपर्स चिंता नहीं करते" में जिन डेवलपर्स की बात हो रही है, वे शायद वे senior लोग होंगे जिन्होंने कुछ हद तक करियर बना लिया है। वैसे भी कंपनी के नज़रिए से freshers को hire करने की वजह कम होती जा रही है, ऊपर से AI भी आ गया है, और AI का इस्तेमाल senior लोग बेहतर करेंगे, यह तो लगभग तय ही है....
संकल्पना अच्छी है, लेकिन क्वेरी लेटेंसी कम करने के लिए state की जरूरत अनिवार्य रूप से पड़ती है। MySQL और PostgreSQL से तुलना करने पर क्वेरी लेटेंसी लगभग 100 गुना ज्यादा लगती है। यह लगभग वैसा लगता है जैसे फाइल सिस्टम में इनपुट और आउटपुट हो रहा हो।
यह लेख पढ़ते-पढ़ते TaskPaper ऐप याद आ गया। यह plain text आधारित है और outliner की तरह काम करता है ...
मैं खुद Things को ही 10 साल से थोड़ा ज़्यादा समय से इस्तेमाल कर रहा हूँ, और वही सबसे सुविधाजनक लगा।
macOS के लिए Things की quick entry Autofill सुविधा इतनी आकर्षक है कि ...
धन्यवाद, यह निश्चित रूप से बहुत मददगार होगा ✌️
शुरुआत में मैंने इसे n8n से सेटअप किया था, लेकिन बाद में AWS Lambda + @ पर स्विच कर दिया 🙇♂️
मैं इसे ऐसे ही manage कर रहा हूँ, haha
एक बार खुद बनाकर देखने की सलाह दूँगा, मज़ेदार है 👍
अच्छा सुझाव देने के लिए धन्यवाद। आपने जो कहा कि “लेटेंसी कम करने के लिए state की ज़रूरत होती है”, वह हमारे architecture के एक प्रमुख trade-off को बिल्कुल सही ढंग से पकड़ लिया।
सबसे पहले query latency की बात करूँ तो, हमारे benchmark में p99 (99th percentile) लगभग 130-210ms के स्तर पर होता है। शायद आपने जो 100x फर्क का ज़िक्र किया, वह पोस्ट में बताए गए “cold start में कई सेकंड लग सकते हैं” वाले सबसे खराब (worst-case) केस को देखकर कहा है। जैसा आपने इंगित किया, यह निश्चित ही हमारे architecture की कमजोरी है, और जैसा पोस्ट में उल्लेखित है, production में यह 0.01% से कम (P99.99) पर होता है। बाकी ज्यादातर queries प्रत्येक lambda के local memory और disk को cache की तरह इस्तेमाल करके स्थिर performance देने के लिए design की गई हैं।
इसलिए जैसा आपने कहा, सभी queries के 10ms से नीचे गारंटी होनी जरूरी हो ऐसे ultra-low-latency वित्तीय ट्रेडिंग सिस्टम जैसे मामलों में यह architecture शायद उपयुक्त नहीं हो। लेकिन अधिकांश AI-आधारित search और recommendation applications में P99 के हिसाब से 100-200ms latency पर्याप्त अच्छी performance मानी जा सकती है, और infrastructure खर्च तथा operational overhead को 90% से अधिक घटाने का फायदा इससे कहीं ज्यादा बड़ा है।
एक बार फिर से आपके thoughtful feedback के लिए धन्यवाद।
65GB है, इसलिए... अफ़सोस है टीटी
मैंने भी इसे करने का सोचा था, लेकिन कर नहीं पाया.. हाहा
क्या यह n8n से बनाया गया है??
"डेवलपर्स चिंता नहीं करते" में जिन डेवलपर्स की बात हो रही है, वे शायद वे senior लोग होंगे जिन्होंने कुछ हद तक करियर बना लिया है। वैसे भी कंपनी के नज़रिए से freshers को hire करने की वजह कम होती जा रही है, ऊपर से AI भी आ गया है, और AI का इस्तेमाल senior लोग बेहतर करेंगे, यह तो लगभग तय ही है....
समस्या यह है कि जूनियर्स इस लहर पर सवार नहीं हो पा रहे हैं, और जो किसी तरह इसमें उतर भी जाते हैं, उनके भी इस लहर में बह जाने का खतरा है।
लेकिन AEO, GEO भी आखिरकार SEO के साथ कुछ हद तक ओवरलैप करने वाले काम ही हैं....
लगता है अब हर सुबह देखने के लिए कुछ नया होगा। मैंने subscribe कर लिया है।
जो लोग लहर के खिलाफ खड़े होते हैं या भागते हैं, वे बह जाएंगे; और जो लोग लहर पर सवार होते हैं, वे उसका आनंद लेंगे..
लगता है कि यह LLM के ज़रिए इमेज के रूप में बनाया गया है, लेकिन देखने में अच्छा है।
मुझे भी कुछ ऐसा ही करके देखना चाहिए।
धन्यवाद 👏
मुझे लगा था 32GB काफी होगा...
फिलहाल lm studio M4 max 64gb पर नहीं चलता :(
Simple सबसे अच्छा है!
मैंने सदस्यता ले ली है। 👍
संकल्पना अच्छी है, लेकिन क्वेरी लेटेंसी कम करने के लिए
stateकी जरूरत अनिवार्य रूप से पड़ती है। MySQL और PostgreSQL से तुलना करने पर क्वेरी लेटेंसी लगभग 100 गुना ज्यादा लगती है। यह लगभग वैसा लगता है जैसे फाइल सिस्टम में इनपुट और आउटपुट हो रहा हो।यह लेख पढ़ते-पढ़ते TaskPaper ऐप याद आ गया। यह plain text आधारित है और outliner की तरह काम करता है ...
मैं खुद Things को ही 10 साल से थोड़ा ज़्यादा समय से इस्तेमाल कर रहा हूँ, और वही सबसे सुविधाजनक लगा।
macOS के लिए Things की quick entry Autofill सुविधा इतनी आकर्षक है कि ...