나는 그것이 이러면 안 된다는 것을 몰랐다.Heroku와 Cancancan 퍼포먼스.

지난 1년 동안 저는 원격 팀원들이 그들의 업무 결과를 기록하고 고객을 위해 PDF 보고서를 작성할 수 있도록 내부 웹 앱을 구축해 왔습니다.이 응용 프로그램은 규범에 맞는 업계를 대상으로 하기 때문에 높은 정확성이 필요하다.금융기관이나 의료보건기관이 아니기 때문에 감사 추적과 모니터링 로그가 필요하지 않지만 하드 삭제는 드물다.즉, 팀원들이 이 구성 요소에 대해 어떤 조작을 하기 전에 구성 요소를 잘못 추가한 경우를 하드 삭제하는 경향이 있다.나는 '테스트되지 않음' 이라는 범위를 만들었다

class Component < ApplicationRecord
    has_many :test_records, as: :testable
    scope :untested, -> {
       left_outer_joins(:test_records).
       where(test_records: { testable_id: nil } ) 
    }
end

이것은 다중 연관성을 무시하고 데이터베이스에 있는 모든 테스트 기록을 구성 요소에 연결한 다음 테스트 가능한 id가 없는 기록만 선택하여 테스트 기록이 없는 구성 요소만 수집하도록 합니다.이것은 매우 비싼 요청이지만, 구성 요소를 삭제하기를 원할 때만 발생해야 합니다.이 이야기가 발생했을 때 데이터베이스에는 53000개의 테스트되지 않은 구성 요소가 있었다.
그게 문제야.내 힘으로rb 파일 I는 모든 현장 직원에게 다음 행을 추가합니다.

def certified:
    can :destroy, 
        Component, id: Component.untested.map{ |comp| comp.id }
end

칸칸칸 문서를 보십시오. 이것은 이 점을 실현하는 방법이 아닙니다.내가 왜 전화했어?여기서 지도를 그릴 때, 사용 범위가 아니라?왜 나는 모든 신분증을 수집해야 합니까?왜 나는 일찍 발견하지 못했습니까?
관리자 역할은 당연히 내가 정의한 규칙이 하나밖에 없다can :manage, :all.내가 관리 특권의 상아탑에 앉아 있을 때, 내 사용자는 캔을 호출할 때마다 불필요한 데이터베이스 요청을 받는다.
내가 응용 프로그램에 로그인할 때, 나는 200-500밀리초의 응답 시간을 볼 수 있고, 간혹 2000밀리초의 최고치가 나타날 수 있다.나는 단지 이것이 응용 프로그램의 작업 원리라고 생각했을 뿐이다. 지연으로 인해 예측할 수 없는 지연이 생겼다.심사숙고한 결과, 나는 이것이 발견과 복구가 필요한 문제가 존재한다는 것을 인정하는 것이 아니라, 문제를 해결하기를 희망하는 방식이라고 생각한다.
일단 로그가 효력을 발생하기 시작하면, 비록 현장의 모든 기술자들의 응답 시간이 1000밀리초에서 2000밀리초 사이인 것을 보았지만.몇 달 후 응답 시간이 5000밀리초로 늘어나면서 간혹 시간을 초과할 수도 있다.나는 PDF 생성이 주범이라고 생각해서, 나는 모든 컨트롤러를 다시 써서 조회를 가능한 한 효율적으로 했다.그러나 문제는 여전히 존재한다.
마지막으로 로그의 기술자 사건을 살펴보았을 때 나는 돌파구를 찾았고 내가 제기한 요구와 그들이 제기한 요구 사이의 차이를 알아차렸다.이 두 개의 조회는 모두 사용자 테이블과 역할 테이블에서 선택한 것이지만, 기술자는 구성 요소 테이블에 대한 조회를 실행하고 있습니다. 같은 요청을 실행할 때 이 테이블은 호출되지 않았습니다.

User Load (0.7ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 ORDER BY "users"."id" ASC LIMIT $2 [["id", xx], ["LIMIT", 1]] 
Role Load (0.6ms) SELECT "roles".* FROM "roles" WHERE "roles"."user_id" = $1 LIMIT $2 [["user_id", xx], ["LIMIT", 1]]

Component Load (280.9ms) SELECT "components".* FROM "components" LEFT OUTER JOIN "test_records" ON "test_records"."testable_id" = "components"."id" AND "test_records"."testable_type" = $1 WHERE "test_records"."testable_id" IS NULL [["testable_type", "Component"]]

환영 조회.
어색한 시간을 들여 이 조회가 어디에서 왔는지 찾아내고 프로그램에 따라 코드를 훑어본 후에, 나는 마침내 조회가 캐릭터표에 대한 조회 이후에 발생하지만, 구성 요소표에서 생성된 모든 조회 이전에 발생한다는 것을 알게 되었다.이 검색들 사이에서 코드를 실행하는 유일한 곳은Capabilities표이며 초기 코드를 확실히 찾았다.
나는 0개의 테스트 기록이 있는지 확인하고 장치를 삭제할 수 없을 때 오류 응답을 하기 위해components controller에서 즉시 삭제 방법을 변경했다.나는 나의 능력에서 불쾌한 코드를 삭제했다.rb 파일 및 응답 시간이 500ms 이하로 즉시 감소합니다.사용자들은 미친 듯이 기뻐했다.

이 수정은 하루가 거의 끝날 무렵 오후 5시에 실시됐다.다음은 지난 24시간 동안의 응답 시간입니다.
내가 모르는 일:
수천 개의 ql 오류 코드 = 28000 치명적: pg hba가 없습니다.호스트 ip 주소의 conf 항목, 사용자'postgres', 데이터베이스'postgres', SSL off는 모두 나의 오류 코드의 증상이다.
지속적인 동적 부하는 나쁜 일이 발생하는 징조이다
"Rails의 경우 대용량 메모리 사용은""불가피""하지 않습니다."
히로쿠에 있는 CCTV는 어떻게 생겼을까요?

지난 24시간 동안 동적 부하를 표시합니다.

지난 24시간 동안 메모리 사용 상황을 보여 줍니다.
여러 해 동안 저는 취미 기반과 개발자급에서 Heroku를 사용해 왔습니다. 로그와 분석은 저에게 제공되지 않았습니다.나는 나의 응용 프로그램이 어떻게 실행되어야 하는지 모르겠다. 나는 너희들 중 많은 사람들이 보기에 내가 좀 어리석다고 확신한다. 그러나 솔직히 말하면, 이것은 30초가 걸렸다.잠시 멈추는 것은 나로 하여금 내가 진정한 위기를 겪고 있다는 것을 깨닫게 했다.만약 당신의 히로쿠 지표가 나의 것과 같다면, 당신은 알아야 합니다.... 그렇지 않아야 합니다.