글을 고쳐도 캐시가 그대로? — Nginx Helper 자동 퍼지 삽질기 (원인 4가지)
7편에서 FastCGI 캐시를 붙였고, 이번엔 글을 발행할 때마다 캐시를 자동으로 비우는 “자동 퍼지”를 붙이려 했다. Nginx Helper 플러그인만 깔면 5분이면 끝날 줄 알았다. 결론부터 말하면 반나절을 썼다. 권한을 의심하고, 경로를 의심하고, 해시를 손으로 계산하고, 급기야 플러그인 소스 코드까지 열어봤다. 그리고 … 더 읽기
7편에서 FastCGI 캐시를 붙였고, 이번엔 글을 발행할 때마다 캐시를 자동으로 비우는 “자동 퍼지”를 붙이려 했다. Nginx Helper 플러그인만 깔면 5분이면 끝날 줄 알았다. 결론부터 말하면 반나절을 썼다. 권한을 의심하고, 경로를 의심하고, 해시를 손으로 계산하고, 급기야 플러그인 소스 코드까지 열어봤다. 그리고 … 더 읽기
7편에서 FastCGI 캐시로 서버가 페이지를 내주는 시간을 잡았습니다. 하지만 방문자 브라우저가 실제로 낑낑대며 내려받는 건 대개 글자가 아니라 이미지입니다. 이번 편에서는 같은 서버에서 이미지 용량 자체를 줄입니다. 방법은 1편과 같습니다. 플러그인은 설치하지 않고, 심지어 글의 HTML도 한 글자 고치지 않습니다. … 더 읽기
6편에서 SSL을 붙여 주소창의 자물쇠까지 채웠습니다. 이제 사이트는 안전합니다. 그런데 빠른 건 아니었습니다. 워드프레스는 방문자가 페이지를 열 때마다 PHP를 돌리고 데이터베이스에 몇 번씩 질문을 던져 HTML을 새로 조립합니다. 방문자가 늘면 이 조립 작업이 그대로 서버 부하가 되고, 느려지고, 이탈로 이어집니다. … 더 읽기
1편에서 티스토리를 떠나 서버를 직접 빌린 이유를 적었습니다. 이번 편은 그 다음 이야기입니다. 결제만 끝난 텅 빈 우분투 한 대에 SSH로 들어가서, 웹서버·데이터베이스·PHP를 손으로 올리고, 브라우저에서 PHP가 도는 걸 확인하는 데까지. 관리형 호스팅도, 원클릭 설치 이미지도 쓰지 않았습니다. 명령어는 전부 … 더 읽기