0
저는 Thrift 애플리케이션 용 서비스 검색을 구현하고 있습니다. 서버는 자신의 주소를 ZooKeeper의 알려진 경로에 알리고 클라이언트는이 경로의 로컬 캐시를 유지 관리하여 큐레이터 서비스 검색과 마찬가지로 요청을 서버 인스턴스로 동적으로 라우팅합니다.캐싱 둔화 전송
각 클라이언트는 실제 서버에 연결하는 데 필요한 TTransport도 캐시해야합니까? 이렇게하면 서버에 대한 후속 요청에 대해 TTransport을 다시 열지 않아도됩니다. 그러나 TTransport을 캐싱하면 클러스터의 각 서버에 대한 연결을 유지해야하므로 내 클라이언트와 서버의 성능이 저하 될 수 있습니다.
오픈 TTransport 연결을 캐시하는 것이 안전할까요? 요청할 때마다 연결을 재협상하는 것이 더 좋습니까?
편집 : I went ahead and implemented service discovery with TTransport caching 편집자 : 그러나이 방법이 올바른지 확실하지 않습니다. 이것이 올바른지 또는 더 나은 해결책이 있는지 알고 싶을 것입니다.
연결을 유지하고 있다면 어떻게해야합니까? – ashwin153
나중에 닫으려는 경우가 있으므로 포인터를 어딘가에 두는 것이 좋습니다. 우리는 캐싱 (또는 풀링)에 대해 이야기하기 때문에, 기본 OS 제한 때문에 일부 리소스가 다른 스레드에서 사용될 수 없다는 점에 유의하십시오. – JensG
저는 전송이 스레드로부터 안전하지 않다는 것을 알고 있습니다. 따라서 스레드간에 동기화가 이루어지고 있습니다. 나는 다수의 공개 전송이있을 때의 잠재적 인 성능 영향에 더 관심이 있습니다. 그게 내 클라이언트 또는 내 서버에 문제가 될 수 있는지 아십니까? – ashwin153