Firebase-tools: कार्यों का परिनियोजन अत्यंत धीमा

दाखिल करने के लिए धन्यवाद! हम जानते हैं कि धीमी तैनाती कार्य अनुभव के लिए एक प्रमुख दर्द बिंदु है, और यह कुछ ऐसा है जिसे हम विभिन्न रणनीतियों के माध्यम से हल करने के लिए काम कर रहे हैं।

@laurenzlong
पहली नज़र में फायरबेस के लिए नौसिखिया के रूप में मैंने सोचा कि मैं कुछ गड़बड़ कर रहा था, क्योंकि तैनाती हमेशा _functions पर रुक जाती है: अपलोड करने के लिए फ़ंक्शन निर्देशिका तैयार करना..._ भाग।
कुछ अतिरिक्त जानकारी देना (जैसे: इसे पूरा होने में 3-5 मिनट लगते हैं) वास्तव में अच्छा होगा, जब तक कि समस्या हल नहीं हो जाती।

एक नौसिखिया के रूप में, मैंने इस सोच को रद्द करने में कई बार बिताया कि मैं कुछ गलत कर रहा था।

समस्या एक प्रकार से स्पष्ट है। इनिट कमांड ने एक 'नोड मॉड्यूल' फोल्डर बनाया जो बहुत बड़ा है। मेरी मशीन पर यह है: 22,903 फ़ाइलें, 2,782 फ़ोल्डर। कोड उन सभी को एक अस्थायी फ़ोल्डर में कॉपी करता है।

मैंने जो किया था यह रहा:

1. लॉग प्रिंट स्टेटमेंट का उपयोग करते हुए, मैंने कोड की धीमी लाइन की पहचान की। यह यहां पर है:
   https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L26

लाइन 26 में तैयार फंक्शन्सअपलोड.जेएस:
fs.copySync(options.config.path(options.config.get('functions.source')), tmpdir.name);

1. मैंने उस फ़ाइल कॉपी कॉल के लिए मापदंडों का प्रिंट आउट लिया। मेरी मशीन पर यह है:
   C:\Users\thoma\StudioProjects\LSystemAndroid\firestorefunctions
   -> C:\Users\thoma\AppData\Local\Temp\fbfn_752624vejX0cv3GEJI

फंक्शन फोल्डर CLI कमांड init द्वारा बनाया गया था। यह इस तरह दिख रहा है:

• node_modules (विशाल आकार)
• .gitignore
• index.js
• पैकेज.जेसन
• pacakge-lock.json

मुझे ऐसा लगता है कि CLI कमांड init को उस node_modules फ़ोल्डर को नहीं बनाना चाहिए था। यह 165MB बड़ा है। यह हर परियोजना में जोड़ने के लिए अनुचित लगता है।

@thomasfishersm

वास्तव में यह बात नहीं है। नोड_मॉड्यूल्स को अस्थायी फ़ोल्डर में कॉपी नहीं किया गया है, जैसा कि आप यहां इस लाइन से देख सकते हैं: https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L76

firebase init के लिए फ़ंक्शन स्रोत फ़ोल्डर के अंदर स्थानीय रूप से सभी नोड मॉड्यूल स्थापित करने के लिए आवश्यक है, अन्यथा स्थानीय रूप से फ़ंक्शन की सेवा करने से काम नहीं चलेगा, और ट्रिगर निष्कर्षण काम नहीं करेगा (इस तरह सीएलआई समझता है कि कौन सी घटनाएं प्रत्येक को ट्रिगर करती हैं कार्य करें ताकि यह उन्हें ठीक से तैनात कर सके)।

मैंने लाइन 26 से पहले और बाद में डिबग प्रिंट लाइन लगाई। उस लाइन में मिनट लगे।

फिर, मैंने प्रिंट करने के लिए एक फ़िल्टर जोड़ा कि कौन सी फाइलें कॉपी की जा रही हैं। इसमें सभी नोड_मॉड्यूल फ़ाइलें शामिल थीं।

फिर, मैंने नोड_मॉड्यूल फ़ाइलों को बाहर करने के लिए फ़िल्टर को बदल दिया। तैनाती अब तेजी से आगे बढ़ी। हालाँकि थोड़ी देर बाद, ऐसा लगा कि स्क्रिप्ट क्लाउड फ़ंक्शंस की शुद्धता का मूल्यांकन करने की कोशिश कर रही है। वह कोड विफल हो गया क्योंकि उसमें पुस्तकालय निर्भरताएँ गायब थीं।

आप जिस स्रोत कोड लाइन की ओर इशारा करते हैं, वह बाद का चरण प्रतीत होता है। ऐसा लगता है कि फ़ाइलें (माइनस नोड_मॉड्यूल्स) क्लाउड पर अपलोड करने से पहले एक ज़िप फ़ाइल में संग्रहीत की जाती हैं। वह लाइन मेरी मशीन पर धीमी गति से नहीं चल रही है।

हाँ, आप सही कह रहे हैं, मुझसे गलती हुई थी, node_modules कॉपी हो जाता है। मुझे लगता है कि यह एक वैध विचार है कि नोड_मॉड्यूल्स को अस्थायी निर्देशिका में कॉपी न करें। यह थोड़ा जटिल है कि सीएलआई पार्सिंग को ट्रिगर करने से पहले अस्थायी फ़ोल्डर में ".runtimeconfig.json" लिखता है, और यह फ़ाइल शेष फ़ंक्शन स्रोत कोड के साथ अपलोड हो जाती है, और हम लिखना नहीं चाहते थे यह फ़ाइल वास्तविक स्रोत कोड निर्देशिका में है। तो शायद एक अच्छा समाधान है कि दोनों तैनाती की गति में सुधार करते हैं और यह सुनिश्चित करते हैं कि अनपेक्षित दुष्प्रभाव नहीं हैं, लेकिन मुझे थोड़ा सा खेलना होगा। आप एक पुल अनुरोध करने के लिए भी स्वतंत्र महसूस कर सकते हैं।

मुझे एक ही समस्या हो रही है। "निर्देशिका तैयार कर रहा है ..." चरणों के दौरान अधिक संदेशों को प्रिंट करना एक अच्छा विचार हो सकता है ताकि उपयोगकर्ता को यह न लगे कि फायरबेस-टूल्स हैंग हो रहा है।

संपादित करें: यह उबंटू डब्लूएसएल पर था। लिनक्स पर, "तैयारी" चरण लटका नहीं है। "बनाने का कार्य" चरण धीमा हो सकता है, लेकिन उतना नहीं जितना मैंने पहले अनुभव किया था।

यह मुद्दा चूतड़ में एक वास्तविक दर्द है। मुझे लगता है कि इसे उच्च प्राथमिकता दी जानी चाहिए: /

मैं अपनी परियोजना में फायरबेस कार्यों को लागू करने की कोशिश कर रहा हूं और इस त्रुटि के कारण मुझे इसे स्थगित करना पड़ा।
इस त्रुटि ने मेरा बहुत समय बर्बाद किया।
आशा है कि यह जल्द ही ठीक हो जाएगा!

यह मुद्दा एक बड़ी बाधा है। ज्यादातर इसलिए कि मैं फायरस्टोर का उपयोग करता हूं और उस सामान जैसे एग्रीगेट्स, काउंटर और उपस्थिति को केवल क्लाउड फ़ंक्शंस द्वारा शालीनता से नियंत्रित किया जा सकता है और यह हर बार 5 मिनट के लिए लटका रहता है।

@PulpoEnPatineta यह कोई त्रुटि नहीं है। यह सिर्फ तैनाती के समय के साथ एक मुद्दा है।

@McStuffins यदि आपकी कार को चालू होने में पाँच मिनट लगते हैं, तो क्या यह एक त्रुटि है या बस प्रारंभ समय के साथ कोई समस्या है?

क्या इसे ठीक करने का कोई तरीका है? यह वास्तव में बेहद धीमा है।

मैंने शुरू से ही इस मुद्दे पर नज़र रखी, लेकिन यह मेरे लिए कभी कोई समस्या नहीं रही क्योंकि मेरे पास एक सीडी है और यह मेरे लिए सभी काम करती है। अगर वे काम करते हैं तो परीक्षण करने के लिए मैं कभी भी कार्यों को तैनात नहीं करता हूं। तो मूल रूप से यह मेरे लिए कोई मायने नहीं रखता था।

आज तक, जब मुझे एक अप्रत्याशित सीमा का सामना करना पड़ा: मैं अब अपने कार्यों को तैनात नहीं कर सकता, क्योंकि उत्पादन में तैनाती दैनिक कोटा (12,000 सेकंड) से अधिक है। मेरे पास विभिन्न ट्रिगर्स (पबसुब, फायरस्टोर, https) के साथ ~ 55 कार्य हैं। क्या इसे संभालना बहुत ज्यादा है?

अब मुझे अपने आवेदन को दो दिनों के लिए तैनात करना है: rofl:: लॉलीपॉप:: +1:: 1st_place_medal:: ताबूत:: टैको:: कैक्टस:: डांसर:: मुस्कान_इम्प:

कभी-कभी, जब मैं तैनाती कर रहा होता हूं, तो यह बेहद धीमा होता है, और फिर टर्मिनल में एक चेतावनी होती है जो कहती है "निर्माण वातावरण में त्रुटि"

@srinurp कृपया ऊपर से लिंक किए गए पुल अनुरोध को देखें, यह समस्या के एक हिस्से को संबोधित करेगा। और बैकएंड टीम समस्या के अन्य हिस्सों को संबोधित करने के लिए काम कर रही है (लेकिन यह एक बहुत ही जटिल उपक्रम है, इसलिए हम आपके धैर्य की सराहना करते हैं।)

@merlinnot जब तक आप प्रत्येक तैनाती के साथ अपने सभी कार्यों के लिए कोड अपडेट नहीं कर रहे हैं, मैं व्यक्तिगत कार्यों या कार्यों के समूहों को तैनात करने के लिए --only कमांड का उपयोग करने की अनुशंसा करता हूं। https://firebase.google.com/docs/cli/#partial_deploys देखें।

@McStuffins "निर्माण के वातावरण में त्रुटि" आमतौर पर एक उत्पादन समस्या को इंगित करता है, उस स्थिति में कृपया https://firebase.google.com/support/ पर एक समर्थन टिकट दर्ज करें, आप देख सकते हैं कि क्या कोई उत्पादन समस्या चल रही है फायरबेस स्थिति डैशबोर्ड

@laurenzlong मुझे तैनाती के बीच प्रत्येक फ़ंक्शन में स्वचालित रूप से परिवर्तनों का पता लगाने के लिए अपने सीआई को कॉन्फ़िगर करना होगा (निर्भरता को हल करने सहित)। और क्या होगा यदि मैं firebase-functions , firebase-admin , lodash आदि जैसे पैकेज अपडेट करता हूं, जिनका मैं हर एक फ़ंक्शन में उपयोग करता हूं?

@merlinnot यह एक बहुत ही वैध उपयोग का मामला है। परिनियोजन कोटा Google क्लाउड फ़ंक्शंस द्वारा नियंत्रित होते हैं, मैं उनके सार्वजनिक मुद्दों ट्रैकर पर एक अनुरोध दर्ज करने की अनुशंसा करता हूं: https://cloud.google.com/functions/docs/support

रुचि रखने वाले सभी लोगों के लिए: https://issuetracker.google.com/issues/71385193

@laurenzlong स्रोत की प्रतिलिपि बनाते समय node_modules फ़ोल्डर को अनदेखा किया जा सकता है और फिर npm install --production या yarn install --production करें? चूंकि ये उपकरण केवल कॉपी और पेस्ट करने की तुलना में तेज़ हो सकते हैं।

@horacehylee
यह एक तोड़ने वाला बदलाव हो सकता है। कुछ लोग (स्वयं शामिल) अभी भी एक सापेक्ष पथ (जैसे "पैकेज-नाम": "./externs/package.tgz") द्वारा पैकेज का संदर्भ दे सकते हैं, ज्यादातर 'निजी भंडार के साथ ( अब तय ) समस्या का कारण। उपकरण को इन सभी कोने के मामलों को ध्यान में रखना होगा।

दूसरी बात कैशिंग है: अगर Google को आपकी ओर से पैकेज डाउनलोड करना था, तो उन्हें कुछ आंतरिक कैशिंग तंत्र को लागू करना होगा। हम सभी के कंप्यूटर पर स्थानीय कैश होते हैं (एनपीएम और यार्न दोनों में कैशिंग तंत्र होते हैं), इसलिए हम एनपीएम के सर्वर को नहीं मारते हैं;)

कुछ लोग बाहरी पुस्तकालयों में कुछ बदलावों का परीक्षण करना भी चाह सकते हैं। एक फ़ाइल को बदलना और फ़ंक्शन को तैनात करना एक कांटा बनाने, परिवर्तन करने, अस्थायी रूप से पैकेज के संदर्भ को बदलने की तुलना में बहुत आसान है, ...

निचली पंक्ति: यह ठीक काम करता है, इसे अभी छोड़ दें: +1:

@horacehylee @merlinnot 2 सेंट के लिए धन्यवाद। कृपया https://github.com/firebase/firebase-tools/pull/578 देखें, सीएलआई की अगली रिलीज अब फ़ंक्शन स्रोत फ़ोल्डर अवधि की प्रतिलिपि नहीं बनाएगी।

मुझे सच में यकीन नहीं है कि फायरबेस ऐसा क्या कर सकता है जो 1 जीबीपीएस फाइबर कनेक्शन पर बैठे छह 4GHz कोर मशीन पर 5 लाइन, 1kb फ़ंक्शन को तैनात करने में MINUTES लेता है।

मुझे पता है कि ऐसा लगता है कि मैं पेशाब कर रहा हूं, लेकिन मैं वास्तव में उत्सुक हूं कि "अपलोड के लिए निर्देशिका तैयार करने" के दौरान क्या हो रहा है। वास्तव में कोई जानता है?

एक tmp dir में नोड मॉड्यूल सहित, अपने फ़ंक्शन निर्देशिका की प्रतिलिपि बनाना।

हमारी अगली रिलीज़ इसे संबोधित करेगी और अब इसे पहले कॉपी करने की आवश्यकता नहीं है
तैनाती

सूर्य पर, 7 जनवरी 2018, 5:05 अपराह्न hmexx [email protected] ने लिखा:

मुझे सच में यकीन नहीं है कि फ़ायरबेस क्या कर सकता है जिसमें MINUTES लगते हैं
a . पर बैठे छह 4GHz कोर मशीन पर 5 लाइन, 1kb फ़ंक्शन परिनियोजित करें
1 जीबीपीएस फाइबर कनेक्शन।

मुझे पता है कि ऐसा लगता है कि मैं पेशाब कर रहा हूँ, लेकिन मैं वास्तव में उत्सुक हूँ क्या
"अपलोड के लिए निर्देशिका तैयार करने" के दौरान चल रहा है। वास्तव में कोई जानता है?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/firebase/firebase-tools/issues/536#issuecomment-355868154 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAAD_nUptJWFuYGvEXI0MwmQR-bG9_MKks5tIWm1gaJpZM4QdF3g
.

@mbleeigh

ठीक है। इससे स्पष्ट हुआ। यह एक तरह का हास्य है कि एक वर्कस्टेशन एक या दो मिनट के लिए पागल हो जाता है, केवल अगली पंक्ति का प्रिंट आउट "पैकेज्ड फ़ंक्शंस ( 37.55kb !!!) सफलतापूर्वक अपलोड करने के लिए" lol

अगली रिलीज की प्रतीक्षा करें। जवाब देने के लिए Thx।

एच।

दिन 19. फायरबेस अभी भी तैनात है। *पकौड़े पॉपकॉर्न*

हां।

अगली रिलीज़ कब निर्धारित की गई है, और हमें परिनियोजन समय में कितने% सुधार की उम्मीद करनी चाहिए?

बस यह जानने के लिए कि क्या इस रास्ते पर चलते रहना है।

रिलीज इस सप्ताह होनी चाहिए, और आप "तैयारी" की उम्मीद कर सकते हैं
तैनाती के लिए कार्य निर्देशिका" कदम काफी तेजी से जाने के लिए (मैं नहीं
सटीक संख्याएँ हैं)। तैनाती के अन्य हिस्से अपरिवर्तित रहेंगे।

सोम, 15 जनवरी, 2018 को दोपहर 12:42 बजे hmexx [email protected] ने लिखा:

हां।

अगली रिलीज़ कब होगी, और परिनियोजन में कितना% सुधार होगा
हमें कितनी बार उम्मीद करनी चाहिए?

बस यह जानने के लिए कि क्या इस रास्ते पर चलते रहना है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/firebase/firebase-tools/issues/536#issuecomment-357784792 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAAD_vaj-WngS9dMj7j5Q2AesM0tNMvVks5tK7hBgaJpZM4QdF3g
.

यह जारी किया गया था!

@mbleeigh क्या यह रिलीज 3.17.4 में है?

@jkossis v3.17.0

रिलीज नोट्स से:

यदि आप फ़ंक्शन परिनियोजित कर रहे हैं, तो आपको अपनी फ़ंक्शन निर्देशिका के अंदर "npm i --save firebase-functions@latest " चलाकर फ़ायरबेस-फ़ंक्शंस SDK को नवीनतम में अपडेट करना होगा। यह तेजी से कार्यों की तैनाती को सक्षम बनाता है।

मिनटों से सेकंड तक: अच्छा काम!

मेरे लिए इसमें अभी भी मिनट लगते हैं।

मेरे पास [email protected] और [email protected] है। इस समस्या को और अधिक डीबग करने में सहायता के लिए मैं क्या कर सकता हूं?

यहाँ केवल कार्यों को परिनियोजित करने से समयबद्ध आउटपुट है। मैंने नाम बदल दिए हैं लेकिन वे आरईएसटी एंडपॉइंट्स, डेटाबेस और ऑथ ट्रिगर्स का संयोजन हैं।

➜  functions git:(master) ✗ firebase --version
3.17.4
➜  functions git:(master) ✗ time firebase deploy --only functions

=== Deploying to 'XXX'...

i  deploying functions
i  functions: ensuring necessary APIs are enabled...
✔  functions: all necessary APIs are enabled
i  functions: preparing functions directory for uploading...
i  functions: packaged functions (123.07 KB) for uploading
✔  functions: functions folder uploaded successfully
i  functions: updating function 1...
i  functions: updating function 2...
i  functions: updating function 3...
i  functions: updating function 4...
i  functions: updating function 5...
i  functions: updating function 6...
✔  functions[1]: Successful update operation.
Function URL (1): https://us-central1-XXX.cloudfunctions.net/1
✔  functions[3]: Successful update operation.
✔  functions[4]: Successful update operation.
✔  functions[5]: Successful update operation.
✔  functions[6]: Successful update operation.
✔  functions[2]: Successful update operation.
Function URL (2): https://us-central1-XXX.cloudfunctions.net/2

✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/XXX/overview
firebase deploy --only functions  4.59s user 1.07s system 1% cpu 6:09.26 total

@adamduren preparing functions directory for uploading... . में खर्च किए गए अत्यधिक समय के लिए फिक्स था

खुद को तैनात करने में अभी भी काफी लंबा समय लग सकता है।

एक ही स्थिति में ढेर:

"firebase-admin": "^5.8.2",
"firebase-functions": "^0.8.1",

npm install -g npm@latest ने मुझे थोड़ा अलग इनपुट दिया, और firebase-cli को हटाने से भी कुछ बदल गया।

अपडेट करें:

ठीक है, npm install -g firebase-tools चलाने के बाद आखिरकार यह काम कर गया। यश की प्रशंसा

नमस्ते, मुझे एक ही बिंदु पर एक समस्या आ रही है ("फ़ंक्शन निर्देशिका तैयार कर रहा है ..")
लेकिन मेरे मामले में इसे पूरा करने में 25/30 मिनट से अधिक समय लगा
मेरे पास 4 निजी निर्भरताएं हैं जिनका वजन लगभग 2.20 mb . है
मैंने पाया कि निजी निर्भरताओं को संपीड़ित फ़ाइलों के रूप में शामिल करने का यही एकमात्र तरीका था।
क्या मुझसे कुछ गलत हो रही है? या यह तरीका काम करने वाला है?

2018-5-9
firebase deploy अभी भी धीमा है, पता नहीं क्यों

क्या आपने पिछले संस्करण में अपडेट किया है? मैंने पिछले हफ्ते अपडेट किया और अब मेरी तैनाती में 1-3 मिनट लगते हैं (25/30 से)

मैं कुछ सरल के लिए 4+ मिनट का परिनियोजन समय देख रहा हूं:

const functions = require('firebase-functions')

exports.test = functions.https.onRequest((req, res) => {
  res.send('Hello World')
})

i functions: updating function test... लटकी हुई रेखा है।
यह इतना धीमा कभी नहीं हुआ करता था!

@Robula क्या आपने फायरबेस-टूल्स के नवीनतम संस्करण में अपडेट किया है?

हां, मेरा ऐसा मानना ​​है। firebase —version रिपोर्ट 3.18.6।

आप मुझसे बाद के संस्करण पर हैं। मुझे यकीन नहीं है कि शायद वे 3.18.6 में फिर से नोड_मॉड्यूल्स फ़ोल्डर को स्थानांतरित करना जारी रखते हैं, लेकिन फिलहाल 3.18.4 के साथ, सब कुछ ठीक चल रहा है ...

हाल के फायरबेस-टूल्स संस्करणों में परिनियोजन रणनीति में कोई प्रतिगमन नहीं हुआ है (नोड_मॉड्यूल्स फ़ोल्डर की प्रतिलिपि नहीं बनाई गई है), हालांकि परिनियोजन समय मशीन से मशीन और समय-समय पर भिन्न होता है। किसी फ़ंक्शन का प्रारंभिक परिनियोजन भी बाद के अपडेट की तुलना में धीमा है।

मैं preparing functions directory for uploading... चरण के दौरान परिनियोजन समय देख रहा हूं, स्थानीय रूप से चलते समय अकेले इस चरण पर लगभग 7 मिनट लगते हैं। बिल्ड के लिए पूर्व-तैनाती चरण स्थानीय रूप से लगभग 5 सेकंड लेता है। डिबग से चलाने के रूप में बहुत जल्दी के रूप में परिनियोजन प्रक्रिया में अन्य सभी चरण। मुझे लगता है कि तैनाती कुछ हद तक धीमी हो सकती है, लेकिन मैं काम के लिए एडब्ल्यूएस लैम्ब्डा का भी उपयोग करता हूं और बहुत बड़ी लैम्ब्डा तैनाती इससे बहुत तेज होती है, 2 दो 3 मिनट के आदेश पर, जिसमें पायथन पैकेज इंस्टॉल और बिल्ड शामिल है।

यहां तक ​​​​कि Google क्लाउड बिल्ड से तैनात करने में 2 से 3 मिनट लगते हैं, बनाम लैम्ब्डा में 10 से 20 सेकंड। मैं सिर्फ यह पूछना चाहता हूं कि क्या क्ली अपलोड करने से पहले पूरे फ़ंक्शन फ़ोल्डर को ज़िप कर रहा है?

@laurenzlong , क्या आप विस्तृत कर सकते हैं कि क्या फ़ंक्शन पहले से ही समानांतर में तैनात हैं, या यदि यह अनुकूलन कार्यों में है?

कार्यों को हमेशा समानांतर में तैनात किया गया है। हालांकि, कृपया ध्यान दें कि समानांतर में 10 फ़ंक्शन को परिनियोजित करना एकल फ़ंक्शन को परिनियोजित करने की तुलना में अभी भी धीमा है।

+1 फ़ंक्शन को परिनियोजित करना बेहद धीमा है। मैंने प्रति घंटा-टिक फ़ंक्शन बनाने के लिए क्रॉन जॉब ट्यूटोरियल का पालन किया, मेरा पहला स्वर, और इसे हर बार तैनात करने में एक मिनट लगता है।

@laurenzlong फ़ायरबेस पर आपकी कड़ी मेहनत के लिए प्रतिक्रिया और धन्यवाद के लिए बहुत बहुत धन्यवाद!

क्या तैनाती के समय में सुधार के लिए कोई सक्रिय योजना है? मैं पूछता हूं क्योंकि हालांकि हमें फायरबेस पसंद है, हम वास्तव में धीमी तैनाती के समय के कारण इससे दूर जाने की सोच रहे हैं। हमारे पास लगभग 47 क्लाउड फंक्शन हैं और हमारी तैनाती में नियमित रूप से 3-6 मिनट लगते हैं। इसकी तुलना git push heroku master से करें, जो हरोकू में कोड की समान मात्रा को परिनियोजित करने में लगभग 20-30 सेकंड का समय लेगा। और वह कोड तुरंत हरोकू पर चल रहा होगा। फायरबेस के साथ हमें तैनाती के बाद एक और 20-30 (यादृच्छिक) समय की प्रतीक्षा करनी होगी, इससे पहले कि तैनात कार्य वास्तव में चल रहे हों (इस समय के दौरान, नए और पुराने कार्यों का मिश्रण चलता है)।

तो परिनियोजन अनुभव की तुलना करें:

*** Heroku:

git push heroku master

20-30s later ...

All newly-deployed functions are now running in a consistent/atomic way

*** Firebase:

firebase deploy --only functions

180-360s later ...

Functions are deployed but only some of the new ones are running, some old ones are still running

20-30s later ... 

All new functions running

फायरबेस के साथ परमाणु तैनाती करना भी मुश्किल है क्योंकि तैनाती के बाद, समय की अवधि होती है, जिसके दौरान कुछ नए कार्यों, उन्हें v_n+1 कहते हैं, कुछ पुराने कार्यों के साथ चल रहे हैं v_n । इसलिए यदि आप एक बड़ा अपडेट करते हैं, तो आपके पास विभिन्न डेटा प्रारूपों या एल्गोरिदम का उपयोग करके संभवतः चलने वाले नए और पुराने कार्यों का मिश्रण है। यह हरोकू परिनियोजन की तुलना में बहुत कम सुरक्षित है जहाँ या तो सभी नए कार्य तैनात हैं और केवल नए कार्य चल रहे हैं या कोई भी परिनियोजित नहीं है।

इसके अलावा, कभी-कभी हमारे 47 कार्यों में से कुछ त्रुटियों के साथ परिनियोजित करने में विफल हो जाते हैं जैसे

⚠  functions[retrieveFavorites(us-central1)]: Deployment error.
Server Error. getaddrinfo ENOTFOUND cloudfunctions.googleapis.com cloudfunctions.googleapis.com:443

हम अत्यधिक विश्वसनीय सममित गीगाबिट इंटरनेट पर तैनात कर रहे हैं, इसलिए समस्या हमारे नेटवर्क की नहीं है।

तो हेरोकू को एक परमाणु डीबी लेनदेन (सभी या कुछ भी नहीं) के रूप में तैनात करने के बारे में सोचें जबकि फायरबेस तैनाती अंततः आंशिक विफलताओं के अनुरूप है ... यह देव ओप को और अधिक कठिन बनाता है, खासकर यदि आप एक बग फिक्स को दबा रहे हैं एक पृष्ठ के जवाब में आधी रात।

स्पष्ट रूप से, फायरबेस पर तैनाती का अनुभव हेरोकू या एडब्ल्यूएस की तुलना में निष्पक्ष रूप से धीमा और कम विश्वसनीय है ... मुझे गलत मत समझो, हमें फायरबेस पसंद है और हम वास्तव में आपकी कड़ी मेहनत की सराहना करते हैं। मेरा मतलब यह नहीं है कि यह एक हमले की तरह लग रहा है, यह व्यक्तिगत कुछ भी नहीं है, लेकिन हमें यहां बेहतर करने के लिए फायरबेस की आवश्यकता है या हम कहीं और जाने की सोच रहे हैं क्योंकि तैनाती बहुत दर्दनाक है।

Firebase पर आपकी कड़ी मेहनत के लिए फिर से धन्यवाद। हम आपकी मदद के आभारी हैं :-)।

अपना डेटापॉइंट साझा करने के लिए धन्यवाद! विशेष रूप से एक ही समय में कई कार्यों को तैनात करने के लिए हमारे पास इसे सुधारने के लिए कुछ योजनाएं हैं (मुख्य रूप से फ़ंक्शन बनाने/अपडेट करने के लिए एपीआई कॉल के बाद सर्वर-साइड बिल्ड चरण में सुधार)। हालांकि, ये बुनियादी ढांचे में बदलाव हैं, जिनमें तिमाहियों का समय लगेगा, इसलिए इस बीच हम वास्तव में आपके धैर्य की सराहना करते हैं।

हो सकता है कि आपने पहले ही इस पर विचार कर लिया हो, लेकिन आप अपनी CI/CD पाइपलाइन में एक स्क्रिप्ट बना सकते हैं जो यह पता लगाती है कि कौन से फ़ंक्शन संपादित किए गए हैं, और केवल उन्हीं को --only ध्वज के साथ परिनियोजित करें। इससे आपकी तैनाती की गति में नाटकीय रूप से सुधार होगा। उदाहरण के लिए इस वीडियो को देखें: https://www.youtube.com/watch?v=iyGHW4UQ_Ts

@laurenzlong जानकारी के लिए धन्यवाद, लॉरेन। हालाँकि, मेरे पास सिर्फ एक छोटा क्लाउड फ़ंक्शन है और इसे सबसे छोटा परिवर्तन करने के बाद भी तैनात होने में लगभग 1 मिनट का समय लगता है। मैं उस झंडे का भी उपयोग करता हूं, भले ही मेरे पास सिर्फ एक क्लाउड फ़ंक्शन है। ऐसा लगता है कि यहां कुछ गलत हो रहा है।

अभी भी अप्रैल 2019 तक सचमुच मिनट लग रहे हैं - फायरबेस संस्करण 6.6.0 - मैं जो कुछ कर रहा हूं वह यहां ट्यूटोरियल का अनुसरण कर रहा है: https://firebase.google.com/docs/functions/get-started

हर बार जब मैं "फायरबेस परिनियोजन" डाउनलोड करता हूं और कुछ मिनट लेता हूं

पिछले कुछ दिनों में होस्टिंग को भी तैनात करने में कई मिनट लगते हैं, जब कुछ हफ़्ते पहले 10-15 सेकंड लगते थे। कार्यों की तैनाती का समय भी समाप्त हो गया।

और फायरबेस स्थिति पृष्ठ हरा है https://status.firebase.google.com/ ।

क्या किसी को पता है यह क्यों होता है?

firebase-tools 7.0.0 का उपयोग करना

$ firebase deploy --only=hosting --token xxx

=== Deploying to 'xxx'...

i  deploying hosting
i  hosting[xxx]: beginning deploy...
i  hosting[xxx]: found 1959 files in public
✔  hosting[xxx]: file upload complete
i  hosting[xxx]: finalizing version...
✔  hosting[xxx]: version finalized
i  hosting[xxx]: releasing new version...
✔  hosting[xxx]: release complete
✔  hosting: Finished running postdeploy script.

✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/xxx/overview
Hosting URL: https://xxx.firebaseapp.com
✨  Done in 181.75s

@laurenzlong-

हालांकि, ये बुनियादी ढांचे में बदलाव हैं, जिनमें तिमाहियों का समय लगेगा, इसलिए इस बीच हम वास्तव में आपके धैर्य की सराहना करते हैं।

कुछ तिमाहियों पहले आपके अंतिम नोट के बाद से कोई बुनियादी ढांचा-पक्ष अपडेट? जब तक ये परिवर्तन नहीं किए जाते, क्या इस मुद्दे को फिर से खोलना संभव है? जब तक ट्रैकिंग किसी भिन्न/संबंधित मुद्दे पर नहीं चली जाती है, तब तक बंद करना उचित स्थिति प्रतीत नहीं होता है।

Firebase functions सब कुछ बनने/अपलोड होने के बाद भी बहुत धीमी गति से चल रहा है और कार्यों को सर्वर साइड पर बनाया/अपडेट किया जा रहा है। जैसा कि अन्य ने कहा है, यह एक प्रमुख विकास वेग है।

firebase --version
7.1.0

विचार करने के लिए बहुत धन्यवाद!

@repentsinner बैकएंड प्रोजेक्ट बिल्ड/तैनाती समय में सुधार करने के लिए अभी भी चल रहा है (और अच्छी तरह से चल रहा है!) लेकिन यह अभी भी जारी नहीं हुआ है।

क्या आपने अपनी विकास प्रक्रिया को तेज करने के लिए एमुलेटर ( firebase emulators:start के माध्यम से) का उपयोग करने का प्रयास किया है? यदि ऐसा है तो हमें आपकी प्रतिक्रिया प्राप्त करना अच्छा लगेगा!

@samtstern अपडेट के लिए धन्यवाद।

मैंने अभी तक एमुलेटर की कोशिश नहीं की है - मैं एक स्पंदन ऐप के साथ-साथ एक फायरस्टोर में डेटा से functions.https.onCall का उपयोग कर रहा हूं, और ऐसा लगता है (फिलहाल वैसे भी) ऐप के टेस्ट बिल्ड में सब कुछ रीडायरेक्ट कर रहा है मेरे विकास कार्य केंद्र के लिए तैनाती की प्रतीक्षा करने से अधिक प्रयास है।

मुझे लगता है कि मैं उस समय का उपयोग कर सकता हूं जिसका मैं इंतजार कर रहा हूं।

इस मुद्दे को नया साल मुबारक हो जो अभी भी बंद है और अभी भी तय नहीं हुआ है! मैं

शायद एक व्यवस्थापक या ओपी इस मुद्दे का नाम बदलकर "बेहद धीमी गति से तैनाती के लिए कार्य निर्देशिका तैयार कर रहा है" क्योंकि ऐसा लगता है कि यह पूरी तरह से समग्र तैनाती प्रक्रिया के उस चरण के लिए एक फिक्स के आधार पर बंद कर दिया गया है।

हम तब से एक नया "तैनाती कार्यों को बेहद धीमा" मुद्दा खोल सकते हैं ... कार्यों को तैनात करना अभी भी बेहद धीमा है

यह समस्या इसलिए बंद कर दी गई क्योंकि परिनियोजन समय में सुधार के लिए हम सीएलआई की ओर से और कुछ नहीं कर सकते। स्थानीय विकास के लिए हम एमुलेटर में निवेश करना जारी रख रहे हैं, हम आशा करते हैं कि लोगों को केवल firebase deploy चलाना होगा, जब वे अपने विकास जीवनचक्र के हिस्से के रूप में नहीं, बल्कि उत्पादों को परिनियोजित कर रहे हों।

बैकएंड परिवर्तन अभी भी प्रगति पर हैं। जैसा कि आप बता सकते हैं, अप्रत्याशित देरी हुई है।

स्पष्टीकरण @samtstern के लिए धन्यवाद, इसलिए मुझे लगता है कि फायरबेस/फायरबेस-टूल्स के खिलाफ मुद्दे/अनुरोध केवल सीएलआई पर लागू होते हैं? बैकएंड को कवर करने वाले रेपो/प्रोजेक्ट की तलाश करेगा।

स्थानीय विकास के बारे में- चीजों के सार्वजनिक पक्ष से ऐसा लगता है कि Google वास्तव में फायरबेस और स्पंदन के एकीकरण को प्रोत्साहित कर रहा है जो टिन पर एक साथ बहुत अच्छी तरह से काम करता प्रतीत होता है, लेकिन व्यवहार में हम इस तरह की देव-समय की विसंगतियों में भाग लेते हैं। मैंने इस मुद्दे की खोज करते समय सुझाए गए एमुलेटर पर एक त्वरित नज़र डाली, लेकिन यह वास्तव में एक एकीकृत फायरबेस प्लस स्पंदन विकास वर्कफ़्लो का समर्थन करने के लिए प्रकट नहीं हुआ, निश्चित रूप से क्लाउड बैकएंड के माध्यम से उतना सुचारू रूप से नहीं। मैंने यह देखने के लिए चक्कर नहीं लगाया है कि क्या इसमें हाल ही में सुधार हुआ है, लेकिन ऐसा लगता नहीं है।

@repentsinner हाँ यह रेपो केवल सीएलआई के काम को ट्रैक करता है। बेशक हम किसी भी चीज का जवाब देने की कोशिश करते हैं, लेकिन अक्सर हमें मुद्दों को बंद करना पड़ता है जब कुछ भी उत्पादक नहीं होता है जो हम यहां कर सकते हैं। हमारे बैकएंड ओपन सोर्स नहीं हैं, इसलिए हम आम तौर पर लोगों को सामान्य फायरबेस चीजों के बारे में बग रिपोर्ट या फीचर अनुरोध फाइल करने के लिए फायरबेस समर्थन की ओर इशारा करते हैं।

स्पंदन के लिए, हम इसे प्यार करते हैं (देखें: https://github.com/FirebaseExtended/flutterfire) लेकिन यह ध्यान रखना महत्वपूर्ण है कि यह एक आधिकारिक फायरबेस प्लेटफॉर्म नहीं है, जिसका अर्थ है कि हम उन मुद्दों के लिए अपना पूर्ण समर्थन नहीं दे सकते हैं जैसे हम करते हैं देशी Android/iOS/Web. हो सकता है कि एक दिन यह बदल जाए लेकिन अभी के लिए यही स्थिति है।

यदि आपके पास अपने फ़्लटर ऐप को फायरबेस एमुलेटर से कनेक्ट करने के बारे में प्रश्न हैं, फ़्लटरफ़ायर रेपो पर एक समस्या खोलें और मुझे सीसी करें, तो मैं सही फ़्लटर लोगों को भी शामिल कर सकता हूं।

समझ गया, @samtstern स्पष्टीकरण के लिए धन्यवाद! मैं इस समय अन्य परियोजनाओं पर चला गया हूं, लेकिन जब मैं इस सामान में वापस आऊंगा तो FlutterFire रेपो में देखूंगा।

एमुलेटर ऑथ संदर्भ का समर्थन नहीं करता है, इसलिए इसका 100% पूरी तरह से बेकार IMO है।

मुझे पता चला कि मेरी तैनाती रुक गई क्योंकि मैं dotenv . का उपयोग करने की कोशिश कर रहा था

लोगों को यह याद दिलाने के लिए बस मेरा सिर थपथपाना कि यह अभी भी एक दर्द बिंदु है ️

उन लोगों के लिए जो अभी भी इस पर आ रहे हैं - एक चीज जो मुझे मददगार लगी, वह थी functions.ignore का उपयोग अनावश्यक ब्लोट अपलोड करने से बचने के लिए। मुझे लगता है कि शामिल करने के लिए एक विशेष रूप से अच्छा है .git :
{ "functions": { "ignore": ["node_modules", ".git", ".gitignore", ".nyc_output", ".runtimeconfig.json", "firebase-debug.log", "tslint.json", "tests"] }

मैंने कार्यों को पूरी तरह से छोड़ दिया क्योंकि देव वर्कफ़्लो दर्दनाक से परे है।

उन लोगों के लिए जो अभी भी इस पर आ रहे हैं - एक चीज जो मुझे मददगार लगी, वह थी functions.ignore का उपयोग अनावश्यक ब्लोट अपलोड करने से बचने के लिए। मुझे लगता है कि शामिल करने के लिए एक विशेष रूप से अच्छा है .git :

"functions": {
    "ignore": ["node_modules", ".git", ".gitignore", ".nyc_output", ".runtimeconfig.json", "firebase-debug.log", "tslint.json", "tests"]
  }

इससे वास्तव में कुछ परिणाम मिले। अभी लगभग 65-70% समय चल रहा है। धन्यवाद!

दिलचस्प - डिफ़ॉल्ट रूप से functions उपनिर्देशिका प्रोजेक्ट रूट के नीचे है इसलिए इसमें .git फ़ोल्डर नहीं होगा। जिन लोगों के लिए इससे मदद मिली - आपकी निर्देशिका संरचना कैसी दिखती है?

@mbleeigh सच। मेरा सबसे अच्छा अनुमान यह है कि यह इसके बारे में स्मार्ट है, और इन्हें फ़ंक्शन निर्देशिका पर लागू करता है।

@mbleeigh मेरे पास केवल एक फ़ंक्शन-रिपॉजिटरी है, इसलिए फ़ंक्शन निर्देशिका रखने के लिए यह थोड़ा मूर्खतापूर्ण लग रहा था। सब कुछ जड़ में खिसक गया।

यह मेरे firebase.json से एक उद्धरण है:

  "functions": {
    "ignore": [
      "__mocks__",
      ".cache",
      ".commitlintrc.yaml",
      ".dependabot",
      ".editorconfig",
      ".eslintrc.yaml",
      ".firebase",
      ".firebaserc",
      ".git",
      ".gitattributes",
      ".github",
      ".gitignore",
      ".lintstagedrc.js",
      ".nvmrc",
      ".prettierignore",
      ".prettierrc.yaml",
      ".vscode",
      "CHANGELOG.md",
      "cloudbuild.yaml",
      "codecov.yml",
      "CONTRIBUTING.md",
      "coverage",
      "cSpell.json",
      "decisions",
      "firebase.json",
      "firestore.indexes.json",
      "jest.config.js",
      "node_modules",
      "README.md",
      "rfcs",
      "scripts",
      "src",
      "test",
      "tsconfig.json",
      "tsconfig.production.json"
    ],
    "source": "."
  },

मैं खुशी से इसे इसके साथ बदल दूंगा:
```
{
"शामिल करें": ["lib", "package.json", "package-lock.json"]
}

एफडब्ल्यूआईडब्ल्यू मेरा मानना ​​​​है कि ये ग्लोब स्वीकार करते हैं ताकि आप ऐसा करने में सक्षम हों:

{
  "exclude": ["!{lib,package.json,package-lock.json}"]
}

अभी-अभी क्लाउड फ़ंक्शन शुरू किया है, और परिनियोजन का समय दर्दनाक है।

दर्दनाक तैनाती समय :(

हमारे फायरबेस ऐप में अभी 60 क्लाउड फंक्शन चल रहे हैं। पहले तो हमें कोटा के कारण बहुत सारी तैनाती विफलताएं होने लगीं, इसलिए हमने इसे डॉक्स के सुझाव के अनुसार बैचों में तोड़ दिया। यह अब लगातार तैनात है, लेकिन प्रत्येक बैच को डिफ़ॉल्ट रनर पर गिटहब क्रियाओं सीआई के हिस्से के रूप में तैनात करने में ~ 3 मिनट लगते हैं। बैच लगभग 6 प्रत्येक हैं, इसलिए कुल 10 बैच हमारे फ़ंक्शन परिनियोजन समय को लगभग 30 मिनट बनाते हैं।

फ़ंक्शन स्वयं न्यूनतम निर्भरता वाले कोड के बहुत छोटे बिट हैं। सुनिश्चित नहीं है कि पाइपलाइन को गति देने के लिए हम और क्या कर सकते हैं।

यह सुनकर वाकई दुख हुआ। एक अन्य दृष्टिकोण एक ही फ़ंक्शन में एकाधिक प्रवेश बिंदुओं/मार्गों को बंडल करना है। यह स्पष्ट रूप से चिंताओं/आकार/सुरक्षा को अलग करने से सबसे अच्छा नहीं है, लेकिन हमने अपने सभी एपीआई एंडपॉइंट्स (एकल एंट्रीपॉइंट जो तब आंतरिक राउटर का उपयोग करता है) के साथ किया है, और तब से कई कोटा सीमाओं का अनुभव नहीं किया है (लेकिन वे कभी-कभी होते हैं)।

फिर भी, यह कोटा सीमा वास्तव में कम लगती है, क्योंकि आधिकारिक दस्तावेज़ "क्लाउड फ़ंक्शंस एपीआई के माध्यम से कार्यों को तैनात करने या हटाने के लिए कॉल" के लिए "80 प्रति 100 सेकंड" सूचीबद्ध करता है। मैं मान रहा हूँ कि Google समर्थन इस सीमा को और आगे नहीं बढ़ा सकता?

फिर भी, यह कोटा सीमा वास्तव में कम लगती है, क्योंकि आधिकारिक दस्तावेज़ "क्लाउड फ़ंक्शंस एपीआई के माध्यम से कार्यों को तैनात करने या हटाने के लिए कॉल" के लिए "80 प्रति 100 सेकंड" सूचीबद्ध करता है। मैं मान रहा हूँ कि Google समर्थन इस सीमा को और आगे नहीं बढ़ा सकता?

@dinvlad मैं एपीआई सीमा में वृद्धि के बारे में बिक्री और समर्थन दोनों के बारे में पूछताछ कर रहा था, यह जीसीपी कंसोल कोटा अनुभाग में स्पष्ट रूप से अक्षम/धूसर हो गया है। अंततः हैंगआउट पर एक Google इंजीनियर प्राप्त करने में सक्षम था जिसने मुझे सूचित किया "वह कोटा नहीं बदलता है" ... तो मुझे नहीं लगता।

हमने अगली रिलीज़ में मानक उपेक्षा सूची में .git जोड़ा है:
https://github.com/firebase/firebase-tools/pull/2395

इससे कुछ के लिए रिलीज में तेजी आनी चाहिए। बेशक हम (Firebase CLI टीम) क्लाउड फ़ंक्शंस बैकएंड पर विलंबता के बारे में बहुत कुछ नहीं कर सकते हैं।

जब आप फ़ंक्शन अपडेट नहीं कर रहे हों तो firebase deploy --only hosting करना सुनिश्चित करें

यहाँ पर हम एक फ़ंक्शन में संबंधित कार्यक्षमता को भी समूहित कर रहे हैं, इसलिए यह "कार्यक्षमता के प्रति व्यक्तिगत ग्रेन्युल एक फ़ंक्शन" के बजाय "एक फ़ंक्शन प्रति फ़ीचर क्षेत्र" जैसा दिखता है।

परिनियोजन की प्रदर्शन विशेषताएँ एक फ़ंक्शन में जाने वाली वास्तुकला को दृढ़ता से चला रही हैं!

यह मुद्दा कब और क्यों बंद हुआ। यह नवंबर 2017 में खोला गया था और ऐसा लगता है कि यह अभी भी उतनी ही समस्या है जितनी तब थी। मुझे यहां 'बंद' का संदर्भ नहीं दिख रहा है और मुझे यह जानने में दिलचस्पी होगी कि इसे क्यों बंद किया गया था।

मैं शिकायत नहीं कर रहा हूं, बस सोच रहा हूं। मुझे यकीन है कि इस पर काम किया जा रहा है लेकिन किसी भी प्रगति के बारे में जानना अच्छा होगा।

@chriscurnow इसे बंद कर दिया गया था क्योंकि वास्तविक कारण स्पष्ट रूप से (बंद-स्रोत) सर्वर पक्ष के कारण है, सीएलआई उपकरण नहीं, भले ही यह उपयोगकर्ताओं को सीएलआई मुद्दे के रूप में प्रकट करता है (प्रति @samtstern https://github.com में) /firebase/firebase-tools/issues/536#issuecomment-572830647)।

दुर्भाग्य से बैक एंड के लिए कोई अच्छा सार्वजनिक ट्रैकर नहीं है इसलिए हमें यहां अपडेट मिलते हैं :(

Google के बैकएंड में इसे ठीक करने के लिए हम इस बग को कैसे खोल सकते हैं?
यह हास्यास्पद रूप से धीमा है

जैसे, फायरबेस फ़ंक्शंस का उपयोग करने का क्या मतलब है अगर इसमें इतना समय लगने वाला है

अरे दोस्तों, हो सकता है कि हम सभी इस मुद्दे की रिपोर्ट Google को कर सकें और शायद वे सुनेंगे?
https://firebase.google.com/support/troubleshooter/contact

हर बार जब मैं किसी महत्वपूर्ण चीज़ के लिए Google से कुछ उपयोग करने का प्रयास करता हूं तो मुझे याद दिलाया जाता है कि वे अस्तित्व में कम से कम उपभोक्ता अनुकूल कंपनियों में से एक हैं, लेकिन हे, हम कोशिश कर सकते हैं।

@RenFontes मैंने अभी केस 00075974 दायर किया है: फायरबेस कार्यों को तैनात करना इतना धीमा है कि फायरबेस समर्थन के साथ अनुपयोगी होना चाहिए । मैं इस संदेश को उनके साथ वापस आने के साथ अपडेट करूंगा।

विशिष्ट कार्यों को तैनात करना संभव है। क्या सीएलआई के पास प्रत्येक फ़ंक्शन के लिए "चेकसम ट्रैकर" नहीं हो सकता है और केवल बदले हुए लोगों को तैनात कर सकता है (और साथ ही, जो कुछ भी उपयोग करता है उसे ट्रैक करें: vars, package, ...)?

@ श्रीब्रह्म निश्चित रूप से, लेकिन समस्या अभी भी मौजूद है, भले ही आप केवल एक ही फ़ंक्शन को तैनात करते हैं (उदाहरण के लिए, एकल फ़ंक्शन परिनियोजन टाइमआउट के कारण अभी भी विफल हो सकता है)।

बैचिंग फ़ंक्शन परिनियोजन को प्रबंधित करने के लिए इसे उपयोगकर्ता पर नहीं पड़ना चाहिए, और कई मामलों में फ़ंक्शन अपडेट परमाणु रूप से आवश्यक हैं, इसलिए विभाजित/बैच नहीं किया जा सकता है।

वर्कअराउंड के सुझावों की सराहना करें, लेकिन वास्तव में हमें यहां Google की ओर से एक SLA और उनका पालन करने की आवश्यकता है।

यह सच है कि फायरबेस कभी-कभी काम करता है? (शायद अक्सर) प्रदर्शन पर बेकार है..यह वास्तव में धीमा है .. आपको जंग का समर्थन करना चाहिए .. जाओ? क्या यह नोड से बहुत तेज है?

अभी भी Google की प्रतीक्षा कर रहा है कि वह समय परिनियोजित करने के लिए Google फ़ंक्शंस में सुधार करे?
पीडब्ल्यूए से एसएसआर में जाने से मुझे हर तैनाती के लिए 7 मिनट और इंतजार करने के लिए मजबूर होना पड़ा