PHP 버 전 은 어떻게 선택 합 니까?어떤 버 전 을 사용 해 야 합 니까?

75%가 넘 는 사이트 에서 PHP 를 개발 언어 로 사 용 했 고 wordpress,phpmyadmin 과 다른 일부 오픈 소스 프로젝트 가 성행 하면 서 많은 긴 꼬리 사용 자 를 가 져 왔 다.그러나 이들 은 보통 설치 후 업그레이드 가 거의 되 지 않 는 다.아래 그림 은 현재 PHP 사용 통계 입 니 다.

놀랍게도 이 그림 의 왼쪽 부분 은 지원 되 지 않 는 PHP 버 전 을 나타 낸다.PHP 5.2 는 2011 년 1 월 에 이미 유지 되 지 않 았 습 니 다.이것 은 결코 당신 이 그것 을 사용 할 수 없다 는 것 을 의미 하 지 는 않 지만,이것 은 어떤 안전 한 업 데 이 트 를 의미 하 며,당신 은 따라 갈 수 없다 는 것 을 의미한다.일부 발행 판 은 버그 를 복구 하려 고 시도 할 것 이지 만,당신 의 PHP 버 전 은 약간 할 말 이 없 는 것 같 습 니 다.왜냐하면 당신 이 사용 하고 있 는 것 은 2006 년 의 유행 이 지난 기술 이기 때 문 입 니 다.
어디서부터 시작 해 야 할 지
PHP 5.2 버 전 을 선택 한 사람 은 없 지만 이런 일 들 은 이미 발생 했다.그러나 나 는 내 가 이 블 로 그 를 써 서 무슨 말 을 하 는 것 이 아니 라 업그레이드 지침 을 주 는 것 도 아니다.일반적으로 그들 이 사용 하 는 것 은 2006 년 부터 시 작 된 호스트 공간 이다.그들 은'장기 지원'버 전 을 가지 고 업 데 이 트 된 버 전 을 사용 하지 않 거나 아직 업그레이드 할 계획 이 없다.아니면 이유 가 정말 많아 요.하지만 좋 은 것 은 새 PHP 에서 기다 리 고 있 습 니 다.
PHP 5.3 에 유용 한 OOP 기능 이 많이 추가 되 었 습 니 다!예 를 들 어 익명 함수,SPL 확장 은 교체 기 뿐만 아니 라 신화 적 인 DateTime 확장 은 모두 PHP 5.3 에 통합 되 었 습 니 다.아주 중요 한 E 도 추가DEPRECATED 의 오류 보고 표지 입 니 다.현재 사용 하고 있 는 기능 들 이 다음 버 전에 서 사용 할 수 없 음 을 알려 줍 니 다.만약 당신 이 이미 PHP 5.3 을 사용 하고 있다 면,당신 의 향후 업그레이드 도 로 는 더욱 원활 해 질 것 입 니 다.만약 온라인 프로그램 이 낮은 버 전에 서 실행 된다 면,업 그 레이 드 를 권장 하지 않 습 니 다.
PHP 5.4 는 더 빠 른 실행 효율 과 더 적은 메모리 사용량 을 가 진 일련의 최 적 화 를 진행 했다.다음은 기준 테스트 결과 다.

traits 특성 을 사용 하 든 PHP 5.4 는 프로그램 성능 을 향상 시 키 고 하드웨어 원 가 를 낮 추 었 습 니 다.그래서 저 는 오픈 소스 소프트웨어 를 사용 할 때 업 그 레이 드 를 유지 하 는 것 을 권장 합 니 다.
PHP 5.5 는 아직 테스트 중 이 며 생산 환경 에는 적용 되 지 않 는 다.PHP 5.3 이후 업그레이드 위험 과 변경 이 크게 줄어든다.
다음은 밀 학생 이 정리 한 글 입 니 다.
여러분 은 PHP 버 전 을 선택 할 때 매우 곤 혹 스 러 울 것 입 니 다.이렇게 많은 버 전이 있 는데 도대체 그것 을 선택 하 시 겠 습 니까?
질문:
우 리 는 현재 windows server 2008 r2 를 사용 하여 서버 를 새로 샀 다.php 5.4 환경 설정.
그러나 우리 가 이전에 개발 한 2003,phop 은 5.2 버 전 으로 새 서버 에 이식 하면 프로그램 운행 에 영향 을 줄 수 있 습 니까?아니면 내 가 그 문제 들 을 더 주의해 야 하나?
API 버 전
PHP 는 큰 버 전 에서 아래로 호 환 되 는 업그레이드 방식 을 사용 합 니 다.즉,5.5 호 환 5.1-5.4 입 니 다.그럼 에 도 불구 하고 실제 호환성 이 낙관적 이지 않 습 니 다.PHP 정부 가 어떤 좋 은 해결 방법 을 제시 할 지 기대 하지 마 세 요.현재 2013 년 9 월 버 전 5.2.17 5.3.27 5.4.17 5.5.3
5.2.17
이 버 전 은 가장 광범 위 한 버 전 을 지원 한다 고 할 수 있 습 니 다.현재 대부분의 오픈 소스 소프트웨어 는 이 버 전 을 사용 하고 있 습 니 다.예 를 들 어 Drupal 7.23,Joomla 2.5,국내 대부분 소프트웨어:dedecms 5.7,discuzX 3 등 최신 버 전 은 아직도 5.2 를 지원 하고 있 습 니 다.특별한 요구 가 없 으 면 이 버 전 을 설치 하 는 것 이 가장 편리 하지만 장기 적 으로 보면 버 려 질 수 있 습 니 다.현재 많은 호스트 업 체 들 이 인력 비용 을 절약 하기 위해 PHP 버 전 을 업그레이드 하 는 것 도 귀 찮 고,어차피 기본적으로 지원 한다.여기에 한 마디 를 삽입 합 니 다.현재 국내 소프트웨어 는 더 많은 설치 환경 을 호 환 하기 위해 심혈 을 기울 이 고 있 습 니 다.심지어 PHP 5.1 도 지원 할 수 있 습 니 다(discuzX 3 는 지원 하지 않 습 니 다).가장 얻 기 어 려 운 것 은 성능 도 별로 뒤떨어 지지 않 았 습 니 다.이렇게 할 수 있 는 것 은 정말 쉽 지 않 습 니 다!)Drupal 6 은 이 버 전 을 사용 하 는 것 을 권장 합 니 다.
5.3.28(추천)
이 버 전 은 이름 이 5 로 시작 되 었 지만 많은 사람들 이 PHP 6.0 버 전의 시작 으로 성능 이 향상 되 었 다 고 생각 하고 많은 API 가 변화 하여 5.2 에 대한 호환성 이 좋 지 않다.일부 오픈 소스 소프트웨어 는 5.2-5.3 을 호 환 할 수 있다 고 주장 하지만 문제 도 적지 않 은 것 같다.많은 아예 5.2 를 포기 했다.예 를 들 어 Joomla 3 는 5.3 이상 만 지원 한다.Drupal 7 에 대해 서 는 이 버 전 을 사용 하 는 것 을 강력 히 권장 하 며,지원 이 상당히 좋다.Drupal 8 에 대해 서도 이 버 전 을 사용 할 수 있어 지원 도 좋다.이 버 전 은 사용 범위 가 매우 넓 어서 성능 과 호환성 을 겸비 한 사이 에 좋 은 균형 점 을 만들어 낸다.
5.4(가볍게 추천)
5.4 기본적으로 완전 체 에 가 까 워 졌 고 현 재 는 비교적 완선 하 며 안정성 과 성능 도 좋다.앞으로 업 그 레이 드 될 중점 버 전 은 Drupal 7.X 가 지원 할 수 있 지만 제3자 모듈 은 아직 완벽 하지 않다.나중에 업그레이드 하 는 것 이 귀 찮 으 면,이 버 전 을 설치 할 수 있다.
5.5
5.3 부터 앞으로 버 전 은 기본적으로 주력 성능 의 향상 으로 함수 와 모든 것 을 뒤로 호 환 할 수 있 습 니 다.5.5 처음에 64 개의 버 전이 있 는 것 같 았 고 성능 이 더욱 강 했 습 니 다.저 는 해 본 적 이 없어 서 감히 말 을 하지 못 했 습 니 다.
총결산
만약 오픈 소스 소프트웨어 가 PHP 5.3 을 설치 하 는 것 을 권장 한다 면,당신 은 항상 5.3 을 성실 하 게 사용 하 세 요.5.5 같은 것 을 사용 하지 마 세 요.어차피 호 환 될 수 있 고 성능 이 더 좋 을 것 이 라 고 생각 할 수 있 습 니 다.왜 새로운 것 을 사용 하지 않 습 니까?말 은 이렇게 하지만 오픈 소스 소프트웨어 는 개발 할 때 보통 특정한 환경 에서 개발 되 는 것 을 알 고 있 습 니 다.아무리 잘 호 환 되 더 라 도 예상 치 못 한 의외 의 사고 가 있 을 수 있 습 니 다.(아무리 강 한 팀 이라도 모든 함수 API 를 호 환 테스트 할 수 없습니다.그것 은 상당히 무 서운 작업량 입 니 다!)이 는 특정한 환경 에서 테스트 와 최적화 만 할 수 있 고 호환성 에 문제 가 있다 는 것 을 알 더 라 도 팀 은 더 높 은 버 전 을 호 환 하기 위해 수정 하지 않 을 것 이다.그들 이 딱딱 한 것 이 아니 라 안전 과 안정 을 위해 고려 하 는 것 이다.개원 분위기 에서 우 리 는'충분 하면 가장 좋다'는 의식 을 가 져 야 한다.'최신 이 가장 좋다'는 것 이 아니 라'가장 좋다'는 것 이다.예 를 들 어 Joomla 3.1 은 5.4-5.5 에서 모두 작 동 하지 않 고 설치 에 성공 하지 못 했다.그러나 Drupal 은 5.5.3 에서 도 정상적으로 작 동 하고 있 습 니 다.제 생각 에는 개별 사례 인 것 같 습 니 다.그러나 실행 중 예상 치 못 한 오류 가 발생 한 것 같 습 니 다.버 전의 문제 인지 아 닌 지 는 모 르 겠 습 니 다.아니 었 으 면 좋 겠 습 니 다.

None-thread-safe or thread-safe
Apache 는 보통 none-thread-safe,IIS 는 후자(FAST-CGI)를 선택한다.나 는 설명 하지 않 겠 다.신 이 형 이 맞다.
TS 는 Thread Safety,즉 스 레 드 보안 을 말 하 며,일반적으로 IIS 가 ISAPI 방식 으로 불 러 올 때 이 버 전 을 선택 합 니 다.
NTS 는 None-Thread Safe 로 보통 fast cgi 방식 으로 실 행 될 때 이 버 전 을 선택 하면 더욱 좋 은 성능 을 가 집 니 다.
2000 년 10 월 20 일 에 발 표 된 첫 번 째 Windows 버 전의 PHP 3.0.17 은 모두 스 레 드 가 안전 한 버 전 으로 시작 되 었 다.이것 은 Linux/Unix 시스템 이 다 중 프로 세 스 를 사용 하 는 작업 방식 과 달리 Windows 시스템 은 다 중 스 레 드 를 사용 하 는 작업 방식 이기 때문이다.IIS 에서 PHP 를 CGI 로 실행 하면 매우 느 릴 수 있 습 니 다.이것 은 CGI 모드 가 다 중 스 레 드 가 아 닌 다 중 프로 세 스 를 기반 으로 하기 때 문 입 니 다.일반적으로 우 리 는 PHP 를 ISAPI 방식 으로 실행 하도록 설정 합 니 다.ISAPI 는 다 중 스 레 드 방식 으로 훨씬 빠 릅 니 다.그러나 문제 가 하나 있 습 니 다.많은 PHP 확장 은 Linux/Unix 의 다 중 프로 세 스 사상 으로 개 발 됩 니 다.이러한 확장 은 ISAPI 방식 으로 실 행 될 때 오류 가 발생 하여 IIS 를 무 너 뜨 립 니 다.따라서 IIS 에서 CGI 모드 가 야 말로 PHP 가 실행 되 는 가장 안전 한 방식 이지 만,CGI 모드 는 모든 HTTP 요청 에 대해 PHP 환경 전 체 를 다시 불 러 오고 마 운 트 해제 해 야 하기 때문에 그 소모 가 매우 크다.
마이크로소프트 는 IIS 에서 PHP 의 효율 과 안전 을 함께 고려 하기 위해 FastCGI 솔 루 션 을 제시 했다.FastCGI 는 새로운 요청 이 아 닌 PHP 프로 세 스 를 반복 적 으로 이용 할 수 있 습 니 다.동시에 FastCGI 도 몇 개의 프로 세 스 를 동시에 실행 할 수 있 습 니 다.이렇게 하면 CGI 프로 세 스 모드 의 소모 가 너무 큰 문 제 를 해결 할 뿐만 아니 라 CGI 프로 세 스 모드 를 이용 하여 라인 보안 문제 가 존재 하지 않 는 다 는 장점 을 가진다.
따라서 ISAPI 방식 으로 PHP 를 실행 하려 면 Thread Safe(스 레 드 보안)버 전 을 사용 해 야 합 니 다.FastCGI 모드 로 PHP 를 실행 하면 스 레 드 보안 검 사 를 할 필요 가 없습니다.None Thread Safe(NTS,비 스 레 드 보안)버 전 으로 효율 을 높 일 수 있 습 니 다.
64 비트 와 32 비트.
당신 의 시스템 은 64 명 이면 64 명,32 명 이면 32 명 입 니 다.설명 하지 않 습 니 다.신 형. 
미래.
솔직히 미래 는 PHP 5.4 이상 을 사용 하 는 사람들 에 게 속한다.업 그 레이 드 를 유지 하고 언어의 새로운 특성 과 진전 을 정기 적 으로 추적 하 는 것 은 우리 의 일상적인 업무 의 일부분 이다.만약 당신 이 이미 뒤떨어 졌 다 면,나 는 당신 이 업그레이드 계획 을 시작 하여 비교적 새로운 버 전 으로 업그레이드 하 는 것 을 강력 히 건의 합 니 다.노력 은 가치 가 있 는 것 이다.왜냐하면 절 차 는 오 랜 세월 운행 되 기 때문이다.