카운터 그림을 메모리에 담아 두기

이 서비스가 그리는 카운터 그림의 5분의 1 가까이가 이제 아무것도 바꾸지 않습니다. 이전 세대의 마우스 추적 스크립트가 움직일 때마다 그림을 다시 불러오는데, 그 요청이 아무것도 올리지 않게 된 뒤로 연달아 온 둘은 바이트 단위로 같은 그림을 내놓습니다.

캐시의 뻔한 후보입니다. 흥미로운 결정은 그것을 어디에 두고 무엇으로 열쇠를 삼느냐였습니다.

디스크가 아니라

이것은 작은 서버에서 돌고, 디스크는 SD 카드입니다. 그린 그림을 거기 담아 두는 것은 대략 하루 70MB의 쓰기를 뜻했을 테고, 맞바꾼 것은 잰 값으로 하루 1.6분의 프로세서 시간이었을 것입니다.

나쁜 맞바꿈입니다. SD 카드는 쓰기로 망가지고, 사는 것은 프로세서에 매이지 않은 기계에서의 반올림 오차입니다. 그래서 캐시는 /dev/shm에 삽니다. tmpfs이고, 곧 RAM입니다. 거기서 잰 값: 읽기 0.027ms, 쓰기 0.036ms, 여유 1.9GB.

다시 켤 때 모든 것이 사라집니다. 캐시에게 그것은 손실이 아니라 정상입니다.

같은 기계에서 Redis가 돕니다. 쓰지 않았고, 까닭은 기술과 무관합니다. 그것은 다른 응용에 속하고 그 응용을 위해 비밀번호로 보호되어 있습니다. 한 인스턴스를 나눠 쓰면 무관한 두 서비스가 묶이고, 한쪽의 나쁜 날이 다른 쪽의 나쁜 날이 됩니다.

열쇠가 숫자를 담습니다

흔한 캐시 열쇠는 신원에 만료를 더한 것이고, 만료는 내기입니다. 지난 5분 동안 중요한 것은 바뀌지 않았다는 내기입니다. 카운터에서 바뀌는 것은 바로 화면에 보이는 그것입니다.

그래서 보이는 값들이 열쇠 안으로 들어갑니다. 숫자가 바뀌면 다른 열쇠이고, 그림은 새로 그려집니다. 내기를 조심스럽게 하는 대신 아예 없앱니다. 세어진 방문은 적어도 평생 총계를 올리므로, 세어진 어떤 방문도 낡은 그림을 받을 수 없습니다. 남은 만료는 열쇠에 들어 있지 않은 값들, 곧 주간·월간·연간 수치에 대한 상한일 뿐입니다.

먼저 확인해야 했던 것

캐시는 담는 것이 그 열쇠의 함수일 때에만 안전합니다. 그것은 모든 디자인에 관한 주장이고, 가정하지 않고 확인했습니다:

• 어떤 디자인도 다음을 쓰지 않습니다: rand(), mt_rand(), shuffle(), uniqid()
• 어떤 디자인도 시계를 시간 단위보다 잘게 읽지 않습니다
• 옛 스크립트의 추적 매개변수는 트리 어디에서도 읽히지 않습니다

마지막 것이 이 작업 전체에서 가장 훌륭한 실패를 낳았습니다. 그 매개변수가 아직 열쇠의 일부였을 때, 요청마다 마우스 좌표가 조금씩 달랐으므로 모든 열쇠가 유일했습니다. 캐시는 하루 온종일 돌며 적중 13회를 기록했습니다. 완벽하게 작동하면서 아무 일도 하지 않고 있었고, 그것이 알아채기 가장 어려운 종류의 고장입니다.

그리고 여기서 무엇이 실패해도 — 읽을 수 없는 디렉터리, 꽉 찬 디스크, 망가진 항목 — 그림은 그냥 평소대로 그려집니다. 캐시가 카운터가 나타나지 않는 까닭이 되어서는 결코 안 됩니다.