큐를 넣을 자리인지 다시 봤다

메일 보내는 것이 느려서 요청 하나가 이 초 넘게 걸렸다. 큐를 넣자는 이야기가 나왔다. 넣기 전에 무엇이 느린지부터 쟀다.

Open Table of contents

무엇이 느린지 쟀다

메일 보내는 자리 앞뒤로 microtime 을 찍어 봤다. 그 한 줄이 일 초 팔이었고 요청 전체가 이 초 일이었다. 나머지 처리는 다 합쳐도 삼백 밀리초였다.

느린 자리가 하나로 좁혀졌다. 그러면 그 자리만 요청 밖으로 빼면 된다. 무엇으로 빼느냐가 다음 물음이었다.

큐를 쓰려면 그 서버를 세우고 꺼내 처리하는 것을 계속 돌려야 한다. 그것이 죽으면 다시 띄우는 것도 있어야 한다. 실패한 것을 어떻게 할지와 밀렸는지 보는 것도 새로 만든다.

메일 하나 때문에 이것을 전부 세우는 것이 맞는지 걸렸다. 넣는 것 자체보다 딸려 오는 운영이 더 컸다. 그래서 더 단순한 방법이 있는지 먼저 봤다.

보낼 내용을 MySQL 테이블에 넣고 cron 이 일 분마다 꺼내 SMTP 로 보내게 했다. 이미 있는 것을 쓰니 새로 세울 것이 없었다. 요청은 이 초 일에서 삼백 밀리초가 됐다.

큐를 세운 것과 결과가 같았다. 다만 단순한 대신 안 되는 것도 있었다. 일 분 안에는 안 나가고 초당 수천 건은 못 다루며 여러 대가 나눠 처리하려면 MySQL 쪽 잠금이 필요했다.

메일은 일 분 늦어도 문제가 없는 종류였다. 하루 발송량이 이천 건이라 처리량도 걸리지 않았다. 포기한 것이 전부 지금 필요 없는 것이었다.

다만 여러 대가 될 때를 대비해 UPDATE 로 먼저 표시하고 그것만 가져가는 방식은 지금 넣었다. 나중에 넣으려면 이미 같은 메일을 두 번 보낸 뒤가 된다. 중간에 죽어 표시만 남은 것을 되돌리는 정리도 함께 뒀다.

언제 큐로 바꿀지도 숫자로 적어 뒀다. 하루 오만 건을 넘거나 일 분 지연이 문제가 되는 종류가 생기면 바꾼다. 많아지면이라고 적으면 그때가 언제인지 아무도 모른다.

보낸 기록이 한 달에 육만 건씩 쌓여서 DELETE 도 같이 만들었다. 성공한 것은 구십 일 두고 DELETE 하고 실패한 것은 남겼다. 넣는 것을 만들 때 지우는 것을 같이 만들지 않으면 조회가 점점 느려진다.