바니시 대 다른 리버스 프록시

모든 웹 트래픽에 대한 캐싱 리버스 프록시로 Varnish를 배포 한 조직과 협력하고 있습니다. 이들의 트래픽 구성은 고객이 생성 한 많은 동적 웹 사이트이며 일반적인 정적 자산 모음이 옆에 매달려 있습니다.

나는 니스를 좋아하려고 노력하고 있지만 (원칙적으로 꽤 좋은 아키텍처를 가지고 있다고 생각합니다) 관리 및 문제가 발생할 때 문제를 해결하는 데 어려움이 있으므로 실제로 올바른 선택인지 궁금합니다. 나는 과거에 오징어를 리버스 프록시로 사용했지만 같은 종류의 역할을하지 않았으므로 비교할 명확한 근거가 없습니다.

내 질문은 프로덕션 환경에서 바니시를 배포했거나 대안에 대해 심각하게 평가 한 사람들을 대상으로합니다. 바니시를 사용하거나 다른 리버스 프록시를 사용하게 되었습니까? 그 상태를 유지하거나 전환해야 할 핵심 사항은 무엇이며, 다른 것을 사용했다면 무엇을 사용하게 되었습니까?

글쎄,로드 밸런싱 기능도 편리하지만 주로 성능상의 이유로 웹 서버에서 Varnish를 실행하고 있습니다.

내 유스 케이스는 Django 기반 웹 사이트 앞에서 캐싱 하고 있으며 페이지 로딩 성능이 궁금합니다. 캐시에서 직접 대부분의 페이지를 제공하고 거의 문제없이 방문자 수를 처리 할 수 ​​있습니다.

내가 Varnish를 선택한 이유는 주로 성능 / 확장 성 때문이었습니다. 요점 :

• 바니시는 스퀴드가 별도의 디스크 및 메모리 캐시를 유지하려고 시도하는 가상 메모리를 커널이 관리하게함으로써, 디스크로 페이징 될 내용에 대해 커널과 오징어를 약간 뭉개 버릴 수 있습니다.
• Varnish는 도메인 고유의 구성 언어 인 VCL을 사용하며 C를 통해 기계 코드로 컴파일됩니다. 이는 구성에 약간의 논리 (조건부 헤더 제거 등)가있는 경우 매우 실제적인 성능 이점입니다.

내 경험상 Varnish는 대부분의 경우 오징어보다 약간 더 성능이 좋으며 트래픽 급증에 대해서는 훨씬 우수합니다. 반면, 바니시를 올바르게 구성하면 메일 목록 목록 트롤링이 필요합니다. 순서에 따라 즉시 사용할 수있는 특정 사용 사례 문서가 많지 않기 때문입니다. 오징어의 경우 – 바니시는 비교적 젊은 프로젝트이기 때문입니다.

나는 늪지 표준 리눅스 / 델 하드웨어에서 Varnish 1.x를 안정적으로 얻으려고 오랜 시간을 보냈습니다. 항상 이상한 방식으로 멈추고 워치 독이 다시 시작합니다. 다른 곳에서는 지속되지 않은 하드 원 캐시를 제외하고는 괜찮습니다 ...

말했듯이, 실제로 작업에 적합한 도구를 사용하고 있습니까? 요청 결과를 캐시 하는 리버스 프록시를 원할 경우 (좋은 품질의 캐시 헤더를 제공한다고 가정) 니스는 좋은 옵션입니다. 바라건대 버전 2.0에서는 더 안정적입니다.

그러나 * onRails 사이트를 실행 중이고 여러 백엔드 서버를 통한로드 밸런싱을 원할 경우 HAProxy 또는 Nginx를 사용하는 것이 좋습니다. 복잡한 URL 로직이 필요하지 않은 경우 (리디렉션, 이전 URL을 다시 작성하기 위해 정규식 일치 등) HAProxy가 청구서에 적합합니다. 더 유능한 것이 필요하다면, nginx를 사용하십시오.