핸드셰이크 비용

Magento 통합이 느리다면 숨겨진 네트워크 비용 때문일 수 있습니다.

예전에 가격 API와 통신하는 상품 내보내기 작업을 실행한 적이 있습니다. 상품 하나는 빠르게 처리되었습니다. 하지만 전체 카탈로그를 처리하는 데는 영겁의 시간이 걸렸습니다. 데이터베이스는 유휴 상태였고, 프로파일러를 통해 확인한 결과 문제는 네트워크에 있었습니다.

코드가 루프 내부에서 새로운 HTTP 클라이언트를 생성하고 있었습니다.

HTTPS를 통해 데이터를 보내기 전에, 머신은 많은 작업을 수행합니다. 소켓을 열기 위해 TCP 핸드셰이크를 수행합니다. 그다음 인증서를 교환하고 키를 협상하기 위해 TLS 핸드셰이크를 수행합니다. 이 과정에서 여러 번의 왕복(round trips)이 발생합니다.

한 번만 수행한다면 비용은 낮습니다. 하지만 40,000개의 상품을 처리하는 루프 안에서 이 작업을 수행한다면, 그 비용을 40,000번 지불하게 됩니다. 실제 데이터는 작지만, 설정 과정이 비용이 많이 드는 부분입니다.

PHP에서는 클라이언트를 생성하고 바로 버려도 될 것처럼 느껴질 때가 많습니다. 단일 웹 요청에서는 이 방식이 작동하지만, 장시간 실행되는 프로세스에서는 실패합니다.

크론 잡(cron jobs), 콘솔 명령(console commands), 또는 메시지 큐 컨슈머(message queue consumers)에서 다음과 같은 패턴을 피하십시오:

이 코드는 매 상품마다 새로운 연결을 열고 전체 핸드셰이크를 실행합니다.

Guzzle은 동일한 클라이언트 인스턴스를 사용하면 연결을 유지합니다. 클라이언트를 루프 외부로 옮기십시오:

  • $client = new \GuzzleHttp\Client(['base_uri' => 'https://api.example.com']);
  • foreach ($products as $product) {
  • $client->post('/sync', [...]);
  • }

이제 소켓과 TLS 세션이 열린 상태로 유지됩니다. 핸드셰이크는 한 번만 수행하고 나머지는 스트리밍합니다. Magento에서는 클라이언트를 수동으로 생성하는 대신, 생성자를 통해 설정된 클라이언트를 주입(inject)하십시오.

이를 지키지 않으면 단순히 지연 시간(latency) 문제만 발생하는 것이 아닙니다. 아웃바운드 포트가 고갈될 수 있습니다. 닫힌 연결이 OS에서 회수되는 속도보다 더 빠르게 TIME_WAIT 상태로 쌓이게 됩니다. 그러면 서비스가 아예 새로운 소켓을 열지 못하게 됩니다.

코드에서 이 실수가 있는지 확인하십시오. 터미널에서 다음 명령어를 실행하십시오:

grep -rn "new .*Client(" app/code | grep -i http

루프 내부에 위치한 새로운 클라이언트 생성이 있는지 찾아보십시오. 클라이언트를 루프 밖으로 옮기십시오. 이는 대규모 동기화 작업에서 엄청난 속도 향상을 제공하는 단 한 줄의 코드 변경입니다.

Source: https://dev.to/iamrobindhiman/the-handshake-tax-reuse-your-http-client-in-magento-integrations-3kk7