Firebase-tools: نشر الوظائف بطيء للغاية

شكرا للتسجيل! نحن نعلم أن النشر البطيء هو نقطة ضعف رئيسية لتجربة الوظائف ، وهو شيء نعمل على حله من خلال استراتيجيات مختلفة.

تضمين التغريدة
بصفتي مبتدئًا في Firebase للوهلة الأولى ، اعتقدت أنني كنت أفسد شيئًا ما ، لأن النشر توقف دائمًا عند _functions: تحضير دليل الوظائف للتحميل ... _ part.
سيكون تقديم بعض المعلومات الإضافية (مثل: يستغرق إكمالها من 3 إلى 5 دقائق) أمرًا رائعًا حقًا ، حتى يتم حل المشكلة.

بصفتي مبتدئًا ، قضيت عدة مرات في إلغاء هذا التفكير في أنني كنت أفعل شيئًا خاطئًا.

المشكلة واضحة نوعًا ما. أنشأ الأمر init مجلد "وحدات عقدة" ضخم. يوجد على جهازي: 22903 ملفًا ، و 2782 مجلدًا. ينسخ الرمز كل ذلك إلى مجلد مؤقت.

هذا ما فعلته:

1. باستخدام بيانات طباعة السجل ، حددت السطر البطيء من التعليمات البرمجية. إنه هنا:
   https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L26

السطر 26 في PreparFunctionsUpload.js:
fs.copySync (options.config.path (options.config.get ('function.source')) ، tmpdir.name) ؛

1. لقد قمت بطباعة معلمات استدعاء نسخ الملف هذا. على جهازي:
   C: \ Users \ thoma \ StudioProjects \ LSystemAndroid \ firestorefunctions
   -> C: \ Users \ thoma \ AppData \ Local \ Temp \ fbfn_752624vejX0cv3GEJI

تم إنشاء مجلد الوظائف بواسطة الأمر init. تبدو هكذا:

• node_modules (حجم هائل)
• .gitignore
• index.js
• package.json
• pacakge-lock.json

يبدو لي أنه لا ينبغي أن ينشئ الأمر init الأمر CLI هذا المجلد node_modules. حجمها 165 ميغا بايت. يبدو أنه من غير المعقول إضافة إلى كل مشروع.

تضمين التغريدة

هذه ليست القضية في الواقع. لا يتم نسخ node_modules إلى المجلد المؤقت ، كما ترى من هذا السطر هنا: https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L76

من الضروري أن يقوم firebase init بتثبيت جميع الوحدات النمطية للعقدة محليًا داخل مجلد مصدر الوظائف ، وإلا فلن تعمل خدمة الوظائف محليًا ، ولن يعمل استخراج المشغل (هذه هي الطريقة التي يفهم CLI الأحداث التي تؤدي إلى تشغيل كل منها تعمل حتى تتمكن من نشرها بشكل صحيح).

أضع سطر طباعة التصحيح قبل السطر 26 وبعده. استغرق هذا الخط دقائق.

بعد ذلك ، أضفت مرشحًا لطباعة الملفات التي يتم نسخها. تضمنت جميع ملفات node_modules.

بعد ذلك ، قمت بتغيير عامل التصفية لاستبعاد ملفات node_module. تقدم النشر بسرعة الآن. ولكن بعد ذلك بقليل ، بدا أن البرنامج النصي كان يحاول تقييم صحة وظائف السحابة. فشل هذا الرمز لأنه كان يفتقد تبعيات المكتبة.

يبدو أن سطر التعليمات البرمجية المصدر الذي تشير إليه خطوة لاحقة. يبدو أنه تم أرشفة الملفات (باستثناء node_modules) في ملف مضغوط قبل تحميلها على السحابة. لا يبدو أن هذا الخط يعمل ببطء على جهازي.

نعم أنت على حق ، لقد كنت مخطئًا ، لا يتم نسخ node_modules. أعتقد أنها فكرة صحيحة عدم نسخ أكثر من node_modules إلى دليل temp. ما يعقد هذا الأمر قليلاً هو حقيقة أن CLI يكتب ".runtimeconfig.json" إلى المجلد المؤقت قبل بدء التحليل ، ويتم تحميل هذا الملف مع بقية التعليمات البرمجية المصدر للوظائف ، ولم نرغب في الكتابة هذا الملف في دليل التعليمات البرمجية المصدر الفعلي. لذلك من المحتمل أن يكون هناك حل جيد يعمل على تحسين سرعة النشر ويضمن عدم وجود آثار جانبية غير مقصودة ، ولكن يجب أن أتلاعب قليلاً. يمكنك أيضًا أن لا تتردد في تقديم طلب سحب.

لدي نفس المشكلة. قد يكون من الجيد طباعة المزيد من الرسائل أثناء خطوات "تحضير الدليل ..." حتى لا يعتقد المستخدم أن أدوات Firebase معلقة.

تحرير: كان هذا على Ubuntu WSL. في لينكس ، مرحلة "التحضير" لا تتوقف. يمكن أن تكون خطوة "إنشاء الوظيفة" بطيئة ، ولكن ليس بالقدر الذي جربته سابقًا.

هذه القضية هي ألم حقيقي في بوم. أعتقد أنه يجب إعطاؤها أولوية عالية: /

أحاول تنفيذ وظائف Firebase لمشروعي ولأن هذا الخطأ اضطررت إلى تأجيله.
هذا الخطأ جعلني أضيع الكثير من الوقت.
آمل أن يتم إصلاحه قريبًا!

هذه القضية هي عائق كبير. في الغالب لأنني أستخدم firestore وفي تلك الأشياء مثل المجاميع والعدادات والتواجد لا يمكن التعامل معها إلا بشكل لائق من خلال وظائف السحابة وتتوقف لمدة 5 دقائق في كل مرة.

PulpoEnPatineta هذا ليس خطأ. هذه مجرد مشكلة تتعلق بوقت النشر.

McStuffins إذا استغرق تشغيل سيارتك خمس دقائق ، فهل هو خطأ أم مجرد مشكلة في وقت البدء؟

هل هناك إصلاح لهذه؟ انها حقا بطيئة للغاية.

لقد تابعت هذه المشكلة من البداية ، لكنها لم تكن مشكلة بالنسبة لي لأن لدي قرص مضغوط وهو يقوم بكل العمل من أجلي. أنا أيضًا لا أنشر وظائف لمجرد اختبار ما إذا كانت تعمل. لذلك في الأساس لم يكن الأمر مهمًا بالنسبة لي.

حتى اليوم ، عندما واجهت قيودًا غير متوقعة: لا يمكنني نشر وظائفي بعد الآن ، لأن النشر للإنتاج يتجاوز الحصة اليومية (12000 ثانية). لديّ 55 وظيفة تقريبًا مع مشغلات مختلفة (pubsub ، firestore ، https). هل هو كثير جدا للتعامل معها؟

الآن عليّ نشر طلبي لمدة يومين : rofl:: lollipop:: +1:: 1st_place_medal:: coffin:: tada:: taco:: cactus:: dancer:: smiling_imp:

في بعض الأحيان ، عندما أقوم بالنشر ، يكون الأمر بطيئًا للغاية ، ثم يظهر تحذير في الجهاز يقول "خطأ في بيئة الإنشاء"

srinurp يرجى الاطلاع على طلب السحب الذي ربطته أعلاه ، وسوف يعالج جزءًا من المشكلة. ويعمل فريق الخلفية على معالجة أجزاء أخرى من المشكلة (لكنها مهمة معقدة للغاية ، لذلك نقدر سعة صدرك.)

merlinnot ما لم تكن تقوم بتحديث التعليمات البرمجية لجميع وظائفك مع كل عملية نشر ، فإنني أوصي باستخدام الأمر - only لنشر الوظائف الفردية أو مجموعات الوظائف. راجع https://firebase.google.com/docs/cli/#partial_deploys.

عادةً ما يشير McStuffins "خطأ في بيئة الإنشاء" إلى وجود مشكلة في الإنتاج ، وفي هذه الحالة ، يرجى تقديم بطاقة دعم على https://firebase.google.com/support/ ، ويمكنك معرفة ما إذا كانت هناك أية مشكلات جارية في الإنتاج من خلال زيارة لوحة بيانات حالة Firebase

laurenzlong سأضطر إلى تكوين CI الخاص بي لاكتشاف التغييرات تلقائيًا في كل وظيفة بين عمليات النشر (بما في ذلك حل التبعيات). وماذا لو قمت بتحديث حزم مثل firebase-functions ، firebase-admin ، lodash إلخ ، والتي أستخدمها في كل وظيفة؟

merlinnot هذه حالة استخدام مشروعة للغاية. تتحكم وظائف Google Cloud في حصص النشر ، أوصي بتقديم طلب بشأن أداة تعقب المشكلات العامة الخاصة بهم: https://cloud.google.com/functions/docs/support

لكل المهتمين: https://issuetracker.google.com/issues/71385193

laurenzlong هل يمكن تجاهل المجلد node_modules عند نسخ المصدر ثم عمل npm install --production أو yarn install --production ؟ حيث أن هذه الأدوات قد تكون أسرع من مجرد نسخ ولصق.

تضمين التغريدة
قد يكون هذا تغيير جذري. قد لا يزال بعض الأشخاص (بمن فيهم أنا) يشيرون إلى الحزم من خلال مسار نسبي (مثل "اسم الحزمة": "./externs/package.tgz") ، غالبًا سبب المشكلة (التي تم إصلاحها الآن ) مع المستودعات الخاصة. يجب أن تأخذ الأداة كل حالات الزاوية هذه في الاعتبار.

الشيء الآخر هو التخزين المؤقت: إذا كان على Google تنزيل الحزم نيابة عنك ، فسيتعين عليهم تنفيذ بعض آليات التخزين المؤقت الداخلية. لدينا جميعًا ذاكرات تخزين مؤقت محلية على أجهزة الكمبيوتر الخاصة بنا (كل من npm و yarn لهما آليات تخزين مؤقت) ، لذلك نحن لا نقتل خوادم npm ؛)

قد يرغب بعض الأشخاص أيضًا في اختبار بعض التغييرات في المكتبات الخارجية. من الأسهل بكثير فقط تغيير ملف ونشر الوظيفة بدلاً من إنشاء مفترق ، وإجراء تغييرات ، وتغيير مرجع للحزمة مؤقتًا ، ...

خلاصة القول: إنه يعمل بشكل جيد ، اتركه كما هو الآن: +1:

horacehyleemerlinnot شكرًا على 2 سنت. يرجى مراجعة https://github.com/firebase/firebase-tools/pull/578 ، لن يقوم الإصدار التالي من CLI بنسخ فترة مجلد مصدر الوظائف.

لست متأكدًا حقًا مما يمكن أن يفعله Firebase والذي يستغرق دقائق لنشر وظيفة 5 خطوط ، 1 كيلو بايت ، على آلة أساسية بستة 4 جيجاهرتز ، على اتصال ليفي بسرعة 1 جيجابت في الثانية.

أعلم أن الأمر يبدو وكأنني أتناول البول ، لكنني أشعر بالفضول حقًا بشأن ما يحدث أثناء "إعداد الدليل للتحميل". أي شخص يعرف فعلا؟

نسخ دليل دوالك ، بما في ذلك وحدات العقدة ، إلى tmp dir.

سيتناول إصدارنا التالي هذا الأمر ولن نحتاج إلى نسخه من قبل
الانتشار.

في الأحد ، 7 يناير 2018 ، الساعة 5:05 مساءً ، كتب hmexx [email protected] :

لست متأكدًا حقًا مما يمكن أن تفعله Firebase يستغرق بضع دقائق
انشر وظيفة 5 خطوط ، 1 كيلو بايت ، على آلة أساسية بستة 4 جيجاهرتز ، جالسًا على ملف
اتصال الألياف 1 جيجابت في الثانية.

أعلم أن الأمر يبدو وكأنني أتناول البول ، لكنني أشعر بالفضول حقًا
يجري أثناء "إعداد الدليل للتحميل". أي شخص يعرف فعلا؟

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/536#issuecomment-355868154 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAAD_nUptJWFuYGvEXI0MwmQR-bG9_MKks5tIWm1gaJpZM4QdF3g
.

تضمين التغريدة

اه صحيح. أن يفسر ذلك. إنه نوع من الكوميديا ​​أن ترى محطة عمل تصبح مجنونة لمدة دقيقة أو دقيقتين ، فقط لطباعة السطر التالي "وظائف مجمعة ( 37.55 كيلو بايت !!!) بنجاح لتحميل" لول

نتطلع إلى الإصدار القادم. تشك للرد.

ح.

اليوم 19. لا يزال Firebase قيد النشر. * يمسك الفشار *

نعم.

ما هو موعد الإصدار التالي ، وما هي النسبة المئوية للتحسين في أوقات النشر التي يجب أن نتوقعها؟

فقط لمعرفة ما إذا كنت ستستمر في السير في هذا الطريق.

من المفترض أن يتم الإطلاق هذا الأسبوع ، ويمكنك أن تتوقع "جارٍ التحضير
دليل الوظائف للنشر "خطوة للذهاب بشكل أسرع (لا أفعل
لديك أرقام دقيقة). الأجزاء الأخرى من الانتشار ستبقى دون تغيير.

في يوم الإثنين 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
.

صدر هذا!

mbleigh هل هذا في الإصدار 3.17.4؟

jkossis v3.17.0

من ملاحظات الإصدار:

إذا كنت تنشر وظائف ، فيجب عليك تحديث حزمة تطوير البرامج (SDK) الخاصة بوظائف Firebase إلى الأحدث عن طريق تشغيل "npm i --save firebase -function @ latest " داخل دليل الوظائف. هذا يتيح نشر الوظائف بشكل أسرع.

من دقائق إلى ثوان: عمل جيد!

بالنسبة لي لا يزال هذا يستغرق دقائق.

لدي [email protected] و [email protected] . ما الذي يمكنني فعله للمساعدة في تصحيح هذه المشكلة بشكل أكبر؟

هنا هو الناتج الموقوت من نشر الوظائف فقط. لقد قمت بتغيير الأسماء ولكنها عبارة عن مزيج من نقاط نهاية REST وقاعدة البيانات ومشغلات المصادقة.

➜  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 نجح الأمر أخيرًا. مجد إلى https://stackoverflow.com/questions/48531993/firebase-config-variables-are-not-available-error-with-deploying-functions#comment84098334_48531993

مرحبًا ، لدي مشكلة في نفس النقطة ("تحضير دليل الوظائف ..")
ولكن في حالتي ، استغرق الأمر أكثر من 25/30 دقيقة حتى يكتمل
لدي 4 تبعيات خاصة تزن حوالي 2.20 ميغابايت
لقد وجدت أن هذه كانت الطريقة الوحيدة لتضمين التبعيات الخاصة ، كملفات مضغوطة.
أفعل شيئا خاطئا؟ أم أن هذه هي الطريقة التي من المفترض أن تعمل؟

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؟

نعم أعتقد ذلك. تقارير firebase —version 3.18.6.

أنت تستخدم إصدارًا أحدث مني. لست متأكدًا مما إذا كانوا قد استمروا في نقل مجلد node_modules مرة أخرى في 3.18.6 ، ولكن في الوقت الحالي مع 3.18.4 ، يبدو أن كل شيء يعمل بشكل جيد ...

لم يكن هناك تراجع في إستراتيجية النشر في إصدارات أدوات Firebase الحديثة (لم يتم نسخ مجلد node_modules) ، ومع ذلك فإن وقت النشر يختلف أيضًا من آلة إلى أخرى ومن وقت لآخر. يعد النشر الأولي لوظيفة أبطأ أيضًا من التحديثات اللاحقة.

أرى أوقات نشر أثناء الخطوة preparing functions directory for uploading... تستغرق ما يقرب من 7 دقائق في هذه الخطوة وحدها عند التشغيل محليًا. تستغرق خطوة النشر المسبق للبناء حوالي 5 ثوانٍ محليًا. جميع الخطوات الأخرى في عملية النشر يتم تشغيلها من التصحيح بسرعة كبيرة جدًا. أحصل على أن هذا النشر يمكن أن يكون بطيئًا إلى حد ما ، لكنني أيضًا أستخدم AWS lambda للعمل ، كما أن عمليات نشر lambda الكبيرة جدًا أسرع بكثير من ذلك ، في حدود دقيقتين و 3 دقائق ، بما في ذلك تثبيت حزم Python وبنائها.

حتى النشر من google cloud build يستغرق الأمر من 2 إلى 3 دقائق ، مقابل 10 إلى 20 ثانية في aws lambda. أريد فقط أن أسأل هل يقوم cli بضغط مجلد الوظيفة بالكامل قبل التحميل؟

laurenzlong ، هل يمكنك توضيح ما إذا تم بالفعل نشر الوظائف بالتوازي ، أو إذا كان هذا التحسين قيد التنفيذ؟

تم دائمًا نشر الوظائف بالتوازي. ومع ذلك ، يرجى ملاحظة أن نشر 10 وظائف على التوازي لا يزال أبطأ من نشر وظيفة واحدة.

+1 أن نشر الوظيفة يكون بطيئًا للغاية. لقد اتبعت البرنامج التعليمي الخاص بوظيفة cron لإنشاء وظيفة التجزئة بالساعة ، وهي أول نغمة لي ، ويستغرق الأمر دقيقة واحدة لنشرها في كل مرة.

laurenzlong نشكرك كثيرًا على الرد وشكراً لعملك الجاد على Firebase!

هل هناك أي خطط نشطة لتحسين وقت النشر؟ أسأل لأنه على الرغم من أننا نحب Firebase ، إلا أننا نفكر بالفعل في الابتعاد عنه بسبب أوقات النشر البطيئة. لدينا حوالي 47 وظيفة سحابية وتستغرق عمليات النشر من 3 إلى 6 دقائق بشكل منتظم. قارن ذلك بـ git push heroku master والذي سيستغرق حوالي 20-30 ثانية لنشر نفس الحجم من التعليمات البرمجية إلى Heroku. وسيتم تشغيل هذا الرمز على الفور على Heroku. مع Firebase ، يتعين علينا الانتظار 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

من الصعب أيضًا إجراء عمليات النشر الذرية باستخدام Firebase لأنه بعد النشر ، هناك فترة زمنية يتم خلالها تشغيل بعض الوظائف الجديدة ، يطلق عليها v_n+1 جنبًا إلى جنب مع بعض الوظائف القديمة v_n . لذلك إذا أجريت تحديثًا رئيسيًا ، فلديك مزيج من الوظائف الجديدة والقديمة التي يمكن تشغيلها باستخدام تنسيقات بيانات أو خوارزميات مختلفة. هذا أقل أمانًا بكثير من نشر Heroku حيث يتم نشر جميع الوظائف الجديدة وتشغيل الوظائف الجديدة فقط أو عدم نشرها.

علاوة على ذلك ، في بعض الأحيان يفشل نشر عدد قليل من وظائفنا البالغ عددها 47 مع وجود أخطاء مثل

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

نحن ننتشر على إنترنت جيجابت متماثل موثوق للغاية ، لذا فإن المشكلة ليست شبكتنا.

لذا فكر في نشر Heroku كمعاملة قاعدة بيانات ذرية (كل شيء أو لا شيء) بينما عمليات نشر Firebase تشبه في النهاية حالات فشل جزئية ... وهذا يجعل عمليات dev أكثر صعوبة ، خاصة إذا كنت تدفع بإصلاح الأخطاء في منتصف الليل ردا على صفحة.

بصراحة ، فإن تجربة النشر على Firebase أبطأ بشكل موضوعي وأقل موثوقية من Heroku أو AWS ... لا تفهموني بشكل خاطئ ، فنحن نحب Firebase ونقدر حقًا كل عملك الشاق. لا أقصد أن يبدو هذا وكأنه هجوم ، فهو ليس شيئًا شخصيًا ، لكننا نحتاج إلى Firebase لأداء أفضل هنا أو نفكر في الذهاب إلى مكان آخر لأن عمليات النشر مؤلمة للغاية.

نشكرك مرة أخرى على عملك الشاق في Firebase. نحن نقدر مساعدتك :-).

شكرا لتقاسم البيانات الخاصة بك! لدينا بعض الخطط لتحسين هذا خاصة لنشر العديد من الوظائف في نفس الوقت (بشكل أساسي تحسين خطوة البناء من جانب الخادم بعد إجراء استدعاء API لإنشاء / تحديث الوظيفة). ومع ذلك ، فهذه تغييرات في البنية التحتية ستستغرق أرباعًا ، لذلك نقدر حقًا صبرك في هذه الأثناء.

ربما تكون قد فكرت في ذلك بالفعل ، ولكن يمكنك إنشاء برنامج نصي في خط أنابيب CI / CD الخاص بك يكتشف الوظائف التي تم تحريرها ، ونشر تلك الوظائف بعلامة --only فقط. سيؤدي ذلك إلى تحسين سرعة النشر بشكل كبير. شاهد هذا الفيديو للحصول على مثال: https://www.youtube.com/watch؟v=iyGHW4UQ_Ts

@ laurenzlong شكرا على المعلومات ، لورين. ومع ذلك ، لدي وظيفة سحابية صغيرة واحدة فقط ولا يزال الأمر يستغرق حوالي دقيقة واحدة للنشر حتى بعد إجراء أصغر تغيير. أنا أستخدم هذا العلم أيضًا على الرغم من أن لدي وظيفة سحابية واحدة فقط. يبدو أن هناك خطأ ما يحدث هنا.

ما زلت أستغرق دقائق حرفيًا اعتبارًا من أبريل 2019 - إصدار Firebase 6.6.0 - كل ما أفعله هو اتباع البرنامج التعليمي هنا: https://firebase.google.com/docs/functions/get-started

تم التنزيل للتو واستغرق بضع دقائق في كل مرة أقوم فيها "بنشر Firebase"

في الأيام القليلة الماضية ، يستغرق نشر الاستضافة حتى عدة دقائق ، عندما استغرق الأمر من 10 إلى 15 ثانية قبل أسبوعين. تنتهي مهلة نشر الوظائف أيضًا.

وتظهر صفحة حالة Firebase باللون الأخضر 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 من تطبيق flutter بالإضافة إلى البيانات في متجر firestore ، ويبدو أنه (في الوقت الحالي على أي حال) أعاد توجيه كل شيء في الإصدارات التجريبية للتطبيق إلى محطة عمل التطوير الخاصة بي هو جهد أكثر من انتظار عمليات النشر.

أعتقد أنه يمكنني استخدام الوقت الذي أنتظر فيه البحث في هذا 🤨.

عام جديد سعيد لهذه المشكلة التي لا تزال مغلقة ولم يتم إصلاحها بعد! 🎉

ربما يمكن للمسؤول أو OP إعادة تسمية هذه المشكلة إلى "إعداد دليل الوظائف للنشر بطيء للغاية" حيث يبدو أنه قد تم إغلاقه بناءً على إصلاح تلك المرحلة من عملية النشر الشاملة فقط.

يمكننا بعد ذلك فتح مشكلة جديدة "نشر الوظائف بطيء للغاية" لأن ... نشر الوظائف لا يزال بطيئًا للغاية 😄

تم إغلاق هذه المشكلة لأنه لا يوجد شيء آخر يمكننا القيام به من جانب CLI لتحسين أوقات النشر. بالنسبة للتنمية المحلية ، نواصل الاستثمار في المحاكي ، ونأمل أن يضطر الأشخاص إلى تشغيل firebase deploy فقط عند نشرهم للحث وليس كجزء من دورة حياة التطوير الخاصة بهم.

التغييرات الخلفية لا تزال جارية. كما يمكنك أن تقول ، كانت هناك تأخيرات غير متوقعة.

شكرًا للتوضيح samtstern ، لذا أعتقد أن المشكلات / الطلبات ضد أدوات Firebase / firebase-tools تنطبق فقط على CLI؟ سوف نبحث عن ريبو / مشروع يغطي الواجهة الخلفية.

فيما يتعلق بالتنمية المحلية - من الجانب العام للأشياء ، يبدو أن Google تشجع حقًا تكامل Firebase و Flutter اللذين يبدو أنهما يعملان جيدًا معًا ، ولكن من الناحية العملية ، نواجه تناقضات في وقت التطوير مثل هذا. لقد ألقيت نظرة سريعة على المحاكي كما هو مقترح عند اكتشاف هذه المشكلة ، ولكن لا يبدو أنه يدعم سير عمل تطوير Firebase plus Flutter على الإطلاق ، وبالتأكيد ليس بسلاسة كما يفعل عبر الواجهة الخلفية السحابية. لم أعود بدائرة إلى الوراء لمعرفة ما إذا كان هذا قد تحسن مؤخرًا ، ولكن يبدو أنه غير مرجح.

repentsinner نعم هذا الريبو يتتبع عمل CLI فقط. بالطبع نحاول الإجابة على أي شيء يأتي ولكن غالبًا ما يتعين علينا إغلاق المشكلات عندما لا يكون هناك شيء مفيد يمكننا القيام به هنا. خلفياتنا الخلفية ليست مفتوحة المصدر وهذا هو السبب في أننا نوجه الأشخاص عمومًا إلى دعم Firebase لتقديم تقارير الأخطاء أو طلبات الميزات حول عناصر Firebase العامة.

بالنسبة إلى Flutter ، نحن نحبها (انظر: https://github.com/FirebaseExtended/flutterfire) ولكن من المهم ملاحظة أنها ليست منصة Firebase رسمية مما يعني أنه لا يمكننا تقديم دعمنا الكامل لمشكلات مثل ما نفعله على Android / iOS / Web الأصلي. ربما سيتغير ذلك يومًا ما ولكن هذا هو الوضع الآن.

إذا كانت لديك أسئلة حول كيفية توصيل تطبيق Flutter بـ Firebase Emulators ، فافتح مشكلة في FlutterFire repo و cc me ، ثم يمكنني إشراك الأشخاص المناسبين من Flutter أيضًا.

حسنًا ، شكرًا على التوضيحsamtstern! لقد انتقلت إلى مشاريع أخرى في الوقت الحالي ، لكنني سأبحث في FlutterFire repo عندما أعود إلى هذه الأشياء.

لا يدعم المحاكي سياق المصادقة ، لذا فهو IMO عديم الفائدة تمامًا بنسبة 100٪.

انتهى بي الأمر باكتشاف تجميد عمليات النشر الخاصة بي لأنني كنت أحاول استخدام dotenv

فقط أزعج رأسي لتذكير الناس أن هذه لا تزال نقطة ألم ✌️

بالنسبة للأشخاص الذين ما زالوا يواجهون هذا - هناك شيء واحد وجدته مفيدًا وهو استخدام functions.ignore لتجنب تحميل سخام غير ضروري. أعتقد أن العنصر الجيد الذي يجب تضمينه هو .git :
{ "functions": { "ignore": ["node_modules", ".git", ".gitignore", ".nyc_output", ".runtimeconfig.json", "firebase-debug.log", "tslint.json", "tests"] }

لقد أسقطت الوظائف تمامًا لأن سير عمل dev أصبح مؤلمًا.

بالنسبة للأشخاص الذين ما زالوا يواجهون هذا - هناك شيء واحد وجدته مفيدًا وهو استخدام functions.ignore لتجنب تحميل سخام غير ضروري. أعتقد أن العنصر الجيد الذي يجب تضمينه هو .git :

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

هذا في الواقع أسفر عن بعض النتائج. تعمل في حوالي 65-70٪ من الوقت الآن. شكرا!

مثير للاهتمام - يكون الدليل الفرعي functions افتراضيًا أسفل جذر المشروع ، لذا لن يكون هناك مجلد .git . الأشخاص الذين ساعدهم هذا - كيف تبدو بنية الدليل الخاصة بك؟

تضمين التغريدة أفضل تخميني هو أنه ذكي في هذا الأمر ، ويتم تطبيقه على دليل الوظائف.

mbleigh لقد حصلت على مستودع للوظائف فقط لذا بدا من السخف أن يكون لدي دليل وظائف. كل شيء تحول إلى الجذر.

هذا مقتطف من بلدي 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": "."
  },

يسعدني استبداله بـ:
""
{
"include": ["lib"، "package.json"، "package-lock.json"]
}

FWIW أعتقد أن هؤلاء يقبلون الكرات الأرضية لذا قد تتمكن من القيام بما يلي:

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

بدأت للتو وظائف السحابة ، ووقت النشر مؤلم.

وقت نشر مؤلم :(

يحتوي تطبيق Firebase الخاص بنا على 60 وظيفة سحابية تعمل فيه الآن. في البداية بدأنا في مواجهة الكثير من حالات فشل النشر بسبب الحصص ، لذا قمنا بعد ذلك بتقسيمها إلى مجموعات كما تقترح المستندات. يتم نشره باستمرار الآن ، ولكن كل دفعة تستغرق حوالي 3 دقائق للنشر كجزء من إجراءات GitHub CI على العدائين الافتراضيين. يبلغ عدد الدُفعات حوالي 6 كل منها ، لذا فإن إجمالي 10 دفعات يجعل وقت نشر وظيفتنا حوالي 30 دقيقة.

الوظائف نفسها عبارة عن أجزاء صغيرة جدًا من التعليمات البرمجية مع الحد الأدنى من التبعيات. لست متأكدًا مما يمكننا فعله لتسريع خط الأنابيب.

من المحزن حقًا سماع ذلك. هناك طريقة أخرى تتمثل في تجميع عدة نقاط دخول / مسارات في وظيفة واحدة. من الواضح أن هذا ليس أفضل ما في فصل المخاوف / الحجم / الأمان ، ولكن هذا ما فعلناه مع جميع نقاط نهاية API الخاصة بنا (نقطة دخول واحدة تستخدم بعد ذلك جهاز توجيه داخلي) ، ولم نواجه العديد من حدود الحصة منذ ذلك الحين (ولكن تحدث من حين لآخر).

ومع ذلك ، يبدو حد الحصة منخفضًا حقًا ، نظرًا لأن المستند الرسمي يسرد "80 لكل 100 ثانية" لـ "المكالمات لنشر الوظائف أو حذفها عبر Cloud Functions API". أفترض أن دعم Google لا يمكنه رفع هذا الحد أكثر من ذلك؟

ومع ذلك ، يبدو حد الحصة منخفضًا حقًا ، نظرًا لأن المستند الرسمي يسرد "80 لكل 100 ثانية" لـ "المكالمات لنشر الوظائف أو حذفها عبر Cloud Functions API". أفترض أن دعم Google لا يمكنه رفع هذا الحد أكثر من ذلك؟

dinvlad كنت أستفسر عن كل من المبيعات والدعم حول زيادة حد واجهة برمجة التطبيقات ، فقد تم تعطيله / تعطيله بشكل واضح في قسم حصص وحدة التحكم في GCP. في النهاية تمكَّن من الحصول على مهندس Google في جلسة Hangout أخبرني "هذه الحصة لا تتغير" .... لذلك لا أعتقد ذلك.

لقد أضفنا .git إلى قائمة التجاهل القياسية في الإصدار التالي:
https://github.com/firebase/firebase-tools/pull/2395

يجب أن يسرع إطلاق سراح بالنسبة للبعض. بالطبع ليس هناك الكثير الذي يمكننا فعله (فريق Firebase CLI) بشأن وقت الاستجابة على الواجهة الخلفية لـ Cloud Functions.

تأكد من تنفيذ firebase deploy --only hosting عندما لا تقوم بتحديث الوظائف

هنا قمنا أيضًا بتجميع الوظائف ذات الصلة في وظيفة ، لذلك ينتهي الأمر بالشكل "وظيفة واحدة لكل منطقة ميزة" بدلاً من "وظيفة واحدة لكل حبيبة فردية من الوظائف".

خصائص الأداء للنشر تقود بقوة بنية ما يدخل في وظيفة واحدة!

متى ولماذا تم إغلاق هذه القضية. تم افتتاحه في نوفمبر 2017 ويبدو أنه لا يزال يمثل مشكلة بقدر ما كان في ذلك الوقت. لا يمكنني رؤية إشارة إلى "مغلق" هنا وسأكون مهتمًا بمعرفة سبب إغلاقه.

أنا لا أشكو ، فقط أتساءل. أنا متأكد من أنه يجري العمل عليه ولكن سيكون من الجيد معرفة أي تقدم.

chriscurnow تم إغلاقه لأن السبب الحقيقي على ما يبدو يرجع إلى جانب الخادم (مغلق المصدر) وليس إلى أدوات CLI ، على الرغم من أنه يظهر للمستخدمين النهائيين كمشكلة CLI (لكل samtstern في https://github.com / firebase / firebase-tools / issues / 536 # issuecomment-572830647).

لسوء الحظ ، لا يوجد متتبع عام جيد للجهة الخلفية ، لذا نحصل على تحديثات هنا :(

كيف يمكننا فتح هذا الخطأ لجوجل لإصلاحه في الخلفية؟
إنه بطيء يبعث على السخرية

مثل ، ما هو الهدف من استخدام وظائف Firebase إذا كان سيستغرق هذا الوقت الطويل

مرحبًا يا شباب ، ربما يمكننا جميعًا إبلاغ Google بهذه المشكلة وربما يستمعون إليها؟
https://firebase.google.com/support/troubleshooter/contact

في كل مرة أحاول فيها استخدام شيء ما من google لشيء مهم ، تذكرت أنها واحدة من أقل الشركات الصديقة للمستهلكين في الوجود ، ولكن مهلا ، يمكننا المحاولة.

RenFontes لقد رفعت للتو القضية 00075974: نشر وظائف Firebase بطيء جدًا بحيث لا يمكن استخدامه مع دعم Firebase. سوف أقوم بتحديث هذه الرسالة بكل ما يأتون به.

من الممكن نشر وظائف محددة. ألا يمكن أن يكون لدى CLI "أداة تعقب المجموع الاختباري" لكل وظيفة وتنشر فقط تلك التي تم تغييرها (وأيضًا ، تتبع كل شيء تستخدمه: vars ، الحزم ، ...)؟

SrBrahma بالتأكيد ، ولكن المشكلة لا تزال موجودة حتى إذا قمت بنشر وظيفة واحدة فقط (على سبيل المثال ، لا يزال من الممكن أن يفشل نشر وظيفة واحدة بسبب انتهاء المهلة).

لا ينبغي أن يقع على عاتق المستخدم لإدارة نشر وظيفة التجميع ، وفي كثير من الحالات تكون تحديثات الوظيفة مطلوبة بشكل جزئي ، وبالتالي لا يمكن تقسيمها / تجميعها.

نقدر الاقتراحات لحل بديل ، ولكن ما نحتاجه حقًا هنا هو اتفاقية مستوى الخدمة من Google والتزامهم بها.

صحيح أن وظائف Firebase أحيانًا؟ (ربما غالبًا) سيئة في الأداء .. إنها بطيئة حقًا .. يجب عليك دعم Rust بدلاً من ذلك .. اذهب؟ هل هو أسرع بكثير من Node؟

هل ما زلت تنتظر Google لتحسين وظائف Google في الوقت المناسب؟
أجبرني الانتقال من PWA إلى SSR على الانتظار 7 دقائق إضافية لكل عملية نشر 😞