1. 멀티 스레드 기반으로 다중 요청을 처리하는 톰캣(Tomcat)의 구조와 동작 방식[ 웹 애플리케이션 서버(WAS, Web Application Server)과 톰캣 ]스프링 MVC 프레임워크는 자바 엔터프라이즈 개발을 편리하게 해주는 경량급 오픈소스 애플리케이션 프레임워크이며, 대량의 동시 요청 처리를 수행행할 수 있도록 멀티 스레드 모델을 기반으로 하고 있다. 이때 클라이언트와의 요청을 수립하고 이를 받는 부분은 웹 애플리케이션 서버(WAS, Web Application Server)가 수행하며, 대표적으로 톰캣(Tomcat)이 이를 구현하고 있다.   [ NIO 기반의 톰캣의 동작 방식 ]사용자 요청이 들어오면 OS 계층에서 TCP 3-way handshake가 발생하고, TCP 연결이 완료된다..

1. 톰캣에서 server.compression.min-response-size가 제대로 동작하지 않는 이유 분석하기 아래의 내용은 HTTP 요청 중에서 content-type: application/json인 경우를 전제로 한다. text/plain 등의 경우에는 정상적으로 작동하고 있다.  [ 스프링 부트의 server.compression 설정들 ]스프링 부트에서는 다음의 압축 설정을 통해 압축을 활성화하고, 압축을 적용할 조건을 명시할 수 있다. 해당 설정을 추가하고 클라이언트가 HTTP 요청에 Accept-Encoding: gzip 헤더를 넣고 보내면, 응답의 Content-Length 헤더가 설정된 값보다 클 경우 압축이 진행됨을 기대할 수 있다.server.compression.enabled..

1. 데이터베이스 커넥션 풀 및 JPA, 하이버네이트 설정 최적화(Database Connection Pool and JPA, Hibernate properties optimization) [ 데이터베이스 커넥션 풀 설정 최적화 ]기본 정보들데이터베이스에 연결하기 위한 기본 정보들로는 url, username, password, driver-class-name과 같은 것들이 있다. 여기서 중요한 것은 url에 접속 파라미터 부분이다.spring.datasource.url=jdbc:mysql://com.mangkyu.database:3306?\\ rewriteBatchedStatements=true\\ &zeroDateTimeBehavior=convertToNull\\ &useUnicode..

이전 포스팅에서는 스프링이 제공하는 레디스 직렬화/역직렬화(Redis Serializer/Deserializer)이 갖는 한계점에 대해서 살펴보았다. 일반적인 현대의 애플리케이션에서는 CPU 사용량보다는 메모리 사용량이 높기 때문에, 압축 기능을 통해 CPU를 조금 더 사용하더라도 저장 공간의 사용량을 줄이는 것이 합리적이라고 볼 수 있다. 따라서 이번 포스팅에서는 Gzip 압축 기능이 적용된 레디스 직렬화/역직렬화(Redis Serializer/Deserializer)를 구현하고, 스프링에서의 설정을 고도화 해보도록 하자.  1. 스프링에서 레디스 설정 및 직렬화/역직렬화(Redis Serializer/Deserializer) 고도화하기스프링 프레임워크에서 레디스를 활용할 때, 크게 @Cacheable..

1. 스프링이 제공하는 레디스 직렬화/역직렬화(Redis Serializer/Deserializer)의 종류와 한계서비스를 개발하다 보면 레디스(Redis)는 사실상 필수불가결한 구성 요소라고 볼 수 있다. 따라서 스프링 진영 역시 레디스를 손쉽게 사용할 수 있도록 캐시 추상화를 해줄 뿐만 아니라, 레디스의 자동 구성(AutoConfiguration) 등을 제공한다. 뿐만 아니라 레디스는 기본적으로 byte 배열을 사용해 데이터를 저장하기 때문에, 스프링 데이터 레디스(spring-data-redis) 에서는 데이터를 직렬화하여 레디스에 저장하고, 필요 시에 역직렬화하는 직렬화/역직렬화 도구까지 기본적으로 제공한다.하지만 스프링이 제공하는 레디스 직렬화/역직렬화(Redis Serializer/Deseri..