|파일 잠금이 필요한 이유는..
|캐쉬가 리셋되거나 만료되었을 때 그것을 가장 먼저 확인한 프로세스(또는 쓰레드)만
|캐쉬를 갱신하는 작동을 하고 나머지 프로세스는 갱신이 완료될 때까지 대기했다가
|완료된 후 갱신된 캐쉬를 읽어서 뿌려주도록 되어야 하는데..
|이런 식으로 작동하지 못한다면.. 캐쉬가 특히 필요한 대규모 싸이트에서는
|잘린 페이지가 출력되거나 오히려 과부하가 발생할 수 있습니다.
캐시기능에 대한 처리에 대해 의견이 있어서 글을 적어봅니다.
파일 잠금 문제로 캐시 기능의 추가를 보류(포기?)하셨는데,
다음과 같은 방법으로 해결되지 않을까 합니다.
우선 캐싱된 파일의 헤더에 만료시간정보는 들어있을 것 같은데,
만료시간정보 외에 현재상태정보를 저장시켜놓는 방법입니다.
기간이 만료되어 페이지를 갱신해야 할 때(만료후 첫 요청시)
기존 캐싱된 파일의 현재상태정보를 갱신중으로 변경합니다.
그리고 랜덤하게 파일명을 생성하여 갱신된 페이지를 저장합니다.
페이지 갱신이 완료되면 copy 를 이용해 캐싱된 파일을 바꾸어줍니다.
이럴 경우 굳이 file 에 lock을 걸 필요가 없을 거라 생각됩니다.
그럼 페이지의 요청이 있을 때,
1. 만료가 되지 않았을 경우엔 당연히 캐싱된 페이지를 반환합니다.
2. 만료후 첫 요청때, 현재상태정보를 변경하고 갱신에 들어갑니다.
3. 현재 갱신중일 때, 기존 캐싱된 페이지를 반환합니다.
이렇게 하면 첫 요청자만 갱신완료시까지 대기를 하게 되고, 그 외
만료후 갱신 완료시까지 기존에 캐시되어있던 파일을 보게 됩니다.
여기서 또 생각해볼 것은 만료후 첫 요청자가 갱신도중 취소했을 경우
현재상태정보가 갱신중으로 변경된 상태라서 다음 요청에 계속해서
기존 페이지를 뿌려줄 것으로 생각되는데, 이 경우도 PHP 메뉴얼의
연결제어 부분을 참고하시면 해결될 수 있을 것으로 보입니다.
또 한가지는 만료 후 여러명의 접속자가 현재 상태가 갱신중으로
변경되지 않은 상태인 페이지를 동시에 요청했을 경우인데...
(사실 원래 보류하시려던 것도 이런 이유같긴 한데...)
여기서 발생하는 오버헤드는 감수할 정도인 듯 싶습니다.
답변 부탁드릴께요. |
