성능
Symfony는 매우 빠릅니다. 물론 속도가 정말로 필요하다면 Symfony를 더 빠르게 만들 수 있는 방법이 많이 있습니다. 이 장에서는 Symfony 프로그램 속도를 높이는 몇 가지 방법을 살펴보겠습니다.
바이트 코드 캐시 사용(OPcache 등) ¶
성능 향상을 위해 가장 먼저 해야 할 일은 "바이트 코드 캐시"를 사용하는 것입니다. 이러한 캐시는 컴파일된 PHP 파일을 저장하여 요청할 때마다 다시 컴파일되는 것을 방지합니다.
사용 가능한 바이트 코드 캐시가 많으며 그 중 일부는 오픈 소스입니다. PHP 5.5부터 PHP에는 OPcache가 내장되어 있습니다. 이전 버전에서 가장 널리 사용되는 바이트 코드 캐시는 APC입니다.
바이트 코드 캐시를 사용하면 모든 장점이 있고 단점이 없습니다. Symfony는 "이러한 유형의 환경에서 매우 뛰어난 성능을 발휘"하도록 제작되었습니다.
소스 파일의 변경 사항 모니터링 ¶
대부분의 바이트 코드 캐시는 소스 파일의 변경 사항을 모니터링합니다. 이렇게 하면 파일 소스 코드가 변경되면 바이트 코드가 자동으로 컴파일됩니다. 이는 매우 편리하지만 약간 과부하가 걸립니다.
따라서 일부 바이트 코드 캐시는 이러한 검사를 해제하는 옵션을 제공합니다. 예를 들어, APC에서 검사를 끄려면 php.ini 구성 파일에 직접 apc.stat=0을 추가하세요. apc.stat=0 到你的 php.ini 配置文件中。
当关闭这些检查时，将由服务器管理员来负责“确保缓存在任何源文件发生改变时被清除”。否则，你的更新将不会在程序中被看到。
同理，byte code缓存必须在部署程序时被清除 (例如，使用APC时通过调用 apc_clear_cache() PHP函数，以及，使用Opcache时通过 opcache_reset())。
在PHP中，命令行以及web进程并不共享相同的OPcache。这意味着你不能通过执行终端中的某些命令来清除web服务器上的OPcache。你可以重启服务器或者通过web服务器调用 apc_clear_cache() 或 opcache_reset()
apc_clear_cache() PHP 함수를 호출하고 opcache_reset())을 사용할 때. 🎜PHP에서는 명령줄과 웹 프로세스가 동일한 OPcache를 공유하지 않습니다. 이는 터미널에서 특정 명령을 실행하여 웹 서버에서 OPcache를 지울 수 없음을 의미합니다. 서버를 다시 시작하거나 웹 서버를 통해 apc_clear_cache() 또는 opcache_reset() 함수를 호출할 수 있습니다(예: 실행 시) 웹 스크립트) 그들은). 🎜🎜🎜
Symfony에서 사용하는 모든 파일 최적화 ¶
기본적으로 PHP의 OPcache는 바이트 코드 캐시에 2000개의 파일을 저장합니다. 이 숫자는 일반 Symfony 애플리케이션에 비해 여전히 너무 작으므로 opcache.max_accelerated_files 구성 옵션을 더 높은 값으로 설정해야 합니다.
; php.iniopcache.max_accelerated_files = 20000
Configure PHP realpath 캐시 # 🎜🎜 #¶
realpath_cache_size의 16K를 설정하는데, 이는 Symfony에 비해 너무 작습니다. 이 값을 4096K 이상으로 업데이트하세요. 또한 캐시 경로는 기본적으로 120초 동안만 저장됩니다. 또한 realpath_cache_ttl 옵션을 통해 이 값을 업데이트하는 것도 고려해 보세요. #🎜🎜 #; php.ini realpath_cache_size=4096K realpath_cache_ttl=600
Composer의 클래스 매핑 기능 사용 ¶
16K 的 realpath_cache_size，这对Symfony来说实在太小。将这个值更新到至少 4096K。此外，缓存路径默认时只保存 120 秒，同样考虑通过 realpath_cache_ttl 选项来更新此值:1
使用Composer的类映射功能 ¶
默认时，Symfony标准版使用的是 autoload.php 文件中的Composer自动加载器（autoloader）。这个加载器很容易使用，因为它自动寻找任何“你在已注册目录中放置了”的新类。
不幸的是，这有使用成本，因为类加载器要遍历全部已配置的命名空间，以便找到一个特定文件，发起 file_exists() 的调用直到最终找到它想要的文件为止。
最简单的方案是告诉Composer构建一个优化过的"class map"（类映射），这是一个所有类所在位置的大数组，并且存放在 vendor/composer/autoload_classmap.php기본적으로 Symfony 표준 버전은 파일에서 autoload.php
file_exists() 마침내 원하는 파일을 찾을 때까지. 가장 간단한 해결책은 Composer에게 모든 클래스 위치의 대규모 배열이며 vendor/composer/autoload_classmap.php. 이 클래스 맵은 명령줄에서 생성할 수 있으며 배포 프로세스의 일부가 될 수 있습니다. $ composer dump-autoload --optimize --no-dev --classmap-authoritative
#🎜🎜##🎜🎜##🎜🎜##🎜🎜#--optimize--optimize- 剥离你程序中的每一个兼容PSR-0 和 PSR-4 的类。
--no-dev- 排除那些你只在开发环境下使用的类(如tests)。
--classmap-authoritative- 防止Composer在文件系统中寻找那些没有出现在类映射中的类。
用APC缓存Autoloader ¶
另一个方案是在类被首次定位之再来缓存其位置。Symfony自带了一个类 - ApcClassLoader - 专门用来干这个。要使用它，只需适配你的前端控制器文件。如果你使用了标准版框架，可作出以下改变:
// app.php// ...
use Symfony\Component\ClassLoader\ApcClassLoader;
$loader = require __DIR__.'/../app/autoload.php';include_once __DIR__.'/../app/bootstrap.php.cache';
// Use APC for autoloading to improve performance
// Change 'sf2' by the prefix you want in order
// to prevent key conflict with another application
// 使用APC自动加载以提升性能，改变'sf2'为你希望的前缀，
// 以防止同其他程序发生key冲突$loader = new ApcClassLoader('sf2', $loader);$loader->register(true);
// ...更多细节，参考 对Class Loader进行缓存 一文。
当使用APC autoloader时，如果你添加了新类，它们将被自动找到，所有东西的运作一如往常（即，并无必要“清除”缓存）。但是，如果你改变了某个特定命名空间或前缀的位置，你就需要flush你的APC缓存。否则，自动加载器仍将在那个命名空间的旧位置来寻找所有的类。
使用Bootstrap文件 ¶
为确保弹性优化和代码复用，Symfony程序利用了多样化的类和第三方组件。但在每次请求中从分散位置加载全部这些类会导致一定程度的过载。为减轻负责，Symfony提供了一个脚本来生成一个被称为 bootstrap file 文件，考量的是在单一文件中加载多个类定义。通过包容这个文件 (它包含了各种核心类的拷贝)，Symfony不再需要包容任何“含有那些类”的源文件。这将减少不少的硬盘吞吐（disc IO）。
如果你正在使用Symfony标准版，那你应该已经使用了这个bootstrap启动文件。为确保使用，打开你的前端控制器（通常是 app.php 프로그램에서 모든 PSR-0 호환 및 PSR 제거 -4 수업.
--no-dev개발 환경(예: 테스트)에서만 사용하는 클래스를 제외합니다. --classmap-authoritativeComposer가 클래스에 표시되지 않는 파일 시스템의 클래스를 찾지 못하도록 방지 지도. APC를 사용하여 오토로더 캐시 ¶
또 다른 해결 방법은 다음과 같습니다. 클래스를 처음 찾은 후 클래스 위치를 캐시합니다. Symfony는 클래스와 함께 제공됩니다 - ApcClassLoader - 특히 이 작업을 수행하는 데 사용됩니다. 이를 사용하려면 전면 컨트롤러 파일을 조정하면 됩니다. 표준 버전의 프레임워크를 사용하는 경우 다음과 같이 변경할 수 있습니다.
1
자세한 내용은 올바른 클래스 로더 캐싱 기사.
APC 오토로더를 사용할 때 새 클래스를 추가하면 자동으로 검색됩니다. 모든 것이 평소대로 작동합니다(즉, 캐시를 "지울" 필요가 없습니다). 그러나 특정 네임스페이스나 접두사의 위치를 변경하는 경우 APC 캐시를 플러시해야 합니다. 그렇지 않으면 오토로더는 여전히 해당 네임스페이스의 이전 위치에서 모든 클래스를 찾습니다.
부트스트랩 파일 사용 ¶
유연한 최적화와 코드 재사용을 보장하는 Symfony 프로그램은 다양한 클래스와 타사 구성 요소를 사용합니다. 그러나 요청이 있을 때마다 분산된 위치에서 이러한 모든 클래스를 로드하면 일정 수준의 과부하가 발생합니다. 책임을 줄이기 위해 Symfony는 파일 파일의 경우 단일 파일에 여러 클래스 정의를 로드하는 것을 고려합니다. 다양한 핵심 클래스의 복사본이 포함된 이 파일을 포함하면 Symfony는 더 이상 해당 클래스가 포함된 소스 파일을 포함할 필요가 없습니다. 이렇게 하면 하드 디스크 처리량(디스크 IO)이 많이 줄어듭니다.
Symfony Standard Edition을 사용하는 경우 이 부트스트랩 시작 파일을 사용해야 합니다. 작동하는지 확인하려면 전면 컨트롤러(일반적으로 app.php)를 열고 다음 코드 줄이 있는지 확인하세요.
부트스트랩 파일을 사용할 때 두 가지 단점이 있습니다.
- 이 파일은 원본 리소스가 변경되면 다시 생성됩니다(예: Symfony의 src 코드 또는 공급업체 타사 클래스 라이브러리를 업데이트합니다.);
- 디버깅할 때 개발자는 부트스트랩 파일에 중단점을 설정해야 합니다.
Symfony 표준 버전을 사용하는 경우 공급업체 클래스 라이브러리 이후 composer install 명령을 통해 시작 파일이 자동으로 설치됩니다. Rebuild (번역: Composer.json 등의 포스트 스크립트를 말하며 수동으로 실행할 수도 있음) composer install 命令来自动重建（译注：指composer.json中的post脚本等，也可手动执行）
Bootstrap文件和Byte Code缓存 ¶
即便使用了一种byte code缓存，在使用bootstrap文件时仍会提高性能，这是因为需要监控“发生改变”的文件变少了。当然这个功能如果在byte code cache中被关闭的话 (即在APC中设置 apc.stat=0
부트스트랩 파일 및 바이트 코드 캐시 ¶
바이트 코드 캐시를 사용하더라도 "변경 사항을 모니터링할 파일이 적기 때문에 부트스트랩 파일을 사용할 때 성능은 여전히 향상됩니다. ". 물론, 바이트코드 캐시에서 이 기능이 꺼져 있다면(즉, APC에서 apc.stat=0 설정), 부트스트랩 파일을 사용할 이유가 없을 것이다. . #🎜🎜#
