요일 나는 Zend Server을 찾고 있었는데 왜 내가 이것을 사용하게 될지 궁금해하고 있었습니까? 좋아, 그들은 모두 테스트 및 미션 크리티컬 엔터프라이즈 준비 등하지만 나에게 그것은 마케팅 부서 얘기.젠드 서버 경험
이 제품을 사용하는 사람이 있습니까? 그렇다면 경험을 공유 할 수 있습니까? 그렇다면 응용 프로그램에서이 제품을 선택하는 이유에 대해 자세히 설명 할 수도 있습니다.
젠드 서버를 사용하면 어떤 실질적인 이점이 있습니까?
젠드 플랫폼을 사용 해왔다. (나는 젠드 서버에 대해 물어 보았다. 나는 거기에있다.) 젠드 서버를 가지고있는 오류보고 도구에 매우 열중하고있다.
오류가 발생하거나 예외가 발생할 때마다 Zend Server는 가능한 한 많은 정보를 저장합니다 (예 : 사용 된 요청 매개 변수, 오류가 발생한 위치, 시간, 오류 메시지, 스택 추적 등).). 또한 느린 스크립트 실행이보고되고 있습니다.
나는 고객이 이러한 오류 메시지를받는 것을 선호합니다. "사이트가 작동하지 않습니다. 문제를 해결하십시오."
Zend Studio를 Zend Studio와 함께 사용하면 Zend Debugger가 이미 사전 설치되어 제공됩니다 (그러나 직접 설치할 수도 있음).
또한 php-java-bridge (자바 클래스는 PHP에서 사용할 수 있음)와 함께 제공되지만 필요하지 않습니다.
웹 응용 프로그램에서 PHP 기반 오류보고 솔루션을 이미 사용하고 있거나 자바 브릿지를 사용하고 있지 않다면 Zend를 사용하는 경우에는 별 효과가 없다고 말할 수 있습니다 자신의 아파치를 서버에 설치 (올바른 설정 방법을 알고있는 한).
적어도 제 의견/경험입니다.
Zend Platform의 Developer Edition을 무료로 사용해 왔습니다. Zend Platform/Server에 대해 비용을 지불해야한다면 사용하지 않을 것이라고 생각합니다. 그러나 그것은 프로젝트에 달려 있습니다.
젠드 서버는 테스트되고 지원되는 스택을 보유하고있는 것보다 훨씬 더 많습니다. Andre는 Zend Server의 기능 중 하나 인 모니터링 기능에 대해 언급했습니다. 모니터링은 특정 조건에 대해 PHP 스크립트 실행을 감시하고 특정 임계 값이 전달되면 나중 시점에서 검토 할 수 있도록 해당 요청의 컨텍스트가 기록됩니다. 애플리케이션 문제가있는 고객과 현장에서 협력 할 때 Zend Server를 설치하고 모니터링을 시작해야합니다. 몇 분 안에 나는 보통 그들의 문제가 무엇인지에 관해 꽤 좋은 이론을 가지고있다.
Zend Server 5는 요청 과정에서 거의 모든 개별 기능/메소드 호출의 런타임 계측을 수행하는 코드 추적 기능이 도입되어 훨씬 더 높아졌습니다. 그것은 런타임 동안 수행되는 디버깅과 프로파일 링의 조합과 같은 종류입니다. 대부분의 경우 실제로 문제를 복제하지 않고 프로덕션 환경에서 문제를 진단 할 수 있습니다.
사용할 수있는 몇 가지 다른 기능이 있습니다. 작업 대기열은 내가 꽤 광범위하게 사용하는 큰 하나입니다.나는 그것을 사용하는 방법에 대한 예제를 가지고있다. Do you queue? Introduction to the Zend Server Job Queue
PHP-Java 브리지 (Andre도 언급 한)와 Optimizer +는 가장 빠른 opcode 단축키 중 하나이다.
확실하게 '테스트를 거친 인증 된'비트는 일부 환경에서 사용하기에 적합합니다. 우리의 경우, 인증 요구 사항은 인증 된 소프트웨어 스택을 사용하거나 자체적으로 진행하지만 우리가 제공하는 모든 작은 구성 요소에 대해 빠르게 업데이트하고 있음을 보여 주어야한다는 것입니다. 그래서, 온전한 목적을 위해, 우리는 역사적으로 리눅스 배포판의 표준 제공품을 사용했습니다. 이것의 문제점은 그들이 곡선보다 수년이 걸리는 경향이 있다는 것입니다. 예를 들어, 대부분의 배포판은 5.1 (!)을 사용하여 PHP 5.3을 최근에 채택했습니다. 현대 코딩 기술을 사용하는 최신 응용 프로그램을 개발하려고 할 때 허용되지 않습니다. PHP 성능과 안정성 측면에서 1 톤을 포기할 수도 있습니다.
그런데, 그 기능도 아주 좋습니다. @Keven은 이미 작업 큐를 언급했다. 비동기 적으로 실행되는 모든 종류의 작업을 매우 쉽게 처리 할 수 있고 주요 요청 프로세스를 계속 진행할 수 있다는 점에서 매우 좋습니다. 예를 들어, 우리의 응용 프로그램 중 하나는 특정 유형의 이벤트가 발생할 때마다 버그 추적기에 작업을 생성합니다. 웹 서비스에 의해 수행되고 버그 추적기가 끔찍하게 느려지므로 몇 초가 걸릴 수 있습니다. 그러나 우리 애플리케이션의 사용자를 대기 상태로 만드는 대신 작업을 큐에 대기시키고 백그라운드에서 실행되도록합니다. 마찬가지로 표준 전자 메일 클래스는 코드가 SMTP 서버와 통신하는 동안 사용자 대기를 기다리는 대신 작업 대기열을 사용합니다. 그리고 큰 보고서 생성, 데이터베이스 무결성 검사 실행, 캐시 재 구축 등의 유용성에 손을 대지는 못합니다.
페이지 캐시는 전체 페이지를 단순히 캐시 할 수있는 경우에 유용합니다. 그것으로 끝났다. 우리는 PHP 자체의 캐싱 제어보다 더 잘 제어 할 수 있기 때문에 이것을 WSDL과 함께 사용합니다. 마찬가지로 다운로드 서버는 이미지와 같은 특정 유형의 콘텐츠를 캐싱하기에 좋습니다. 그리고 우리는 로컬 memcached 서버와 같은 데이터 캐시를 사용하여 저속 네트워크의 어딘가에있는 느린 데이터베이스 서버에 대한 쿼리를 피함으로써 모든 종류의 요청을 신속하게 처리 할 수 있습니다.
@ André에서 언급했듯이 디버깅, 추적 및 이벤트보고 기능이 있습니다.
비즈니스 핵심 응용 프로그램에서 매우 중요한 배치 및 롤백을 수행하는 데 유용한 몇 가지 기능이 있습니다. 나는 언젠가 이것들을 시험해보고자한다. 그러나 지금은 ZS를 사용하기 전에 함께 사용한 도구들을 사용하고있다.
이제 다른 다양한 도구를 함께 사용하여 대부분의 기능 (특히 모든 캐싱 비트)을 얻을 수 있습니다. 그러나 그런 다음 모든 것을 연구하고 배워야하며, 모든 것을 설치하고 함께 작동하게 한 다음 무언가가 업데이트되었을 때 적절한 통합 테스트를 수행하는 등 모든 것을 유지해야합니다. 그게 일이고 작업 시간과 시간은 개인적으로 오히려 코드를 작성하는 데 쓰는 시간이 많은입니다.
모든 것을 말하면 단점이 있습니다. 하나는, 때로는 느낌이 ... 반쯤 구워지고/또는 아프게 생각됩니다. 예를 들어 데이터 캐시 API는 존재하지 않는 항목을 가져 오려고하면 부울 false를 반환합니다. 또한 항목을 가져 오지 않고 항목이 있는지 여부를 확인하는 기능이 없습니다. 이것이 무엇을 의미하는지 추측하십시오 : 안전하게 검색 할 수 없으므로 부울 값을 안전하게 저장할 수 없습니다. 잘못 설명 된 APC 호환성 레이어가 포함되어 있지만 APC에서 존재 기능을 사용하려고하면 정의되지 않은 기능 오류가 발생합니다.
또 다른 예로, 우리는 개발 스테이션을 위해 Mac을 사용하지만 PHP 서버 소프트웨어 인 Zend에 수천 명의 사람들이 몰려 드는 모든 전문 개발자들에 의해 실행되는 경향이있는 고대 하드웨어와의 호환성에 대한 잘못된 잘못된 우려로 인해 는 Mac 버전 (개발 전용)을 32 비트 으로 출하하기로 결정했습니다. 따라서 우리는 64 비트로 실행되는 32 비트 응용 프로그램을 개발해야합니다. 이로 인해 상당수의 버그가 발생하고 응용 프로그램의 자동화 된 테스트가 실패하여 개발, 테스트, 스테이징, QA 및 프로덕션 환경 전반에서 동일한 소프트웨어 스택 인 ZS의 핵심 목적 중 하나가 파괴되었습니다. 나는 이것들을 바꾸라고 그들에게 이야기하려고 노력했다. 그러나 그들은 나를 무시하기 시작했다.
또 다른 큰 점은 작업 큐가 HTTP 요청을 통해서만 작업을 처리 할 수 있다는 것입니다. API는 훨씬 더 합리적인 명령 줄 호출과 같은 다른 방법을 허용하도록 설정되어 있지만 HTTP 만 있으면됩니다. 이렇게하면 의도적으로 오래 실행되는 경향이있는 작업으로 웹 서버 연결을 묶어야하므로 웹 컨텍스트에서 벗어나야합니다. 또한 브라우저에서 URL을 방문하여 전 세계 사용자가 작업을 실행할 수 없게하는 등의 작업을 수행해야합니다. 그것은 단지 어리석은 결정입니다.
다른 예는 shebang 행에 의해 트리거 될 때 Mac에서 깨지는 PHP 바이너리의 php-cli 래퍼 인 Zend Monitor에 대한 API를 통해 보내지는 맞춤 이벤트의 처리 상태가 좋지 않아 건강과 성능이 완전히 부족하다는 것입니다 캐시 도구에 대한보고 (ZS 6에서이 점이 바뀌 었음) 및 당황스럽게 불완전한 문서가 포함되어 있습니다. 나는 계속할 수있다. ...
지금, 그 불리한 점과, 타고가는 시간과 자원은 분명히 우리를위한 이익을 능가하지 않고, 우리가 소비하는 금액 , 나는 더 많이 명확히 기대한다.
코드 추적은
근본 원인 분석은 개발자 문제를 해결
위한 시간 싱크 당신이 그 원인이 무엇인지 알고있을 때 쉽게 젠드 끊다가 제공하는 가장 좋은 도구이다. 그러나 테스트 중에는 문제의 근본 원인을 찾는 것이 어려울 수 있으며 응용 프로그램을 프로덕션 환경에서 실행하는 경우에는 매우 어려울 수 있습니다. 개발 환경에서 정확히 동일한 환경, 애플리케이션 상태 및로드를 재현하려고하면 시간이 많이 걸리고 오류가 발생하기 쉽고 개발자는 코드 작성과 관련하여 가장 중요한 작업을 수행하지 않게됩니다. Zend Server 5는 코드 추적 기능을 통해 근본 원인 분석을 완전히 새로운 수준으로 끌어 올립니다.
PHP 응용 프로그램을위한 비행 기록 장치 코드 추적이란 무엇입니까?
블랙 박스 비행 기록 장치를 생각해보십시오. 비행기에 문제가 생기면 문제를 "재생산"하고 싶지 않을 것입니다. 이러한 이유로 비행 기록원은 비행 분석가가 문제의 원인을 이해하는 데 필요한 전체 데이터를 수집합니다.
젠드 서버 코드 추적은 PHP 용 비행 기록 장치와 같습니다.
Zend Server는 환경을 설정하고 오류를 유발하는 모든 단계를 재생하는 데 시간을 소비하는 대신 프로덕션 또는 테스트 랩에서 실시간으로 응용 프로그램의 전체 실행을 캡처하므로 신속하게 근본 원인을 찾는다.
젠드 서버 코드 추적 문제는 사용자, 예를 들어, 수동으로 감지되는 경우, 또는
젠드 서버 코드 추적이 자동으로 활성화됩니다 근본 원인 분석 시간을 잘라 최적화 프로젝트 중.젠드 서버 코드 추적에 의해 기록 데이터는 다음과 같습니다
Zend Server 웹 콘솔에 표시되는 추적을 통해 DVD와 마찬가지로 응용 프로그램의 실행 기록을보고 문제가있는 단일 요청의 발판을 따라 신속하게 근본 원인을 찾아 낼 수 있습니다.
COBOL을 사용하여 20 년, 30 년 동안 실행되었던 오래된 소프트웨어가있는 IBM의 대형 서버 (IBMi 시리즈)에서 실행되는 PHP 응용 프로그램에서 작업합니다. 기본적으로 Zend Server는 IBM i에서 작동하는 것으로 알고있는 유일한 PHP 플랫폼이거나 최소한 IBM만큼 강력합니다. 이러한 시스템은 업무에 핵심적입니다. 기본적으로 대부분의 보험 회사, 은행, 주식, 심지어 교육구도 이러한 유형의 시스템에서 운영됩니다. 젠드 서버와 같은 것을 실행할 수 있기 때문에 현대 시스템에서 고대 시스템을 노출시키고 서비스 지향 아키텍처를 허용하는 REST API를 빌드하는 것과 같은 일을 할 수 있습니다. 그게 내가 작업 해 왔던 것뿐 아니라 데이터를 제 3 자에게 보냅니다 PHP CLI와 Zend Job Queue를 사용하는 Event Driven System입니다. 이 경우 우리는 데이터를 회사 측에서 공급 업체 측으로 동기화합니다.
IBMi의 젠드 서버는 정적 리소스 (CSS, 이미지 등)를위한 nginx 프론트 엔드로 설정되어 있으며 동적 PHP 용 FastCGI 프로세스를 사용하므로 매우 강력한 설정입니다. 현대화를위한 오래된 시스템을 열어줍니다.
젠드 서버를 사용하면 모든 서버에서 PHP의 소프트웨어 버전 및 모든 다양한 확장 기능을 최대한 활용할 수 있습니다.
또한, 사용자 입력 및 환경 변수를 사용하여 문제의 원인을 특정 PHP 기능으로 분류하는 것이 특히 트래픽이 많은 서버에서 PHP 오류 로그를 추적하는 것보다 훨씬 유용합니다.
오픈 소스 대안이 있다면, 그것에 대해 알고 싶습니다! Zend가 무료 버전을 중단 한 것이 너무 행복하지 않습니다.