Capacity Patterns(용량 패턴)

Capacity Patterns(용량 패턴)

풀 연결

리소스 풀은 연결 설정에 필요한 시간을 제거하기 때문에 용량을 극적으로 개선시킬 수 있다.

연결 풀 사용 중 연결 상태가 안 좋아 질 수 있다. 상태가 안 좋은 연결을 사용하려는 모든 요청에 에러가 발생할 것이다. 상태가 안 좋은 연결 풀을 복구할 수 있는 절차에 관하여 고려되어야 한다.

연결 풀 크기는 중요한 이슈다. 크기가 작은 연결 풀은 리소스 풀 경쟁을 일으키고, 너무 큰 연결 풀은 데이터베이스 서버에 지나친 스트레스를 유발할 수 있다.

연결 풀 체크아웃, 체크인 기법

1. Per-page

- 하나의 전체 페이지에 대해서 연결을 체크아웃 한다.

- 모든 요청에 대해서 동일한 순서로 연결이 체크아웃하고 체크인 되도록 강제할 수 있기 때문에 교착상태에 대해 더욱 안전해진다.

- 각각의 연결이 더 오래 동안 체크아웃 될 것이기 때문에 요청을 처리하는 쓰레드 대비 연결 풀의 비용이 높아야 한다.

2. Per-fragment

- 각 프라그먼트가 자신의 연결을 체크아웃하고, 작업을 한 후에, 연결을 풀에 돌려 주도록 한다.

- 이 모델은 교착사태에 더 쉽게 빠지지만 더 높은 처리량을 달성할 수 있다.

- 개별적인 연결이 더 빨리 체크인 되기 때문에 요청을 처리하는 쓰레드 대비 연결 비율이 더 낮아도 된다.

- 각 트랜잭션이 독립적으로 작동한다.

3. Hybrid

- 프라그먼트 마다 자신의 연결을 관리하게 하지만 전체적인 페이지 하나에서 데이터베이스 트랜잭션을 생성하게 한다.

- Per-page의 교착상태에 대한 안정성과 Per-fragment의 단순함과 고립성을 혼합한 형태다.

- 반드시 Per-page 보다 더 큰 연결 풀을 필요로 한다.

- 디버깅이 어려운 단점이 있다.

• 풀 연결은 기본이다.

• 호출자가 영원히 블록 되는 것을 허용하지 마라. 요청을 처리하는 쓰레드를 보호하자.

• 최대 처리량을 내도록 풀의 크기를 정하자.

캐싱을 신중하게 사용하자.

모든 어플리케이션 수준의 캐시에 대한 최대 메모리 사용률은 반드시 설정할 수 있어야 한다. 최대 메모리 사용을 한정 짓지 않는 캐시는 결국 시스템에서 사용할 수 있는 모든 메모리를 사용하사 말 것 이다. 캐시에서 설정한 메모리 크기가 어떻게 되었건, 캐시에 있는 대부분의 항목들이 사용되는지 확인하기 위해서 캐싱된 항목들에 대한 사용률을 모니터링해야 한다. 사용률이 매우 낮다면, 캐시는 어떤 성능 이득도 얻지 못하며 캐시를 사용하지 않는 것보다 실제로 더욱 느려질 것이다. 캐시에 무엇인가를 보관하는 것은 일종의 도박으로, 캐시를 한번 생성하고 해싱하여 찾아보는 비용이, 데이터가 필요할 때마다 데이터를 생성하는 비용보다 작아야 한다. 캐싱된 어떤 객체를 서버가 실행되는 동안 단 한번만 사용한다면, 이 객체를 캐싱하는 것은 도움이 되지 않는다.

캐시는 낡은 데이터의 위험을 일으킨다. 모든 캐시는 소스 데이터가 변경되었을 때 캐시에서 항목을 제거하는 무효화 전략을 가지고 있어야 한다.

• 캐시 크기를 제한하자.

• 크기가 제한되지 않은 캐시는 요청 처리에 사용된다면 더 좋았을 메모리를 사용한다. 메모리에 로드한 모든 객체를 보관하는 것은 사용자에게 좋을 게 없다.

• 플러시 메커니즘을 생성하자.

• 모든 캐시는 플러싱 되어야 한다. 캐시 플러시는 비용이 비싸기 때문에 얼마나 자주 일으킬 것인지 고려해야 한다. 그렇지 않으면 자기부정 공격을 겪게 될 것이다.

• 하찮은 객체들은 캐싱하지 마라.

• 거의 사용되지 않고, 작고, 비싸지 않는 객체들은 캐싱할 가치가 없다.

• 접근 회수와 변경 회수를 비교하자.

• 다시 사용되기 전에 변경될 것 같은 것은 캐싱하지 말라.