웹 애플리케이션 시작 시간이 정말로 중요합니까?

응용 프로그램 시작시 초기화 코드를 추가하는 것에 대해 다른 사람과 대화를 나누었으며 시작 시간이 길어 졌다고 불평했습니다. 그는 실제로 이유를 말할 수 없었습니다 (장 느낌 또는 무언가, 몰라). 이 응용 프로그램은 사용량이 많은 응용 프로그램이 아니며 약 1 분 정도면 시작되며 1 년에 몇 번 배포됩니다.

나는 얼마 전에 SO에 관한 질문에 대한 조언을 읽은 것을 기억합니다. 사람들은 "당신이 페널티를 감당할 수 있다면"스탬프가있는 페이지에 액세스하는 대신 시작시 초기화하는 것이 좋습니다.

나는 30 초에서 4-5 분 사이에 시작된 웹 앱으로 작업했지만 온라인으로 전환했습니다.

그래서 내가 무엇을 놓치고 있습니까? 금융 시장, 의료 응용 프로그램, 우주 탐사 등을위한 중요한 응용 프로그램이 아닌 한 시작 시간이 정말로 중요한가?

추신 : 나는 웹 응용 프로그램을 엄격히 언급하고 있습니다. 데스크톱 응용 프로그램은 번개를 빨리 시작해야합니다.

개발하는 동안 큰 요소가 될 수 있습니다. 플랫폼이 실행중인 응용 프로그램에서 코드 변경을 지원하지 않으면 시작 시간이 피드백주기의 일부가되고 30 초조차도 고통스럽고 생산성에 위협이됩니다.

프로덕션 환경의 경우 실제로 중요하지 않습니다. 약간의 가동 중지 시간이 허용되고 5 분이 아직 걸리지 않거나 그렇지 않아서 일종의 라이브 전환을 구현해야합니다.

나는 이것이 헤겔의 유명한 변증 법적 원리에서 수량에서 품질로의 전환이라는 사실이 사실이라고 생각합니다.

알다시피, 타이밍은 항상 중요합니다. 개발 / 테스트 중 빠른 빌드의 중요성에 대한 Michael Borgwardt의 말에 동의하지만, 다른 방식으로도 생산에 매우 중요하다고 주장합니다.

프로덕션에 잘못된 코드를 배포 한 각 개발자는 5 분과 1 분 안에 제공되는 핫픽스가 실제로는 실제로 다르다는 것을 알고 있습니다.

실제 질문은 앱이 초기화없이 작동하는지 여부입니다. 우리는 "성능"에 집착하는 신입 사원을 보유하고 있습니다. 제 주식 답변은 당신이 얼마나 빨리 잘못된 결과를 내는지에 대해 신경 쓰지 않습니다. IMHO는 모서리를 자르고 알고리즘을 망가 뜨리며 "이 방법은 더 빠를 것"이기 때문에 다른 훌륭한 아이디어는 버그만 소개합니다.

초기화가 필요한 경우 수행하십시오. 최종 사용자가 잘못된 결과를 얻었을 때 얼마나 많은 시간이 낭비 될까요? 결국 웹 앱이 잘못되었다는 사실을 파악하고 전화를 걸어 불평하고 다시 돌아가서 디버그 / 수정 / 테스트 / 재배치해야합니까? 이제 시간을 어떻게 절약했는지 동료에게 물어보십시오. (어쨌든 서버 코어가 99 % 유휴 상태 일 것입니다.)

이 질문은 특정 플랫폼에 대해서는 묻지 않습니다. 시작 시간이 정말로 중요한 플랫폼이 있습니다.

예를 들어 Google App Engine에서; 페이지에 액세스하지 못하거나 같은 노드의 다른 응용 프로그램보다 덜 자주 액세스하는 경우 때때로 언로드됩니다.

따라서 사이트 액세스 빈도의 99 % 이하인 경우 시작 시간 은 액세스 시간입니다. 거의 모든 액세스에서 응용 프로그램이 다시 시작됩니다. 당신이 경우 입니다 상위 1 %에, 당신의 응용 프로그램이 여러 노드에서 최대 시작되어, 많은 페이지 액세스가 이미 시작 인스턴스에서 반환됩니다 있지만, 일부는 여전히하지 않습니다, 당신은 단속을해야하므로, 긴 액세스 시간 .

다른 많은 호스팅 환경에서도 마찬가지입니다. 써드 파티 라이브러리 또는 심지어 발견을 피하기 쉬운 자신의 코드에서 누출이 발생하면 웹 서비스를 실행하는 유일한 신뢰할 수있는 방법은 많은 요청 (보통 100에서 10,000 사이)을 다시로드하는 것입니다. 시작 시간은 자주 지불됩니다. 앱이 누출 된 경우이 패턴을 사용할 수 있지만 빠르게 시작됩니다. 앱을 시작하는 데 몇 초 이상 걸리면 작동하지 않습니다.

응용 프로그램이 표준 이하로 간주되거나 개발 능력이 저하 될 위험이 있습니다. 이제이 앱은 많은 시간을 절약하고 / 또는 감사하는 사용자가 오랜 시작을 지나칠 수 있도록 필요한 작업을 수행 할 수 있습니다.

앱을 느리게로드하는 방식으로 프로그래밍하는 데 시간이 더 걸릴 수 있지만 이해 당사자 만 가치가 있는지 판단 할 수 있습니다. 55 초 안에 보고서가있었습니다. 우리는 그것을 35로 줄였습니다. 아무도 눈치 채지 못했습니다. 나는 35에서 18까지 그것을 얻는 데 두 배나 많은 시간을 보냈지 만 모든 사람들이 주목하고 감사하고 감동했습니다. 1 년에 몇 번 사용 된 앱에 대해 5 분에서 3 분으로 이동하는 것은 큰 문제가 아닙니다. 사용자는 Facebook에서 시간을 보내거나 커피를 마시는 시간이 줄어 듭니다.

인식이 핵심입니다. 일반적으로 개발 팀과이 앱에 대해 컴포지션이 만족스럽지 않은 경우 영업권을 구축하고 업무 속도를 높이는 것이 좋습니다.