1) PHP7은 PHP5.6보다 두 배 빠릅니다.2) JIT - Just in Time 컴파일러(Just-in-time 편집기)
Just In Time(Just-in-time 컴파일)은 머신용 바이트코드를 컴파일하는 것을 의미하는 소프트웨어 최적화 기술입니다. 런타임 코드에서. 직관적인 관점에서 볼 때 기계어 코드는 컴퓨터가 직접 인식하고 실행할 수 있다고 생각하기 쉬우며, Opcode를 하나씩 읽어서 실행하는 것이 Zend보다 효율적입니다. 그 중 HHVM(HipHop Virtual Machine, HHVM은 페이스북 오픈소스 PHP 가상머신)은 JIT를 사용하는데, 이는 PHP 성능 테스트를 몇 배로 향상시키며 충격적인 테스트 결과를 내놓고 있어 직관적으로 JIT가 강력하다고 생각하게 만든다. 돌을 금으로 바꾸는 기술.
사실 2013년에 Niao 형제와 Dmitry(PHP 언어 핵심 개발자 중 한 명)가 PHP5.5 버전에서 JIT를 시도한 적이 있습니다(출시되지 않았습니다). PHP5.5의 원래 실행 프로세스는 어휘 및 구문 분석(형식은 어셈블리와 다소 유사)을 통해 PHP 코드를 opcode 바이트코드로 컴파일하는 것입니다. 그런 다음 Zend 엔진은 이러한 opcode 명령어를 읽고 하나씩 구문 분석하고 실행합니다.
그리고 opcode 링크 뒤에 유형 추론(TypeInf)을 도입한 다음 실행하기 전에 JIT를 통해 ByteCode를 생성했습니다.
그래서 벤치마크(테스트 프로그램)에서 흥미로운 결과를 얻었습니다. JIT를 구현한 후 PHP5.5에 비해 성능이 8배 향상되었습니다. 하지만 이 최적화를 실제 프로젝트인 워드프레스(오픈소스 블로그 프로젝트)에 적용해 보니 성능 향상이 거의 보이지 않아 아리송한 테스트 결과를 얻었습니다.
그래서 그들은 Linux에서 프로파일 유형의 도구를 사용하여 프로그램 실행의 CPU 시간 소비를 분석했습니다.
WordPress 100회 실행 시 CPU 소모 분포:
CPU 시간의 21%가 메모리 관리에 사용됩니다.
CPU 시간의 12%는 주로 PHP 배열을 추가, 삭제, 수정 및 확인하는 해시 테이블 작업에 소비됩니다.
30%의 CPU 시간은 strlen과 같은 내장 함수에 사용됩니다.
25%의 CPU 시간이 VM(Zend Engine)에서 소비됩니다.
분석 후 두 가지 결론이 도출되었습니다.
(1) JIT에서 생성된 바이트코드가 너무 크면 CPU 캐시 적중률(CPU Cache Miss)이 감소합니다.
in PHP5 .5 코드에서는 명확한 유형 정의가 없으므로 유형 추론에만 의존할 수 있습니다. 추론 가능한 변수 유형을 최대한 정의한 후 유형 추론과 결합하여 이 유형이 아닌 분기 코드를 제거하여 직접 실행 가능한 기계어 코드를 생성합니다. 하지만 타입 추론은 모든 타입을 유추할 수는 없습니다. 워드프레스에서는 유추할 수 있는 타입 정보가 30% 미만으로 제한되어 있으며, 축소할 수 있는 브랜치 코드도 제한되어 있습니다. 결과적으로 JIT 이후에는 기계어 코드가 직접 생성되는데, 생성된 ByteCode가 너무 커서 결국 CPU 캐시 적중(CPU Cache Miss)이 크게 감소하게 됩니다.
CPU 캐시 적중이란 CPU가 명령을 읽고 실행하는 과정에서 CPU의 첫 번째 수준 캐시(L1)에서 필요한 데이터를 읽을 수 없는 경우 두 번째 수준 캐시까지 계속해서 아래쪽으로 검색해야 함을 의미합니다. 1단계 캐시(L2)와 3단계 캐시(L3)는 결국 메모리 영역에서 필요한 명령 데이터를 찾으려고 시도하며, 메모리와 CPU 캐시 간의 읽기 시간 차이는 100배에 달할 수 있습니다. 따라서 ByteCode가 너무 크고, 실행되는 명령의 개수가 너무 많으면 다중 레벨 캐시는 그렇게 많은 데이터를 수용할 수 없으며, 일부 명령은 메모리 영역에 저장되어야 합니다.
CPU의 모든 레벨에서 캐시 크기도 제한되어 있습니다. 다음 그림은 Intel i7 920의 구성 정보입니다.
따라서 CPU 캐시 적중률이 감소합니다. 심각한 시간 소모가 발생합니다. 한편, JIT로 인한 성능 향상도 JIT로 인해 상쇄됩니다.
JIT를 통해 VM의 오버헤드를 줄이는 동시에 명령어 최적화를 통해 메모리 할당 횟수를 줄일 수 있어 메모리 관리 개발을 간접적으로 줄일 수 있습니다. 그러나 실제 WordPress 프로젝트의 경우 CPU 시간의 25%만이 VM에 소비되며, 주요 문제와 병목 현상은 실제로 VM에 있지 않습니다. 따라서 이 버전의 PHP7 기능에는 JIT 최적화 계획이 포함되지 않았습니다. 하지만 이후 버전에서는 구현될 가능성이 높으니 기대해볼만한 가치가 있습니다.
(2) JIT 성능 개선 효과는 프로젝트의 실제 병목 현상에 따라 달라집니다.
JIT는 벤치마크에서 코드의 양이 상대적으로 적고 최종 생성되는 ByteCode도 획기적으로 개선되었습니다. 상대적으로 작습니다. 동시에 주요 오버헤드는 VM에 있습니다. 그러나 실제 WordPress 프로젝트에서는 WordPress의 코드량이 벤치마크에 비해 훨씬 크기 때문에 뚜렷한 성능 향상이 없습니다. ByteCode는 오버헤드가 너무 커서 결국 개선되지 않습니다.
프로젝트 유형에 따라 CPU 오버헤드 비율이 다르며 결과도 다릅니다. 실제 프로젝트가 없는 성능 테스트는 그다지 대표적이지 않습니다.
3) Zval의 변경 사항
실제로 PHP에서 다양한 유형의 변수를 저장하는 실제 저장 매체는 Zval이며 이는 관용과 관용이 특징입니다. 본질적으로 C언어로 구현한 구조체(struct)이다. PHP를 작성하는 학생들의 경우 대략적으로 배열과 유사한 것으로 이해할 수 있습니다.
PHP5의 Zval, 메모리 차지 24바이트:
PHP7의 Zval, 메모리 차지 16바이트:
Zval이 24바이트에서 16워드로 줄었습니다. , 왜 감소하고 있나요? 여기에 C에 익숙하지 않은 학생들의 이해를 돕기 위해 약간의 C 언어 기초를 추가해야 합니다. struct와 Union(union)에는 약간의 차이가 있습니다. Struct의 각 멤버 변수는 독립적인 메모리 공간을 차지하는 반면, Union의 멤버 변수는 메모리 공간을 공유합니다(즉, 멤버 변수 중 하나가 수정되면 public space는 수정 후에는 다른 멤버 변수에 대한 기록이 없습니다. 따라서 멤버 변수가 훨씬 많아 보이지만 실제로 차지하는 메모리 공간은 줄어들었다.
또한 분명히 변경된 기능도 있으며 일부 단순 유형은 더 이상 참조를 사용하지 않습니다.
Zval 구조도:
그림의 Zval은 2개의 64비트로 구성됩니다(1바이트 = 8비트, 비트는 "비트"). 변수 유형이 long 또는 bealoon이고 길이가 64비트를 초과하지 않는 경우. 직접 값에 저장되면 다음 참조가 없습니다. 변수 유형이 64비트를 초과하는 배열, 객체, 문자열 등인 경우 저장되는 값은 실제 저장 구조 주소를 가리키는 포인터입니다.
간단한 변수 유형의 경우 Zval 저장소는 매우 간단하고 효율적입니다.
참조가 필요하지 않은 유형: NULL, Boolean, Long, Double
참조가 필요한 유형: String, Array, Object, Resource, Reference
4) 내부 유형 zend_string
Zend_string 실제로 문자열을 저장하는 구조체입니다. 실제 내용은 val(char, 문자형)에 저장되며, val은 길이가 1인 char 배열입니다(멤버 변수 점유에 편리함).
구조체의 마지막 멤버 변수는 char* 대신 char 배열을 사용합니다. 다음은 CPU의 캐시 누락을 줄일 수 있는 작은 최적화 트릭입니다.
char 배열을 사용하는 경우 위 구조의 메모리에 malloc을 적용할 때 동일한 영역에 적용되며, 일반적으로 길이는 sizeof(_zend_string) + 실제 char 저장 공간입니다. 그러나 char*를 사용하면 이 위치에 저장되는 것은 포인터일 뿐이고, 실제 저장되는 곳은 또 다른 독립된 메모리 영역이다.
char[1] 및 char*를 사용한 메모리 할당 비교:
논리 구현의 관점에서 볼 때 둘 사이에는 실제로 큰 차이가 없으며 효과도 매우 유사합니다. 실제로 이러한 메모리 블록이 CPU에 로드되면 매우 다르게 보입니다. 전자는 지속적으로 함께 할당된 동일한 메모리 조각이기 때문에 일반적으로 CPU가 읽을 때 함께 얻을 수 있습니다(같은 레벨 캐시에 있기 때문입니다). 후자는 두 메모리의 데이터를 포함하기 때문에 CPU가 첫 번째 메모리를 읽을 때 두 번째 메모리 데이터가 동일한 레벨 캐시에 없을 가능성이 높으므로 CPU는 L2(보조 캐시) 아래를 검색해야 합니다. 원하는 두 번째 메모리 데이터가 메모리 영역에서 발견되었습니다. 이로 인해 CPU Cache Miss가 발생하며 둘 사이의 시간 소모 차이는 최대 100배에 이를 수 있습니다.
또한, 참조 할당을 사용하여 문자열을 복사할 때 zend_string은 메모리 복사를 피할 수 있습니다.
5) PHP 배열 변경 사항(HashTable 및 Zend Array)
PHP 프로그램을 작성하는 과정에서 가장 자주 사용되는 유형은 배열이며, PHP5 배열은 HashTable을 사용하여 구현됩니다. 대략적으로 요약하면, 이중 연결 목록을 지원하는 HashTable입니다. 배열 키를 통해 요소에 액세스하는 해시 매핑을 지원할 뿐만 아니라 foreach를 통해 이중 연결 목록에 액세스하여 배열 요소를 순회할 수도 있습니다.
PHP5용 해시 테이블:
이 그림은 다양한 포인터가 뛰어다니는 모습으로 매우 복잡해 보입니다. 키 값을 통해 요소의 콘텐츠에 액세스할 때 올바른 콘텐츠를 찾기 위해 포인터를 세 번 점프해야 하는 경우도 있습니다. 가장 중요한 점은 이러한 배열 요소의 저장이 서로 다른 메모리 영역에 분산되어 있다는 것입니다. 마찬가지로 CPU가 읽을 때 동일한 수준의 캐시에 있지 않을 가능성이 높기 때문에 CPU는 하위 수준의 캐시나 심지어 메모리 영역까지 검색해야 하므로 CPU 캐시 적중률이 감소하게 됩니다. 소비 시간이 늘어납니다.
PHP7용 Zend 배열(PPT 스크린샷):
새 버전의 배열 구조는 매우 간단하고 눈길을 끕니다. 가장 큰 특징은 전체 배열 요소와 해시 매핑 테이블이 모두 함께 연결되어 동일한 메모리에 할당된다는 점입니다. 단순한 유형의 정수 배열을 순회하는 경우 배열 요소(Bucket) 자체가 동일한 메모리에 지속적으로 할당되고 배열 요소의 zval이 내부적으로 정수 요소를 저장하고 저장되므로 효율성이 매우 빠릅니다. 포인터 외부 링크도 있고 모든 데이터는 현재 메모리 영역에 저장됩니다. 물론 가장 중요한 것은 CPU Cache Miss(CPU 캐시 적중률 감소)를 방지할 수 있다는 점입니다.
Zend 배열 변경 사항:
(1) 배열 값의 기본값은 zval입니다.
(2) HashTable의 크기가 72바이트에서 56바이트로 22% 감소했습니다.
(3) 버킷 크기가 72바이트에서 32바이트로 50% 감소했습니다.
(4) 배열 요소 버킷의 메모리 공간이 함께 할당됩니다.
(5) 배열 요소(Bucket.key)의 키는 zend_string을 가리킵니다.
(6) 배열 요소의 값은 버킷에 포함됩니다.
(7) CPU 캐시 누락을 줄입니다.
6). 함수 호출 규칙
PHP7은 매개변수 전달 프로세스를 최적화하여 일부 명령을 줄이고 실행 효율성을 향상시킵니다.
PHP5의 함수 호출 메커니즘(PPT의 스크린샷):
그림에서 vm 스택의 send_val 및 recv 매개변수 명령은 동일합니다. PHP7은 이러한 두 중복을 줄여 함수 호출 메커니즘의 기본 최적화를 달성합니다.
PHP7의 함수 호출 메커니즘(PPT 스크린샷):
7) 컴파일러는 매크로 정의와 인라인 함수(인라인)를 통해 작업의 일부를 미리 완료할 수 있습니다.
C 언어의 매크로 정의는 전처리 단계(컴파일 단계)에서 실행되어 작업의 일부를 미리 완료합니다. 프로그램이 실행될 때 메모리를 할당할 필요가 없습니다. 스택 푸시 없이 함수와 유사한 기능을 구현할 수 있습니다. 함수 호출의 오버헤드를 팝하면 효율성이 높아집니다. 인라인 함수의 경우에도 마찬가지입니다. 전처리 단계에서는 프로그램의 함수가 함수 본문으로 대체됩니다. 여기서 실제 실행되는 프로그램이 실행되면 함수 호출에 따른 오버헤드가 발생하지 않습니다.
PHP7은 이 부분에서 많은 최적화를 했고, 실행 단계에서 수행해야 하는 많은 작업을 컴파일 단계에 넣었습니다. 예를 들어, 매개변수 유형 판단(Parameters Parsing)은 여기에 포함된 모든 것이 고정된 문자 상수이기 때문에 컴파일 단계에서 완료될 수 있어 후속 실행 효율성이 향상됩니다.
예를 들어 아래 그림에서는 매개변수 유형을 전달하는 방식이 왼쪽의 쓰기 방식에서 오른쪽의 매크로 쓰기 방식으로 최적화되어 있습니다.
PHP 7.0.0 RC 2 새로운 기능 출시
- 향상된 성능: PHP 7은 PHP 5.6보다 최대 2배 빠릅니다. 성능은 php5.6의 2배
- 일관적인 64비트 지원으로 64비트 지원 , 다양한 플랫폼에서 정수 길이를 통합하고 문자열과 파일 업로드 모두 2GB 이상을 지원합니다.
- 많은 치명적인 오류가 이제 예외입니다. 더 많은 오류 오류를 예외로 처리할 수 있습니다.
- 오래되고 지원되지 않는 SAPI 및 확장 제거
- null 병합 연산자(?? ) null 결합 비교 연산자(??)
- Combined 비교 연산자(<=>) 결합 비교 연산자(<=>)
- 반환 유형 선언 반환 유형 선언
- 스칼라 유형 선언 스칼라 유형 선언
- 익명 클래스 익명 클래스
구체적인 예:
더 많은 오류를 포착할 수 있습니다. 예외
PHP7은 전역 발생 가능 인터페이스, 원래 예외 및 일부 오류가 모두 이 인터페이스를 구현하고 다음의 상속 구조를 구현합니다. 예외는 인터페이스 형식으로 정의됩니다. 결과적으로 PHP7에서는 더 많은 오류가 포착 가능한 예외가 되어 개발자에게 반환됩니다. 포착되지 않으면 오류가 되어 프로그램 내에서 처리할 수 있습니다. 이러한 포착 가능한 오류는 일반적으로 존재하지 않는 함수와 같이 프로그램에 치명적인 해를 끼치지 않는 오류입니다. PHP7은 개발자의 처리를 더욱 용이하게 하고 개발자가 프로그램을 더 잘 제어할 수 있게 해줍니다. 기본적으로 오류는 프로그램을 직접 중단시키고 PHP7은 이를 캡처하고 처리하는 기능을 제공하여 프로그램이 계속 실행되도록 하여 프로그래머에게 보다 유연한 선택을 제공합니다.
예를 들어, 존재 여부를 확신할 수 없는 함수를 실행하기 위해 PHP5 호환 방법은 함수 호출 전에 function_exist 판단을 추가하는 반면, PHP7은 Exception을 잡는 처리 방법을 지원합니다.
아래 사진과 같이
AST는 PHP 컴파일 프로세스에서 미들웨어 역할을 하며, 인터프리터에서 직접 opcode를 내보내는 원래 방식을 대체하고, 인터프리터(파서)와 컴파일러(컴파일러)를 분리하여 일부 해킹 코드를 줄일 수 있습니다. 동시에 구현을 더 쉽게 이해하고 유지 관리할 수 있습니다.
PHP5:
PHP7:
추가 AST 정보: https://wiki.php.net/rfc/abstract_syntax_tree
네이티브 TLS(네이티브 스레드 로컬 스토리지, 네이티브 스레드 로컬 스토리지)
PHP는 멀티 스레드 모드(예: 멀티 스레드인 웹 서버 Apache의 Waker 및 이벤트 모드)에서 "스레드 안전성"(TS, Thread Safe) 문제를 해결해야 합니다. 스레드가 메모리를 공유하기 때문입니다. 따라서 각 스레드 자체는 다른 스레드와의 상호 오염을 피하기 위해 자신의 개인 데이터를 저장하기 위해 어떤 방식으로든 개인 공간을 구축해야 합니다. PHP5에서 채택한 방법은 대규모 전역 배열을 유지하고 각 스레드에 독립적인 저장 공간을 할당하는 것입니다. 스레드는 자체 키 값을 통해 이 전역 데이터 그룹에 액세스합니다.
그리고 이 고유 키 값은 PHP5에서 전역 변수를 사용해야 하는 모든 함수에 전달되어야 합니다. PHP7은 이 전달 방법이 친숙하지 않고 몇 가지 문제가 있다고 생각합니다. 따라서 전역 스레드별 변수를 사용하여 이 키 값을 저장해 보세요.
관련 네이티브 TLS 문제: https://wiki.php.net/rfc/native-tls
결합 비교 연산자(<=>) 결합 비교 연산자(<=>)
// PHP 7之前的写法：比较两个数的大小
function order_func($a, $b) {
return ($a < $b) ? -1 : (($a > $b) ? 1 : 0);
}
// PHP新增的操作符 <=>,perfect
function order_func($a, $b) {
return $a <=> $b;
}로그인 후 복사
반환 유형 선언 반환 유형 선언 및 스칼라 유형 선언
PHP 언어의 매우 중요한 기능은 "약한 타이핑"입니다. 이로 인해 PHP 프로그램을 매우 쉽게 작성할 수 있으며, PHP를 처음 접하는 초보자도 빠르게 시작되었지만 몇 가지 논란이 있습니다. 변수 유형 정의를 지원하는 것은 혁신적인 변화라고 할 수 있습니다. PHP는 선택적인 방식으로 유형 정의를 지원하기 시작했습니다. 또한, 전환 명령 선언(strict_type=1)도 도입되었습니다. 이 명령이 활성화되면 현재 파일의 프로그램이 엄격한 함수 매개변수 전송 유형 및 반환 유형을 따르도록 합니다.
예를 들어 추가 함수와 유형 정의를 다음과 같이 작성할 수 있습니다.
필수 유형 전환 명령에 협조하면 다음과 같이 될 수 있습니다.
strict_type이 켜져 있지 않으면 PHP는 이를 다음으로 변환하도록 돕습니다. 필수 유형을 설정하고 켠 후에는 PHP를 변경하고 더 이상 유형 변환을 수행하지 않으며 유형이 일치하지 않으면 오류가 발생합니다. 이는 "강력한 형식의" 언어를 좋아하는 학생들에게 좋은 소식입니다.
자세한 소개: https://wiki.php.net/rfc/scalar_type_hints_v5 PHP7 스칼라 유형 선언 RFC
PHP5.6에서 PHP7로 직접 점프해야 하는 이유(우리가 필요한 이유 PHP 7로 건너뛰기)
다음 주요 PHP 버전에 버전 6을 재사용하면 안 되는 데에는 몇 가지 이유가 있습니다.
- 무엇보다도 PHP 6은 이미 존재했고 완전히 다른 것이었습니다. 십진법(또는 더 정확하게는 우리가 가지고 있는 무한한 숫자 공급)을 사용하면 버전을 쉽게 건너뛸 수 있으며 향후 버전에 더 많은 것이 남아 있습니다.
- 다른 PHP 6이 일반 출시에 도달하지 못한 것은 사실이지만, 그것은 여전히 php.net이 수행한 매우 널리 게시되고 잘 알려진 프로젝트였으며 현재 논의 중인 버전과 전혀 공유하지 않을 것입니다. PHP 6이 무엇인지 아는 사람이라면 누구나 이 새 버전의 내용과 기능(본질적으로는 모두 유니코드에 관한 것임)에 대해 강한 오해를 갖고 있을 것입니다.
- PHP 6, 원본 PHP 6에 대해서는 많은 PHP 컨퍼런스에서 자세히 논의되었습니다. 기능과 동작에 대한 자세한 설명('사악한' 책 저자가 아닌 php.net 개발자에 의해)을 포함하여 사용자에게 완료된 거래로 가르쳐졌습니다.
- PHP 6은 내부 커뮤니티뿐만 아니라 전 세계적으로 널리 알려졌습니다. PHP 커뮤니티 전체. 이는 대부분은 아니더라도 많은 PHP 커뮤니티 구성원이 알고 있는 주목할만한 프로젝트였습니다.
- 웹에는 원본 PHP 6에 대한 많은 PHP 6 정보가 있습니다. 책은 문제의 가장 작은 부분입니다.
- '우리는 왜 7로 건너뛴 걸까요?'라는 '상식 질문'과 달리, 버전 6을 재사용하면 완전히 다른 두 가지에 대한 충분한 정보로 인해 사람들의 마음에 실제 혼란을 불러일으킬 가능성이 높습니다. 완전히 동일한 이름을 가진 완전히 다른 기능 세트를 가진 버전입니다.
- 버전을 건너뛰는 것은 오픈 소스 프로젝트와 상용 제품 모두에서 전례가 없거나 드문 일이 아닙니다. MariaDB는 혼동을 피하기 위해 버전 10.0까지 올라갔고, Netscape Communicator는 버전 5.0을 건너뛰고 6.0으로, Symantec은 버전 13을 건너뛰었습니다. 각각 건너뛰는 이유는 서로 다르지만 공통점은 버전 건너뛰기라는 것입니다. 별거 아닙니다.
- 버전 6은 일반적으로 동적 언어 세계의 실패와 관련이 있습니다. PHP 6은 실패했습니다. Perl 6은 실패했습니다. 이는 실제로 동적 언어 세계 외부에서도 오류와 관련이 있습니다. MySQL 6도 존재했지만 출시되지 않았습니다. 버전 6을 실패로 인식하는 것(미신이 아니라 실제 사실('Vista'라는 단어와 실패를 연관시키는 것과 유사))은 이 PHP 버전에 나쁜 영향을 미칠 것입니다.
- 6의 경우는 대부분 다음과 같습니다. 위의 일부 사항에 대한 반박이지만 버전 6을 건너뛰면 안되는 이유에 대한 강력한 사례는 제공하지 않습니다. PHP 7을 사용하는 경우 최악의 시나리오는 불필요하게 버전을 건너뛰는 것입니다. 우리는 향후 사용을 위해 여전히 무제한의 주요 버전을 보유하고 있습니다. 그러나 7 대신 6을 선택하는 경우 최악의 시나리오는 커뮤니티에 광범위한 혼란과 이 버전에 대한 잠재적인 부정적인 인식입니다.
지원되는 SAPI
지원되지 않는 확장 프로그램(아직 아님)
-
interbase
mssql
oci8
-
pdo_dblib
pdo_oci
sybase_ct
PHP7 VS PHP5.6
1. Opcache를 활성화하는 것을 잊지 마세요
Opcache가 활성화되어 있지 않더라도 PHP7은 PHP-5.6보다 빠르기 때문에 이전 테스트 기간 동안 누군가가 활성화하지 않았습니다. Opcache 것. Opcache를 활성화하는 것은 매우 간단합니다. php.ini 구성 파일을 추가하기만 하면 됩니다:
zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1"
2. 새로운 컴파일러를 사용하세요
GCC 4.8 이상을 사용하는 것이 좋습니다. 왜냐하면 GCC 4.8 이상 PHP에서만 opline 및 Execute_data 지원을 위한 전역 등록을 활성화할 수 있기 때문입니다. 약 5% 정도의 성능 향상 (Wordpres의 QPS 관점에서 측정)
사실 GCC 4.8 이전 버전에서도 지원하지만 지원에 버그가 있는 것으로 확인되어 4.8 버전임이 틀림없습니다 또는 그 이상으로 이 특성을 활성화할 수 있습니다.
3.HugePage
PHP7을 더 빠르게 만드는 Hugepage, 먼저 시스템에서 HugePages를 활성화한 다음 Opcache의 huge_code_page s를 활성화합니다.
CentOS 6.5를 예로 들어 다음을 전달합니다.
512개의 예약된 대형 페이지 할당 메모리:
$ cat /proc/meminfo | grep Huge
AnonHuge페이지: 106496 kBHugePages_Total: 512
HugePages_Free: 504
HugePages_Rsvd: 27
HugePages_Surp: 0
Hugepage 크기: 2048 kB
그런 다음 PHP에 추가하세요. ini ：
opcache.huge_code_pages=1
이러한 방식으로 PHP는 대용량 메모리 페이지를 사용하여 자체 텍스트 세그먼트와 대용량 메모리 할당을 저장하여 TLB 누락을 줄입니다. 따라서 성능이 향상됩니다.
4. Opcache 파일 캐시 활성화
이 기능을 활성화하면 Opcache가 외부 파일에 opcode 캐시를 캐시하도록 할 수 있습니다. 성능이 크게 향상되었습니다.
php.ini에 추가:
opcache.file_cache=/tmp
이 방법으로 PHP는 일부 Opcode 바이너리 내보내기 파일을 /tmp 디렉터리에 캐시할 수 있습니다. PHP 라이프사이클 전반에 걸쳐.
5, PGO
내 이전 기사: PHP7을 더 빠르게 만들기(GCC PGO)는 또한 PHP가 WordPress와 같은 하나의 프로젝트만 제공하는 데 전념하는 경우에 대해 소개했습니다. , Drupal 또는 기타 다른 것을 사용하는 경우 PGO를 사용하여 PHP를 개선하여 특히 프로젝트 성능을 향상시킬 수 있습니다.
구체적으로 최적화 시나리오로는 wordpress 4.1을 사용했습니다. 우선 PHP를 컴파일할 때:
$ make prof-gen
그런 다음 WordPress용 프로젝트로 PHP를 교육합니다.
$ sapi/cgi/php-cgi -T 100 /home/huixinchen/local/www/htdocs/wordpress/index.php > ;/dev/null
즉, WordPress 홈페이지에서 php-cgi를 100번 실행하여 그 과정에서 일부 프로필 정보를 생성하도록 합니다.
마지막으로:
$ make prof-clean
$ make prof-use
이때 컴파일하는 PHP7은 프로젝트에 맞춰진 최고 성능의 컴파일 버전입니다.
지금은 그게 다입니다. 나중에 생각나면 더 추가하겠습니다. 누구나 시도해 볼 수 있습니다. 감사합니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
