6
nettcprelaybinding과 함께 서비스 버스를 사용하고 있습니다. 한 쪽은 서비스 버스에 상시 연결된 OnPremise 서버입니다. 다른 한편으로는 적절한 서비스 버스를 열고 서버에서 정보를 가져 와서 들어오는 웹 요청에 응답하는 Azure 웹 역할이 있습니다.Azure 서비스 버스 릴레이 성능
관심사는 채널 생성의 성능입니다. 서비스 버스를 통해 onpremise 서버에 새로운 연결을 설정하는 데 몇 초가 소요됩니다. 내 ChannelFactory 캐싱은별로 도움이되지 않습니다. 채널이 열린 후에 전송 성능은 매우 좋습니다.
성능을 향상시키는 방법에 대한 제안. Azure에서 캐싱 정보는 어느 정도만 수행 할 수 있습니다. onpremise 서버에 연결해야합니다.
어떻게 든 서비스 버스에 대한 연결 풀을 설정할 수 있습니까?
더 많은 경우, 여러 다른 onpremise 서버가 있으므로 하나의 연결 만 유지하는 것이 아닙니다.
좋은 의견에 감사드립니다. 60 초 제한에 대해 몰랐습니다. 연결을 풀고 싶으면. 그렇게하는 좋은 방법은 무엇입니까? 귀하의 링크 (http://code.msdn.microsoft.com/WCF-Azure-NetTCP-Keep-Alive-09f50fd9)에 따라 그것에 대한 정보를 발견했습니다. 하지만 이것이 다중 인스턴스 Azure 환경에서 좋은 솔루션입니까? 한 인스턴스에서 채널이 열려 있고 다음 클라이언트가 다른 인스턴스에서 실행되는 경우? 또는로드 밸런서가 동일한 인스턴스가 사용되는지 확인합니까? – user1284390
제가 이해하는 한, 각 인스턴스는 자체 연결을 얻습니다. 그리고 그들은 그것들을 열어두기 때문에, 당신은 하나의 네임 스페이스에 허용 된 최대 연결 한계 (2000 년 또는 그와 같은 것들)를 인식 할 필요가 있습니다. 이를 수행하는 것이 좋거나 나쁘다면 성능 및 확장성에 대한 필요에 따라 달라집니다. – BrentDaCodeMonkey
이것은 좀 오래되었지만 단지 Azure LBs가 소프트웨어 기반이며 대부분의 시간 제한은 4 분입니다 (이전 하드웨어 기반 LB의 경우 1 분이 아님). 이것은 이제 구성 가능합니다. 그러나 서비스 클라이 언트 클라이언트 라이브러리가 TCP KeepAlive를 자동으로 구현하고 있으므로 LB 시간 초과는 실제로 문제가되지 않습니다. 현재로서는 https://azure.microsoft.com/en-us/blog에 이의가 없습니다./new-configurable-idle-timeout-for-azure-load-balancer/ – Jmoney38