시작 작업을 통해 얻은 개발 tips

스타트 단계에 접어들면서 환경이 매일 순식간에 변화무쌍해지는 과정에서 실패했다.
어떤 실패를 당했는지 간단하게 요약해 봅시다どう対応したか!
참고가 됐으면 좋겠다!
(필요한 항목이 있으면 깊이 파고 투고해 보세요)

【전 서버측】


페이지 응답 속도 향상


당초 지적된 것은 사이트의 응답 속도였다.
따라서 응답 속도를 높이는 데 주력하다
그 결과 컴퓨터 홈페이지의 평가는 40点台MAX96点로 높아졌다.
그나저나 핸드폰은 70분 근처에 있어요.
측정 도구는 PageSpeed Insights (페이지 읽기 시간 측정 및 개선 방안을 제공하는 사이트) 입니다.
[컴퓨터 96점]

대책은 다음과 같다.
  • N+1 대책
  • 캐시 배포 (memocache 일시 지원)
  • 이미지 최적화
  • pc와 sp의 이미지 구분 사용 (jpmobile)
  • 이미지 압축
  • JavaScript 및 CSS에서 async/defer 사용
  • 조회 수정(표 또는 열 추가)
  • 페이지를 열 때 대량의 데이터를 계산하는 등 처리가 응답을 늦춘다!!
  • [인프라 시스템]


    Elastic Beanstalk에서 Elastic Beanstalk의 인스턴스 유형 변경


    전자 Beanstalk를 사용하여 환경을 만드는 경우 EC2에서 인스턴스 유형을 변경하지 마십시오.
    의존관계를 파괴하기 때문에 순조롭게 진행될 수 없다.내가 이렇게 서버를 한참 동안 떨어뜨렸어 (울며)
    나는 이때 환경 재건을 통해 서버의 부활을 실현했다.
    전자 Beanstalk > 대시보드 > 작업 > 환경 재구성

    오류 페이지 설정


    서버가 분실되거나 유지보수될 때 503画面 표시되면 사용자의 불신을 초래할 수 있습니다.404와 500은 rails 측에서 설정할 수 있지만 503은 서버가 떨어졌기 때문에 인프라 측면에서 설정해야 합니다.
    CloudFront의 사용자 정의 Error Response를 사용하여 S3의 Sorry 페이지를 표시합니다.

    느린 질의 설정


    조회의 무게는 당신에게 보이는 페이지뿐만 아니라 서버에도 큰 부담을 줄 수 있습니다.
    결과적으로 백그라운드에서도 영향을 미친다.(메일이 대량으로 도착하거나 도착할 수 없거나,job 등) 자주 검사할 수 있도록 설정하세요!
    아마존 RDS for MySQL에서 느린 조회 로그를 출력하려면

    건강 변화 시 통지


    여러 가지 이유가 있지만 건강이 Severe 해지면 서버가 몇 시간 동안 멈추는 것을 알 수 있다.별일 없도록 건강 변화를 자주 알려주세요.전자 Beanstalk에서 환경을 구축할 때
    전자 Beanstalk > 설정 > 알림 > 알림할 주소 설정 > 적용
    사용자 정의 외관을 정의합니다!

    [기타]


    효과적인 시간 관리 문서


    제 개인 공유는 시간이 필요한 차트입니다.
    1위 개발 프로세스 파악
    2위 시스템 환경 건설
    제3 사용자 자문
    특히 1, 2위는 출입이 격렬해 개발 자원 가동을 줄이는 심각한 문제였다.
    가장 간단한 대처 방법으로 우리는 문서 관리에 주력한다.もし、こんな質問がきたらこのマニュアルを渡す 이런 모델로 문서 관리를 할 수 있다.
    (문서 요약은 Github의wiki에서)

    Github 태그를 사용하여 신규 엔지니어를 신속하게 포착

    ドキュメント管理 또 다른 관련.
    나는 중간에 참가한 엔지니어システムの把握가 매우 오래 걸릴 것이라고 생각한다.
    체계적인 파악에 너무 많은 시간을 들인 것은 아쉽지만, 너무 폄하하면 예상치 못한 오류가 생길 수 있다.만약 이것이 데이터 보존계, 갱신계라면 처리하기가 매우 어려울 것이다.
    그래서 제가 자주 사용하는 것은 Github의アサインタグ付け입니다.
    속셈
    ①自分が担当するissue・pullrequestには必ずself assignする
    ②ある程度シリーズ化したorしそうなissue・pullrequestにはタグづけをする
    
    이 두 가지를 관철하면 다음과 같은 일이 발생할 것이다.
    → 태그 하나만 검색하면 누가 어떤 임무를 맡을지.코드가 뭔지 알아요.
    → 상기 내용을 알고 고장 및 오류 규격을 파악하고자 할 때誰とコミュニケーションをとればいいかがすぐわかる이 절차가 끝나면 중간에 전문적인 엔지니어가 들어와 교류의 다리를 놓을 필요가 없다コミュニケーションコストが大幅に下がります![인상]
    rails 저의 코드를 사용할 수 있도록 허락해 주십시오.사실 이런 개발자는 없다.

    [태그별 정렬]

    [분배자에 따라 정렬]

    좋은 웹페이지 즐겨찾기