Firebase-tools: 기능 배포가 매우 느림

제출해 주셔서 감사합니다! 우리는 느린 배포가 기능 경험의 주요 문제점임을 알고 있으며 다양한 전략을 통해 해결하기 위해 노력하고 있습니다.

@laurenzlong
Firebase를 처음 접하는 사람으로서 언뜻 보기에 내가 뭔가를 엉망으로 만들고 있다고 생각했습니다. 배포가 항상 _functions: prepare functions 디렉토리 for uploading..._ 부분에서 중지되었기 때문입니다.
문제가 해결될 때까지 몇 가지 추가 정보(예: 완료하는 데 3-5분 소요)를 제공하면 정말 좋습니다.

뉴비로서 나는 내가 뭔가를 잘못하고 있다는 생각에 여러 번 취소했습니다.

문제는 분명합니다. init 명령은 거대한 '노드 모듈' 폴더를 생성했습니다. 내 컴퓨터에는 22,903개의 파일, 2,782개의 폴더가 있습니다. 코드는 이 모든 것을 임시 폴더에 복사합니다.

내가 한 일은 다음과 같습니다.

1. 로그 인쇄 문을 사용하여 느린 코드 줄을 식별했습니다. 여기 있습니다:
   https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L26

prepareFunctionsUpload.js의 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
• 패키지.json
• 패키지 잠금.json

CLI 명령 init가 해당 node_modules 폴더를 생성해서는 안 되는 것 같습니다. 165MB의 대용량입니다. 모든 프로젝트에 추가하는 것은 불합리한 것 같습니다.

@thomasfischerm

그것은 실제로 문제가 아닙니다. 다음 줄에서 볼 수 있듯이 node_modules는 임시 폴더로 복사되지 않습니다. https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L76

firebase init 가 모든 노드 모듈을 함수 소스 폴더 내부에 로컬로 설치하는 데 필요합니다. 그렇지 않으면 로컬에서 함수를 제공하지 않고 트리거 추출이 작동하지 않습니다(이것이 CLI가 각 노드를 트리거하는 이벤트를 이해하는 방법입니다. 제대로 배포할 수 있도록 기능).

26행과 그 뒤에 디버그 인쇄 행을 넣었습니다. 그 줄은 몇 분이 걸렸습니다.

그런 다음 복사 중인 파일을 인쇄하는 필터를 추가했습니다. 여기에는 모든 node_modules 파일이 포함되었습니다.

그런 다음 node_module 파일을 제외하도록 필터를 변경했습니다. 이제 배포가 빠르게 진행되었습니다. 그러나 잠시 후 스크립트가 클라우드 기능의 정확성을 평가하려는 것처럼 보였습니다. 해당 코드는 라이브러리 종속성이 없기 때문에 실패했습니다.

당신이 가리키는 소스 코드 라인은 나중 단계인 것 같습니다. 파일(node_modules 제외)이 클라우드에 업로드하기 전에 zip 파일로 아카이브된 것 같습니다. 그 줄이 내 컴퓨터에서 느리게 실행되지 않는 것 같습니다.

네 맞아요. 제가 착각했습니다. node_modules는 복사됩니다. node_modules를 임시 디렉토리로 복사하지 않는 것이 유효한 아이디어라고 생각합니다. 이것을 조금 복잡하게 만드는 것은 구문 분석을 트리거하기 전에 CLI가 임시 폴더에 ".runtimeconfig.json"을 작성하고 이 파일이 나머지 기능 소스 코드와 함께 업로드되고 우리는 작성하고 싶지 않다는 사실입니다. 이 파일을 실제 소스 코드 디렉토리에 넣습니다. 따라서 배포 속도를 개선하고 의도하지 않은 부작용이 없도록 하는 좋은 솔루션이 있을 수 있지만 약간의 문제를 해결해야 합니다. 풀 리퀘스트를 자유롭게 할 수도 있습니다.

같은 문제가 있습니다. 사용자가 firebase-tools가 중단되었다고 생각하지 않도록 "디렉토리 준비 중..." 단계에서 더 많은 메시지를 인쇄하는 것이 좋습니다.

편집: 이것은 Ubuntu WSL에 있었습니다. Linux에서는 "준비" 단계가 중단되지 않습니다. "함수 생성" 단계는 느릴 수 있지만 이전에 경험했던 만큼은 아닙니다.

이 문제는 정말 골치 아픈 문제입니다. 높은 우선순위를 부여해야 한다고 생각합니다./

내 프로젝트에 Firebase 기능을 구현하려고 하는데 이 오류로 인해 연기해야 ​​했습니다.
이 오류로 인해 많은 시간이 낭비되었습니다.
곧 수정되기를 바랍니다!

이 문제는 큰 장애물입니다. 대부분 내가 firestore를 사용하고 집계, 카운터 및 프레즌스와 같은 항목은 클라우드 기능에 의해서만 적절하게 처리될 수 있고 매번 5분 동안 멈춥니다.

@PulpoEnPatineta 오류가 아닙니다. 이것은 단순히 배포 시간과 관련된 문제입니다.

@McStuffins 자동차가 켜지는 데 5분이 걸린다면 오류인가요 아니면 단순히 시작 시간 문제인가요?

이것에 대한 수정 사항이 있습니까? 정말 엄청나게 느립니다.

처음부터 이 문제를 추적했지만 CD를 설정하고 모든 작업을 수행하므로 문제가 된 적이 없습니다. 나는 또한 작동 여부를 테스트하기 위해 함수를 배포하지 않습니다. 그래서 기본적으로 그것은 나에게 중요하지 않았습니다.

오늘까지 예상치 못한 한계에 부딪쳤습니다. 더 이상 기능을 배포할 수 없습니다. 프로덕션 배포가 일일 할당량(12,000초)을 초과했기 때문입니다. 다양한 트리거(pubsub, firestore, https)가 있는 ~55개의 기능이 있습니다. 처리하기에는 너무 많은가요?

이제 이틀 동안 내 애플리케이션을 배포해야 합니다.

가끔 배포할 때 속도가 너무 느리다가 터미널에 "오류 in build environment"라는 경고가 뜨는 경우가 있습니다.

@srinurp 위에 링크된 pull request를 참조하세요. 문제의 일부를 해결할 것입니다. 그리고 백엔드 팀은 문제의 다른 부분을 해결하기 위해 노력하고 있습니다(그러나 이것은 매우 복잡한 작업이므로 양해해 주셔서 감사합니다.)

@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 Functions에서 제어하므로 공개 문제 추적기에 요청을 제출하는 것이 좋습니다. https://cloud.google.com/functions/docs/support

관심 있는 모든 사람: https://issuetracker.google.com/issues/71385193

@laurenzlong 소스를 복사할 때 node_modules 폴더를 무시하고 npm install --production 또는 yarn install --production 를 수행할 수 있습니까? 이러한 도구는 단순히 복사하여 붙여넣는 것보다 빠를 수 있습니다.

@horacehylee
이것은 획기적인 변화일 수 있습니다. 어떤 사람들은 (나 자신을 포함하여) 여전히 상대 경로(예: "package-name": "./externs/package.tgz")로 패키지를 참조할 수 있습니다. 주로 개인 저장소의 ( 현재 수정된 ) 문제 때문입니다. 도구는 이러한 모든 경우를 고려해야 합니다.

다른 하나는 캐싱입니다. Google이 사용자를 대신하여 패키지를 다운로드하려면 내부 캐싱 메커니즘을 구현해야 합니다. 우리는 모두 컴퓨터에 로컬 캐시를 가지고 있습니다(npm과 yarn 모두 캐싱 메커니즘이 있습니다). 따라서 npm의 서버를 죽이지 않습니다.

어떤 사람들은 단순히 외부 라이브러리의 일부 변경 사항을 테스트하기를 원할 수도 있습니다. 파일을 변경하고 기능을 배포하는 것이 포크를 만들고, 변경하고, 패키지에 대한 참조를 일시적으로 변경하는 것보다 훨씬 쉽습니다...

결론: 잘 작동합니다. 지금 그대로 두십시오 :+1:

@horacehylee @merlinnot 2센트 주셔서 감사합니다. https://github.com/firebase/firebase-tools/pull/578 을 참조하십시오. CLI의 다음 릴리스는 더 이상 기능 소스 폴더 기간을 복사하지 않습니다.

1Gbps 파이버 연결에 있는 6개의 4GHz 코어 시스템에 5라인, 1kb 기능을 배포하는 데 몇 분이 걸리는 firebase가 무엇인지 잘 모르겠습니다.

내가 오줌을 싸는 것처럼 들리지만 "업로드를 위한 디렉토리 준비 중"에서 무슨 일이 일어나고 있는지 진심으로 궁금합니다. 실제로 아는 사람이 있습니까?

노드 모듈을 포함한 기능 디렉토리를 tmp 디렉토리에 복사합니다.

다음 릴리스에서는 이 문제를 해결하므로 더 이상 이전에 복사할 필요가 없습니다.
배포 중.

2018년 1월 7일 일요일 오후 5:05 hmexx [email protected] 에서 다음과 같이 작성했습니다.

Firebase에서 MINUTES가 걸리는 작업이 무엇인지 잘 모르겠습니다.
6개의 4GHz 코어 머신에 5라인, 1kb 기능을 배치하고
1Gbps 파이버 연결.

내가 오줌을 싸는 것처럼 들리는 것을 알지만 진심으로 무엇인지 궁금합니다.
"업로드할 디렉토리 준비 중"이 진행 중입니다. 실제로 아는 사람이 있습니까?

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/firebase/firebase-tools/issues/536#issuecomment-355868154 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAAD_nUptJWFuYGvEXI0MwmQR-bG9_MKks5tIWm1gaJpZM4QdF3g
.

@mbleigh

아 맞다. 그것은 그것을 설명합니다. 워크스테이션이 1~2분 동안 미쳐 돌아가는 것을 보는 것은 일종의 코미디입니다. 다음 줄에 "패키지된 기능( 37.55kb !!!) 업로드에 성공했습니다"가 출력됩니다.

다음 릴리스를 기대하십시오. 응답해 주셔서 감사합니다.

시간.

19일차. Firebase가 아직 배포 중입니다. * 팝콘을 움켜쥐다 *

응.

다음 릴리스는 언제 예정되어 있으며 배포 시간의 몇 % 개선을 기대해야 합니까?

이 길을 계속 갈지 말지 알면 됩니다.

이번 주에 출시될 예정이며 "준비 중"
배포를 위한 기능 디렉토리" 단계가 훨씬 더 빨라집니다(나는
정확한 숫자가 있어야 함). 배포의 다른 부분은 변경되지 않은 상태로 유지됩니다.

2018년 1월 15일 월요일 오후 12시 42분에 hmex [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

릴리스 정보에서:

함수를 배포하는 경우 함수 디렉토리 내에서 "npm i --save firebase -functions@latest "를 실행하여 firebase-functions SDK를 최신 버전으로 업데이트해야 합니다. 이를 통해 더 빠른 기능 배포가 가능합니다.

몇 분에서 몇 초로: 잘 하셨습니다!

나를 위해 이것은 여전히 ​​몇 분이 걸립니다.

[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분 이상 걸렸습니다.
약 2.20MB로 압축된 4개의 개인 종속성이 있습니다.
압축 파일로 개인 종속성을 포함하는 유일한 방법이라는 것을 알았습니다.
내가 뭔가 잘못하고 있습니까? 아니면 이것이 작동하는 방식입니까?

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-tools로 업데이트하셨습니까?

네 그렇게 믿습니다. firebase —version 보고 3.18.6.

당신은 나보다 최신 버전에 있습니다. 3.18.6에서 node_modules 폴더를 계속 전송했는지 모르겠지만 현재 3.18.4에서는 모든 것이 잘 돌아가는 것 같습니다...

최근 firebase-tools 버전(node_modules 폴더는 복사되지 않음)에서는 배포 전략이 퇴보하지 않았지만 배포 시간은 컴퓨터마다 그리고 때때로 다릅니다. 함수의 초기 배포도 후속 업데이트보다 느립니다.

preparing functions directory for uploading... 단계에서 배포 시간이 로컬로 실행될 때 이 단계에서만 거의 7분이 소요되는 것으로 나타났습니다. 빌드를 위한 사전 배포 단계는 로컬에서 약 5초가 걸립니다. 배포 프로세스의 다른 모든 단계는 디버그에서 매우 빠르게 실행됩니다. 배포가 다소 느릴 수 있지만 작업에도 AWS 람다를 사용하며 매우 큰 람다 배포는 Python 패키지 설치 및 빌드를 포함하여 2 2 3분의 순서로 이보다 훨씬 빠릅니다.

google 클라우드 빌드에서 배포하는 경우에도 aws 람다에서 10~20초가 소요되는 데 비해 2~3분이 소요됩니다. 업로드하기 전에 cli가 전체 기능 폴더를 압축하는지 묻고 싶습니다.

@laurenzlong , 기능이 이미 병렬로 배포되었는지, 또는 이 최적화가 진행 중인지 자세히 설명해 주시겠습니까?

기능은 항상 병렬로 배포되었습니다. 그러나 10개의 기능을 병렬로 배포하는 것은 단일 기능을 배포하는 것보다 여전히 느립니다.

+1 기능 배포가 매우 느립니다. 나는 첫 번째 톤인 hourly-tick 기능을 만들기 위해 cron 작업 튜토리얼을 따랐고 매번 배포하는 데 1분 정도 걸립니다.

@laurenzlong 응답해 주셔서 감사하고 Firebase에서 열심히 일해주셔서 감사합니다!

배포 시간을 개선하기 위한 적극적인 계획이 있습니까? Firebase를 좋아하지만 배포 시간이 느리기 때문에 실제로 Firebase에서 벗어날 생각을 하고 있기 때문에 여쭤봅니다. 약 47개의 클라우드 기능이 있으며 배포하는 데 정기적으로 3-6분이 걸립니다. 동일한 양의 코드를 Heroku에 배포하는 데 약 20-30초가 소요되는 git push heroku master 와 비교하십시오. 그리고 그 코드는 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 배포를 원자적 DB 트랜잭션(전부 또는 전무)과 같다고 생각하는 반면 Firebase 배포는 부분적 실패와 궁극적으로 일치하는 것과 같습니다... 이로 인해 특히 버그 수정을 푸시하는 경우 개발 작업이 훨씬 더 어려워집니다. 한밤중에 페이지에 대한 응답으로.

솔직히 말해서, Firebase에서의 배포 경험은 객관적으로 Heroku 또는 AWS보다 느리고 덜 안정적입니다. ... 오해하지 마세요. 우리는 Firebase를 좋아하고 여러분의 노고에 진심으로 감사드립니다. 내 말은 이것이 공격처럼 들리는 것이 아니라 개인적인 것이 아니지만 여기에서 더 잘하려면 Firebase가 필요합니다. 그렇지 않으면 배포가 너무 고통스럽기 때문에 다른 곳으로 이동할 생각입니다.

Firebase에 대한 노고에 다시 한 번 감사드립니다. 도움을 주셔서 감사합니다 :-).

데이터 포인트를 공유해 주셔서 감사합니다! 우리는 특히 동시에 많은 기능을 배포하기 위해 이것을 개선할 몇 가지 계획이 있습니다(주로 기능 생성/업데이트를 위해 API 호출이 이루어진 후 서버 측 빌드 단계 개선). 그러나 이는 4분의 1이 소요되는 인프라 변경 사항이므로 그동안 기다려 주셔서 감사합니다.

이미 고려했을 수도 있지만 CI/CD 파이프라인에서 편집된 기능을 감지하는 스크립트를 만들고 --only 플래그가 있는 기능만 배포할 수 있습니다. 그러면 배포 속도가 크게 향상됩니다. 예를 들어 이 비디오를 참조하십시오. https://www.youtube.com/watch?v=iyGHW4UQ_Ts

@laurenzlong 정보 감사합니다, Lauren. 하지만, 제게는 작은 클라우드 기능이 하나밖에 없고, 가장 작은 변경을 한 후에도 배포하는 데 여전히 1분 정도 걸립니다. 클라우드 기능이 하나뿐인데도 해당 플래그를 사용합니다. 여기에서 뭔가 잘못되고 있는 것 같습니다.

2019년 4월 현재도 말 그대로 몇 분이 소요됩니다. 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-

그러나 이는 4분의 1이 소요되는 인프라 변경 사항이므로 그동안 기다려 주셔서 감사합니다.

몇 분기 전 마지막 메모 이후 인프라 측 업데이트가 있습니까? 이러한 변경 사항이 적용될 때까지 이 문제를 다시 열 수 있습니까? 추적이 다른/관련 문제로 이동하지 않는 한 닫힘은 적절한 상태가 아닌 것 같습니다.

Firebase functions 는 모든 것이 빌드/업로드되고 서버 측에서 기능이 생성/업데이트된 후에도 여전히 매우 느립니다. 다른 사람들이 말했듯이 이것은 주요 개발 속도 댐퍼입니다.

firebase --version
7.1.0

고려해주셔서 감사합니다!

@repentsinner 빌드/배포 시간을 개선하기 위한 백엔드 프로젝트는 여전히 진행 중이지만(잘 진행 중입니다!) 아직 출시되지 않았습니다.

개발 프로세스의 속도를 높이기 위해 에뮬레이터( firebase emulators:start 를 통해)를 사용해 보셨습니까? 그렇다면 피드백을 받고 싶습니다!

@samtstern 업데이트에 감사드립니다.

나는 아직 에뮬레이터를 시도하지 않았습니다 - 나는 플러터 앱의 functions.https.onCall 와 firestore의 데이터를 사용하고 있으며 (어쨌든 현재로서는) 앱의 테스트 빌드에서 모든 것을 리디렉션하는 것 같습니다. 내 개발 워크스테이션에 배포를 기다리는 것보다 더 많은 노력이 필요합니다.

🤨 기다리고 있는 시간을 활용하면 될 것 같아요.

아직 해결되지 않은 이 문제에 새해 복 많이 받으세요! 🎉

아마도 관리자 또는 OP는 이 문제의 이름을 "매우 느린 배포를 위한 기능 디렉토리 준비 중"으로 바꿀 수 있습니다. 이는 전체 배포 프로세스의 해당 단계에 대한 수정 사항에만 기반하여 닫힌 것으로 보이기 때문입니다.

그런 다음 ... 기능 배포가 여전히 매우 느리기 때문에 새로운 "기능 배포가 매우 느림" 문제를 열 ​​수 있습니다. 😄

배포 시간을 개선하기 위해 CLI 측에서 더 이상 할 수 있는 일이 없기 때문에 이 문제는 종료되었습니다. 로컬 개발을 위해 에뮬레이터에 계속 투자하고 있으므로 사람들이 개발 수명 주기의 일부가 아니라 제품에 배포할 때만 firebase deploy 을 실행해야 합니다.

백엔드 변경은 아직 진행 중입니다. 알 수 있듯이 예상치 못한 지연이 발생했습니다.

@samtstern 에 대한 설명 감사합니다. firebase/firebase-tools에 대한 문제/요청은 CLI에만 적용할 수 있습니까? 백엔드를 다루는 리포지토리/프로젝트를 찾습니다.

로컬 개발과 관련하여 공개적인 측면에서 보면 Google이 Firebase와 Flutter의 통합을 권장하는 것처럼 보이지만 실제로는 매우 잘 작동하는 것처럼 보이지만 실제로는 이와 같은 개발 시간 불일치에 직면합니다. 이 문제를 발견할 때 제안된 대로 에뮬레이터를 간략하게 살펴보았지만 실제로 통합 Firebase 및 Flutter 개발 워크플로를 전혀 지원하지 않는 것처럼 보였습니다. 나는 이것이 최근에 개선되었는지 알아보기 위해 다시 원을 그리지 않았지만, 그럴 것 같지 않습니다.

@repentsinner 예 이 리포지토리는 CLI 작업만 추적합니다. 물론 우리는 들어오는 모든 것에 답하려고 노력하지만 종종 여기서 우리가 할 수 있는 생산적인 것이 없을 때 문제를 닫아야 합니다. 우리의 백엔드는 오픈 소스가 아니므로 일반적으로 사람들이 Firebase 지원 을 통해 버그 보고서를 제출하거나 일반적인 Firebase에 대한 기능 요청을 제출하도록 안내합니다.

Flutter와 관련하여 우리는 그것을 좋아하지만(참조: https://github.com/FirebaseExtended/flutterfire) 공식 Firebase 플랫폼이 아니기 때문에 우리가 하는 것과 같은 문제에 대한 완전한 지원을 제공할 수 없다는 점에 유의해야 합니다. 기본 안드로이드/iOS/웹. 언젠가는 바뀔 수도 있지만 지금은 상황이 그렇습니다.

Flutter 앱을 Firebase 에뮬레이터에 연결하는 방법에 대해 질문이 있는 경우 FlutterFire 리포지토리에서 문제를 열고 저를 참조하십시오. 그러면 적절한 Flutter 직원도 참여시킬 수 있습니다.

알겠습니다. @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 폴더가 없습니다. 이것이 도움이 된 여러분, 디렉토리 구조는 어떻게 생겼습니까?

@mbleigh 참. 제 추측으로는 이것이 현명하고 이를 functions 디렉토리에 적용하는 것입니다.

@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": "."
  },

나는 기꺼이 그것을 다음과 같이 바꿀 것입니다 :
```
{
"포함": ["lib", "package.json", "package-lock.json"]
}

FWIW 나는 이것들이 glob을 허용한다고 생각하므로 다음을 할 수 있습니다.

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

클라우드 기능을 막 시작했고 배포 시간이 고통스럽습니다.

고통스러운 배포 시간 :(

Firebase 앱에는 현재 60개의 클라우드 기능이 실행되고 있습니다. 처음에는 할당량으로 인해 많은 배포 실패가 발생하기 시작했기 때문에 문서에서 제안하는 대로 배치로 나누었습니다. 지금은 일관되게 배포되지만 각 배치는 기본 실행자에서 GitHub 작업 CI의 일부로 배포하는 데 ~3분이 걸립니다. 배치는 각각 약 6개이므로 총 10개의 배치로 함수 배포 시간이 약 30분입니다.

함수 자체는 최소한의 종속성을 가진 매우 작은 코드 비트입니다. 파이프라인 속도를 높이기 위해 무엇을 더 할 수 있는지 잘 모르겠습니다.

정말 안타깝습니다. 또 다른 접근 방식은 여러 진입점/경로를 단일 기능으로 묶는 것입니다. 이것은 분명히 관심사/크기/보안의 분리에서 가장 좋은 것은 아니지만 이것이 우리가 모든 API 엔드포인트(내부 라우터를 사용하는 단일 진입점)에서 수행한 작업이며 그 이후로 많은 할당량 제한을 경험하지 않았습니다(그러나 그들은 가끔 발생합니다).

그러나 공식 문서 에 "Cloud Functions API를 통한 기능 배포 또는 삭제 호출"에 대한 "100초당 80개"가 나열되어 있기 때문에 이 할당량 제한은 정말 낮은 것 같습니다. Google 지원에서 이 한도를 더 높일 수 없다고 가정합니다.

그러나 공식 문서 에 "Cloud Functions API를 통한 기능 배포 또는 삭제 호출"에 대한 "100초당 80개"가 나열되어 있기 때문에 이 할당량 제한은 정말 낮은 것 같습니다. Google 지원에서 이 한도를 더 높일 수 없다고 가정합니다.

@dinvlad API 한도 증가에 대해 판매 및 지원에 문의했는데 GCP 콘솔 할당량 섹션에서 명시적으로 비활성화/회색으로 표시됩니다. 결국 행아웃에서 "그 할당량은 변경되지 않습니다"라고 알려주는 Google 엔지니어를 얻을 수 있었습니다.... 그래서 그렇지 않은 것 같습니다.

다음 릴리스에서 표준 무시 목록에 .git 를 추가했습니다.
https://github.com/firebase/firebase-tools/pull/2395

일부 사용자에게는 릴리스 속도가 빨라질 것입니다. 물론 우리(Firebase CLI 팀)가 Cloud Functions 백엔드의 지연 시간에 대해 할 수 있는 일은 많지 않습니다.

함수를 업데이트하지 않을 때 firebase deploy --only hosting 를 수행하십시오.

여기에서 우리는 관련 기능을 기능으로 그룹화하여 "기능의 개별 과립당 하나의 기능"이 아니라 "기능 영역당 하나의 기능"처럼 보이게 됩니다.

배포의 성능 특성은 하나의 기능에 들어가는 아키텍처를 강력하게 주도하고 있습니다!

이 문제가 종료된 시기와 이유 2017년 11월에 오픈했는데 아직도 그때만큼은 문제가 많은 것 같습니다. 여기에서 'Closed'에 대한 참조를 볼 수 없으며 폐쇄된 이유를 알고 싶습니다.

불평하는 게 아니라 그냥 궁금해서요. 나는 그것이 작업 중이라고 확신하지만 진행 상황에 대해 아는 것이 좋을 것입니다.

@chriscurnow 최종 사용자에게 CLI 문제로 명시되지만(https://github.com의 @samtstern 당) 실제 원인은 CLI 도구가 아닌 (폐쇄 소스) 서버 측 때문인 것 같습니다. /firebase/firebase-tools/issues/536#issuecomment-572830647).

불행히도 백엔드에 대한 좋은 공개 추적기가 없으므로 여기에서 업데이트를 받습니다.:(

Google이 백엔드에서 이 버그를 수정하도록 이 버그를 어떻게 열 수 있습니까?
무지하게 느리다

예를 들어, 이렇게 오래 걸리면 Firebase 기능을 사용하는 것이 무슨 소용이겠습니까?

여러분, 우리 모두 이 문제를 Google에 보고하고 그들이 들을 수 있을까요?
https://firebase.google.com/support/troubleshooter/contact

중요한 일을 위해 Google의 무언가를 사용하려고 할 때마다 Google이 현존하는 가장 소비자 친화적이지 않은 회사 중 하나라는 것을 상기하지만, 이봐, 우리는 시도할 수 있습니다.

@RenFontes 방금 케이스 00075974를 제출했습니다: Firebase 기능 배포가 너무 느려서 Firebase 지원에서 사용할 수 없습니다 . 나는 그들이 돌아오는 대로 이 메시지를 업데이트할 것입니다.

특정 기능을 배포할 수 있습니다. CLI에 각 기능에 대한 "체크섬 추적기"가 있고 변경된 기능만 배포할 수 없었습니까(또한 사용하는 모든 항목 추적: vars, packages, ...)?

@SrBrahma 는 확실하지만 단일 기능만 배포하더라도 문제는 여전히 존재합니다(예: 단일 기능 배포는 시간 초과로 인해 여전히 실패할 수 있음).

일괄 기능 배포를 관리하기 위해 사용자에게 넘어갈 필요가 없으며 많은 경우에 기능 업데이트가 원자적으로 필요하므로 분할/일괄 처리할 수 없습니다.

해결 방법에 대한 제안에 감사드립니다. 하지만 여기에서 실제로 필요한 것은 Google의 SLA와 이를 준수하는 것입니다.

Firebase Functions 가끔?(아마도 자주) 성능이 떨어진다는 것이 사실입니다..정말 느립니다.. 차라리 Rust를 지원해야 합니다.. Go? 노드보다 훨씬 빠릅니까?

여전히 Google이 Google Functions 배포 시간을 개선하기를 기다리고 있습니까?
PWA에서 SSR로 이동하면서 배포할 때마다 7분을 더 기다려야 했습니다. 😞