|여기서 또 생각해볼 것은 만료후 첫 요청자가 갱신도중 취소했을 경우
|현재상태정보가 갱신중으로 변경된 상태라서 다음 요청에 계속해서
|기존 페이지를 뿌려줄 것으로 생각되는데, 이 경우도 PHP 메뉴얼의
|연결제어 부분을 참고하시면 해결될 수 있을 것으로 보입니다.
==>
Cached FastTemplate 의 경우 만료확인한 첫 프로세스만
갱신에 들어가도록 조치가 되어 있는데..
갱신에 들어가는 부분에 주석이 이렇게 달려있더군요.
// We pray that nothing bad happens after this point.
갱신을 요청한 프로세스가 중단되었을 때 2~3 초 후 다른 프로세스에 의해
갱신이 시도되도록 Cached Fast 보다는 좀 더 지능적인 로직을 만들긴 했는데..
이런 상황이 반복되면 대기하는 프로세스가 늘어나고.. 완벽하지는 못합니다.
아파치의 경우.. 요청된 프로세스가 취소돼도 끝까지 실행되는데..
연결수가 많을 때도 그게 보장되는지 모르겠습니다.
말씀하신 연결제어 부분에 답이 있는지 모르겠는데.. 못찾겠네요.
혹시 아파치관련함수를 말씀하신거라면.. 그거로는 안되구요.
|또 한가지는 만료 후 여러명의 접속자가 현재 상태가 갱신중으로
|변경되지 않은 상태인 페이지를 동시에 요청했을 경우인데...
|(사실 원래 보류하시려던 것도 이런 이유같긴 한데...)
|여기서 발생하는 오버헤드는 감수할 정도인 듯 싶습니다.
==>
어떤 방법을 사용하든지 한 개의 프로세스만 갱신동작을 하면 괜찮겠지만..
초당 같은 페이지에 대한 클릭이 수 천 수 만이면,
여러프로세스가 동시에 같은 파일을 쓰기할 때,
뒤이은 프로세스가 계속 캐쉬가 무효하다고 판단하게 되고..
(다른 프로세스가 읽거나 쓰고 있는 중에도 fopen(file, 'w')시에 0 byte가 되버리더군요.)
전부다 갱신모드로 들어가게 되서.. 오버헤드가 지속됩니다.
다른 엔진들에 대해 섣불리 비난을 한 것도 같긴 한데..
어쨌든 감수할 정도인지 아닌지.. 테스트해보기전에는 정확히 알 수 없는 일인거 같네요.
(그리고 카피를 하더라도 헤더정보를 바꿔 저장할 때, 복사할 때, 마찬가지 상황인거 같습니다.)
프로그램이라는 게 되면 되고 안되면 안되고 그래야 될 거 같는데..
이 작업은 어렵다기 보다 뭔가 지저분?한 느낌이 들고..
그래도 캐쉬가 동작해주면 효과가 크기 때문에..
만들긴 하겠지만.. 실험버전의 형태가 될거 같네요.
그리고 강상욱님의 의견을 검토하면서.. 여러가지 도움이 되었네요.
감사합니다. |
