일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- Postman
- String
- 이클립스 플러그인 개발
- Runnable
- RSA
- StringUtils
- IPTV
- Java
- xlet
- sha1
- Freemaker
- DAMO
- Callable
- PKCS#8
- Executor
- 한글조사처리
- JCE
- date
- PKCS
- Instrumentation
- ACAP
- AES
- Log4J
- 한글조사
- 암호학
- ORM
- 자바 암호화
- 자바
- Executors
- mac
- Today
- Total
목록MAIL (2)
오늘은 어디로 갈까...
최적화라는 거창한 단어를 사용하긴 했지만, 사실 별 볼일 없다. 최적화라는것은 운영 환경, 데이터의 모델등 여러 요소를 복합적으로 고려해서 해야하는것이므로, 사실상 정답은 없다. 단지 최선의 방법만이 존재할뿐... 현재 본인의 상황에서 PostMan의 병목현상은 메일 전송 부분에 있다. gmail을 이용해서 보내고 있는데, 메일 1개 전송하는데 보통 3-4초가 소요된다. 아무리 유희를 위해서 만들었다지만, 너무 심하지 않는가... 그래서 약간 수정을 가해서 빠르게 전송하는것처럼(?) 만들어보자. 사실, 구조 자체를 바꿔버리고 싶은 욕망이 꿈틀되지만, 이번만은 참도록 하겠다. ^^; 만약 전용(?) 메일서버를 사용하다면, 이것보다는 빠를거 같지만, 가난한 개발자 & 게으른 개발자인 본인에게는 머나먼 얘기이..
요즘 메일 템플릿 변경 작업을 하고 있는데, 기분이 별로이다. 이곳의 메일 구조는 메일 전송 테이블에 전송 데이터를 넣으면, 데몬이 모니터링하고 있다가 발송하는 구조이다. 뭐, 이런 구조야 흔하디 흔한것이라 별로 반감은 없는데, 문제는 메일 내용을 생성하는 부분이다. 테이블에 URL을 입력하고 데몬이 URL을 호출하여 랜더링된 HTML을 받는다. 즉, 일종의 HttpClient가 웹서버를 호출해서 응답 페이지를 받는것이다. 물론 전혀 문제될게 없는 구조이다. 그럼에도 불구하고, 본인의 성격이 괴팍한것인지, 왠지 마음에 안든다. 굳이 웹페이지를 호출할 필요 없이, 템플릿 엔진을 사용해서 간단하게 구현하면 될것인데, 왜 이렇게 구현해놨을까 하는 쓸데없는 생각은 마음을 갉아먹고 정신을 혼미하게 만들었다. 그래..