나는 웹과 워커 다이 노스의 차이점이 Heroku에서 무엇인지 궁금했습니다. 그들은 가격 페이지에 한 문장으로 설명을 제공하지만 이것은 나를 혼란스럽게 만들었습니다. 각각 몇 개를 선택해야하는지 어떻게 알 수 있습니까? 목표로해야 할 비율이 있나요? 나는이 물건에 꽤 익숙해서 누군가가 깊이 설명을 해줄 수 있나요, 아니면 내가 얼마나 많은 다이노를 필요로하는지 계산할 수있는 방법이 있을까요?
또한 각 다이노의 시간이 무엇을 의미하는지 혼란 스럽습니다.
나는 또한이 기사에 일어났다. 제안 된 솔루션 중 하나로서 다이 노스의 양을 늘리라고했습니다. 여기서 어떤 종류의 다이노를 언급하고 있습니까?
답변:
더 많은 다이노 (Cedar의 프로세스라고도 함)가 필요한 경우 가장 좋은 표시는 heroku 로그입니다. 확장 로깅 (무료)으로 업그레이드하여 로그를 추적 할 수 있는지 확인하십시오.
heroku.router 항목을 찾고 있으며 가장 관심있는 값은 대기열 값입니다.이 값이 계속 0보다 크면 더 많은 dyno를 추가해야하는 좋은 징조입니다. 본질적으로 이것은 프로세스가 처리 할 수있는 것보다 더 많은 요청이 들어 와서 대기열에 있음을 의미합니다. 데이터를 반환하지 않고 너무 오래 대기하면 시간 초과됩니다.
내가 두려워하는 이상적인 비율은 없습니다. 많은 웹 프로세스를 필요로하는 앱에서 초당 100 개의 요청을 수행 할 수 있지만 작업자를 사용하지 않습니다. 이메일 전송 등과 같은 백그라운드에서 처리를 수행하는 경우에만 작업자 프로세스가 필요합니다.
ps 백 로그가 너무 깊으면 Dyno 웹 프로세스로 인해 발생합니다.
업데이트 : 2013 년 3 월 26 일 Heroku는 로그 아웃 풋에서 대기열 및 대기 필드를 제거했습니다.
대기열 및 대기 필드가 라우터 로그 메시지에서 제거되었습니다. 또한 Heroku 라우터는 더 이상 수신 요청에 대해 X-Heroku-Dynos-In-Use, X-Heroku-Queue-Depth 및 X-Heroku-Queue-Wait-Time HTTP 헤더를 설정하지 않습니다.
log-runtime-metrics. 이렇게하려면 다음 명령을 실행하십시오 heroku labs:enable log-runtime-metrics. 자세한 내용은 여기 읽기 : devcenter.heroku.com/articles/log-runtime-metrics을
Dynos는 기본적으로 인스턴스에서 실행되는 프로세스입니다. 새로운 Cedar 스택을 사용하면 임의의 셸 명령을 실행하도록 설정할 수 있습니다. 웹 애플리케이션의 경우 일반적으로 사용자의 HTTP 요청에 응답하는 "웹"이라는 프로세스가 있습니다. 다른 모든 프로세스는 이전에 "작업자"라고 불렀습니다. 이는 크론, 처리 대기열 및 웹 프로세스를 묶고 싶지 않은 무거운 계산과 같은 작업을 위해 백그라운드에서 지속적으로 실행됩니다. 또한 추가 동시성을 위해 각 유형의 여러 프로세스가 부팅되도록 각 프로세스 유형을 확장 할 수도 있습니다. 사용하는 각각의 양은 실제로 응용 프로그램의 요구 사항과받는로드에 따라 다릅니다. New Relic 플러그인과 같은 도구를 사용하여 이러한 사항을 모니터링 할 수 있습니다.
많은 사람들이 알려진 비율이 없으며 원하는 '백그라운드'작업자에 대한 웹 작업자의 비율은 애플리케이션 설계 방식에 따라 달라진다고 언급했습니다. 맞습니다. 그러나 일반적인 경험 법칙으로 웹 워커가 제공하는 컨트롤러 작업이 번개 처럼 빠르고 매우 가벼워서 브라우저 작업의 응답 시간 지연을 줄이는 것이 유용 할 것이라고 생각했습니다 . 제공하는 데 약 0.5 초 이상의 실시간이 필요한 브라우저 작업이있는 경우 해당 작업의 대부분을 대기열로 푸시하는 일종의 시스템을 설계하는 것이 좋습니다.
그런 다음이 대기열을 처리 할 오프라인 작업자 다이노를 설계합니다. 출력에 보류중인 HTTP 응답이 없기 때문에 훨씬 더 오래 걸릴 수 있습니다. 아마도 작업을 푸시 한 초기 브라우저 요청에서 렌더링 한 페이지는 요청이 5 초마다 완료되었는지 확인하는 스레드를 시작하는 일부 자바 스크립트를 제공 할 것입니다.
다른 사람들이 제시 한 것과 같은 이유로 작업 할 비율을 여전히 알려줄 수는 없지만 이것이 앱 설계 방법을 결정하는 데 도움이되기를 바랍니다. (또한 이것은 많은 유효한 디자인 중 하나에 불과하다는 점을 언급해야합니다.)
https://stackoverflow.com/a/19965981/1233555 가 임의 라우팅으로 전환되었으므로 일부 dyno는 대기열을 쌓을 수 있으며 (긴 요청을 처리하는 동안) 다른 dyno는 무료입니다. 모든 요청이 웹 다이노에서 매우 빠르게 처리되도록하여이를 방지하십시오. 이렇게하면 필요한 웹 다이노의 수가 줄어들고 작업자 다이노가 더 많이 필요합니다.
또한 일부 Rails 구성에서만 수행하는 동시성을 지원하는 웹 앱에 관심을 가져야합니다.
필요한 각 종류의 다이노 수를 확인하려면 계산하기보다는 시도해야 할 것입니다. 그들의 New Relic이 dyno 대기열을보고하는지 확인하십시오. 위 링크를 참조하십시오.
짧은 대답은 대기열을 유지하는 데 필요한만큼 필요하다는 것입니다.
John이 설명했듯이 로그에서 대기열을보기 시작하면 더 많은 다이노가 필요합니다. 백그라운드 큐가 너무 길어지기 시작하면 (이 정보를 얻는 방법은 구현 한 내용에 따라 다름) 더 많은 작업자가 필요합니다.
응용 프로그램 디자인 및 사용에 따라 크게 달라지기 때문에 비율이 없습니다.
heroku logs -f. 명령 줄에서 사용해야합니다 .
heroku logs -p router --tail