나무위키 PHP 항목에서 단점란에
단일 프로세스 단일 쓰레드 FastCGI를 쓰게되면[8](IIS나 NGINX로 돌릴 경우 이에 해당된다.) Node.js처럼 응답을 즉시 하지 않아도 되는 런타임 환경의 서버에 curl, sleep, 응답없음 등이 발생하면 php-cgi 프로세스가 블로킹된다. 아예 PHP 프로세스 전라인이 멈춰버리게 되어 서버 정지가 발생하는 단점이 있다. 여기에 더해서 FastCGI 연결에서 프록시 방식과 소켓통신 중 소켓통신을 하게되면 프로세스 하나당 아이피:포트 하나만 매핑가능 하게 되어있으므로 포트 대역은 기껏 해봐야 65535개 인데 시스템 포트 1024개를 제외하면 동접자 6만언저리가 한계이므로 한도를 초과하면 웹사이트가 터지게된다. 대안으로 로드벨런싱과 후술하는 복수의 프로세스를 사용하면된다.
이라고 적혀있는데요
PHP는 요청할때 프로세스가 생기는 멀티프로세스 방식으로 동작한다고 알고있는데
저렇게 동작하는건지 잘못된 내용인지 궁금합니다.
나무위키도 많은사람이 보는만큼 잘못된내용이면 고쳐야 할꺼같아서 질문드립니다
하나의 커넥션을 처리하는 데 하나의 프로세스가 필요하다는 것은 사실입니다. 웹소켓을 제외하면 현실적으로 문제가 될 일은 거의 없지만, 웹소켓을 사용하는 채팅 앱이나 실시간 알림 등을 구현하는 데는 아주 큰 단점이지요. 이럴 때는 node.js처럼 하나의 프로세스가 여러 커넥션을 처리할 수 있는 시스템이 더 유리합니다. 객관적으로 단점을 적는다면 이 부분이 부각되어야 할 것 같네요. PHP에도 node.js와 비슷한 방식의 ReactPHP라는 것이 있긴 하지만, 국내에는 거의 알려지지 않아서...
그.러.나.
1. 서버 사양이 심각하게 낮지 않은 이상 PHP-FPM을 단일 프로세스로 사용하는 일은 없지요. 복수의 프로세스를 쓰는 방법을 후술하겠다고 해놓고 까먹은 모양이네요. ㅋㅋ
보통 10여개 이상, 방문자가 많은 사이트는 100여개 이상의 프로세스를 만들어 놓고 돌려가면서 씁니다. (후술할 이유로, 1000여개까지 가는 일은 극히 드뭅니다.) 요청하는 찰나에 프로세스가 생성되는 것도 아닙니다. 적당한 갯수를 미리 만들어 놓고 기다립니다. 부족할 것 같으면 미리 더 만들고, 남으면 천천히 줄이고, 다 알아서 합니다. FPM = FastCGI Process Manager의 약자입니다. "프로세스 관리"가 이 녀석의 존재 이유입니다. PHP의 특성상 프로세스 갯수 관리가 성능과 직결되기 때문에, 이 부분의 관리 능력만은 다른 어떤 언어나 프레임워크와 비교해도 꿇리지 않게 만들어 놓았습니다.
2. PHP의 소켓통신 방식에 대해 아주 큰 오해가 있네요. 프로세스 하나당 아이피:포트 하나를 배정할 수 있는 것이 아니고 FPM pool마다 하나씩 배정합니다. 보통 기본포트가 9000번이고, 프로세스를 수백~수천 개 돌리더라도 FPM pool 하나에 모두 넣어놓으면 9000번 포트 하나만 사용합니다.
localhost인 경우에는 유닉스 도메인 소켓(예: /run/php/php-fpm.sock)으로 통신하면 포트를 아예 사용하지 않으므로 sysctl.conf에서 설정한 것 외에는 동접 제한이 전혀 없는 것은 물론, TCP 오버헤드가 발생하지 않으므로 성능 향상 효과까지 볼 수 있습니다. nginx와 PHP-FPM이 유닉스 도메인 소켓으로 통신하도록 하고, PHP와 MySQL, Memcached 등도 모두 유닉스 도메인 소켓으로 통신한다면 동접수가 아무리 많아도 포트는 nginx가 사용하는 80, 443 외에는 단 1개도 더 필요하지 않습니다.
3. 가장 중요한 것은 PHP-FPM 프로세스 1개당 동접자 1명이 아니라는 점입니다.
수십 개의 PHP-FPM 프로세스를 구동하는 중소형 커뮤니티 사이트 기준으로 PHP-FPM 프로세스 1개당 동접자 100명 내외를 처리할 수 있습니다. 웹의 특성상 모든 유저가 항상 서버에 처리를 요청하는 것은 아니기 때문이지요. Keep-Alive를 사용하더라도 그건 nginx단에서 관리하지, PHP-FPM 프로세스를 점유하지는 않습니다. 예를 들어 저는 지금 XE타운에 접속해 있지만, 이렇게 댓글을 쓰는 동안에는 아무 것도 요청하지 않고 있습니다. 댓글을 저장하고 새로고침하는 찰나에만 PHP-FPM 프로세스를 점유하게 되겠지요. (참고)
4. 웬만한 서버는 동접 6만 명이 되기 전에 CPU나 RAM이 부족해서 이미 터지고 없을 겁니다. 이미 오래 전에 로드밸런서를 사용하여 여러 대의 서버로 부하를 분산시켜 놓았겠지요. 요즘은 최고 사양의 CPU를 여러 개 박으면 XE로도 동접 6만 명이 나오기는 합니다만... (256코어 함 잡솨봐~ㅎㅎ) 설사 글쓴이의 주장이 옳더라도 현실적인 문제는 아니라는 뜻입니다.