저는 현재 PHP FPM과 함께 APC를 사용하여 수백 개의 Wordpress 사이트를 캐시하고 있습니다. 2gig 캐시를 사용하면 모든 것이 잘 작동하지만 그다지 효율적이지 않으며 캐시가 항상 최대치에 달합니다.
예를 들어 동일한 버전의 동일한 서버에 200개의 Wordpress 사이트가 모두 있으면 200개의 동일한 wp-db.php 파일을 캐시합니다.
몇 년 전 이것이 어떻게 보안 위험이 될 수 있는지에 대한 토론을 기억하는 것 같습니다. 이것이 더 이상 문제가 될지 의심스럽습니다(특히 PHP FPM의 경우). 하지만 어쨌든 모든 사이트를 제어하므로 어떤 단점보다 이점이 더 좋습니다.
최근 몇 년 동안 이것이 전혀 바뀌었습니까? 특히 새로운 기본 Zend Opcache의 경우? 심볼릭 링크와 같은 해킹은 이상적이지 않습니다. 예를 들어 500개의 사이트를 한 번에 업그레이드할 수 없으므로 때때로 심각하게 중단될 수 있습니다.
답변1
이것은 zend opcode에서 이것을 경험하지 않았기 때문에 부분적인 응답입니다.
지난번에 apc를 사용했을 때 이 기능은 버그로 여겨졌으나 결코 기능으로 보지 못했습니다 :-). php-fpm과 함께 -ed 풀을 사용 chroot하고 모든 풀이 chroot에서 동일한 상대 경로를 갖는 경우 apc에서 동일한 캐시 키를 공유합니다. 키는 전체 절대 파일 경로이고 chroot에서 이 파일 경로는 부분을 포함할 수 없습니다.~ 전에chroot.
따라서 chroot로 시도해 볼 수 있습니다. 그러나 이는 다음과 같은 몇 가지 트릭을 의미합니다.
- chroot에는 PHP에 필요한 모든 요소(임시 디렉터리, /etc/hosts, 일부 장치)가 포함되어야 합니다.
- PHP 메일은 작동하지 않으며 smtp 모드에서 사용해야 합니다.
- 일부 파일은 캐시에서 제외되어야 하며 설정이 포함된 모든 파일은 웹 사이트가 뒤섞일 수 있다는 점을 잊어버리면 됩니다!
- 아마도 다른 사람들도 있을 것입니다. chroot는 결코 단순하지 않습니다.