lockedLoadData / 캐시되지 않은 페이지 빌드의 목적은 약 1 분 정도 걸리며 usleep에 소비됩니다.

Magento 2.3.1로 업데이트 한 후 캐시되지 않은 페이지로드에 문제가 있다고 생각합니다 (개발 중).

나는 blackfire.io 추적을했는데 여기 에서 42 초가 usleep에 소비 된 것으로 나타났습니다 .

이제 나는 이것이 목적이 무엇인지 궁금합니다. 나는 어떤 종류의 경쟁 조건에서 달리고 있다고 생각합니까?

전에 이런 경험을 한 사람이 있습니까?

편집 : 호출 스택에 commercebug가 관련된 것 같습니다.

그게 선택이야? -마 젠토 엔지니어들이 만들었습니다.

이것은 대답이 아니지만 해당 함수가 캐시 된 데이터를로드하는 콜백을 허용하는 것처럼 보입니다. 콜백은 현재 잠금 장치가 있는지 확인합니다. 그렇지 않은 경우 잠금을 설정하고 데이터를로드 한 다음 잠금을 해제합니다. 장소에 블록이 있다면, 그것은 잠 을위한 100,000마이크로 초 (0.1 초) 후 다시 로더를 호출합니다.

그래서 크게 생각하면 내 추측은

1. 이 함수에 대한 정상적인 요청 수보다 많은 수
2. 캐시에서 일반적인 읽기 시간보다 깁니다.

lockedLoadData 메커니즘은 서버의로드를 줄여야합니다.

이전에는로드가 많은 사이트에서 구성 캐시를 정리할 때 모든 클라이언트가 CPU / IO로드를 크게 증가시키는 동일한 정보를 생성했습니다.

lockedLoadData를 사용하면 하나의 클라이언트 만 캐시를 생성하고 다른 클라이언트는 캐시를 생성합니다.

작동 방식에 대한 자세한 내용

첫 번째 함수는 "데이터 가져 오기"콜백을 호출하고 단순히 반환하는 것보다 데이터를 가져 오는 경우 (캐시의 데이터가 이전과 같이 작동하고 잠금을 사용하지 않는 경우).

데이터를 사용할 수없고 잠금이 잠긴 경우 루프에서 데이터가 도착하거나 잠금이 제거 될 때까지 데이터를로드하려고합니다.

잠금이 없으면 잠금을 생성하고 캐시에 저장하여 데이터를 생성하고 잠금을 제거하고 데이터를 반환합니다.

추신 : 우리는이 변경 사항을 최대 20kRPM로드의 클라이언트 중 하나에 대한 패치처럼 보냈으며 문제없이 3 개월 이상 작동합니다. 따라서 사용자 지정 / 모듈의 문제 일 수 있습니다 (예 : 캐시 메커니즘을 위반 한 경우)