일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 리눅스
- hyperledger
- 오라클 디비
- 운영체제
- 초대장
- JVM
- 오라클
- auto configure
- MongoDB
- 자바
- 백준 알고리즘
- 알고리즘
- K6
- oracle
- 문법 정리
- spring
- 티스토리
- c#
- 프로젝트
- 학점
- 파이썬 소스
- 자바 프로젝트
- gradle
- resilience4j
- smart cast
- dynamic query
- jsp
- 파이썬
- SQL
- 유사코드
- Today
- Total
목록목차 (231)
모종닷컴
버퍼 풀 InnoDB 스토리지 엔진의 핵심적인 부분이다. 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간. 쓰기 작업을 지연시켜 일괄 작업으로 처리할 수 있게 해주는 버퍼 역할도 같이 한다. => 디스크 작업의 횟수를 줄일 수 있다. 버퍼 풀 사이즈 운영체제와 클라이언트 스레드가 사용할 메모리를 고려하여 설정해야 한다. 클라이언트 세션에서 테이블의 레코드를 읽고 쓸 때 버퍼로 사용하는 공간을 '레코드 버퍼'라고 하는데, 커넥션이 많고 사용하는 테이블도 많다면 레코드 버퍼 용도로 사용되는 공간이 많이 필요해질 수 있다. 하지만 레코드 버퍼 공간은 별도로 설정할 수 없으며, 전체 커넥션 수와 커넥션에서 읽고 쓰는 테이블의 개수를 가늠할 수 없으므로 정확한 메모리 공간 산정이 어렵다. 위에서..

이번 글에서는 제가 Postman에서 자주 사용하는 꿀팁 아닌 꿀팁을 공유드리고자 합니다. 일단 예시 상황을 먼저 보도록 하겠습니다. 일련의 과정들을 호출 이런 예시 상황을 들어보도록 할게요. 멤버를 등록하는 API를 호출 후, 해당 멤버의 이름을 업데이트하는 api를 호출 이어서 멤버를 삭제하는 api를 호출하는 프로세스가 필요하다고 합시다. 일단 포스트맨에 컬렉션 하나를 추가하고 컬렉션에 3개의 Request를 추가합니다. 아래에서 3개 API 스펙을 설명하도록 하겠습니다. 다만 블로그 글을 위해 엉망진창으로 만든 API라서 불편하더라도 그냥 봐주시면 감사하겠습니다ㅎㅎ... 멤버 등록 이름만 받으면 멤버 등록이 완료됩니다. 응답 메시지로는 생성된 멤버의 id를 그냥 리턴하도록 했어요 멤버 이름 수정..

깃허브에 용량이 큰 파일인 경우 블락당한다는 사실을 알고 계신가요?? 용량이 큰 파일을 왜 제한하고 있는지, 큰 파일의 기준이 어떻게 되는지, 용량이 큰 파일을 어떻게 올릴 수 있는지를 한번 알아보도록 하겠습니다. 용량이 큰 파일을 제한하는 이유 GitHub에서는 사용자의 성능과 안정성을 보장하기 위해 전체에 대하여 리포지토리 상태(= repository health)를 모니터링하고 있으며. 리포지토리 상태 체크는 크기, 커밋 빈도, 커밋 내용, 커밋 구조를 보고 있습니다. 그리고 이 상태 체크에 커밋 파일 크기가 걸리는 걸로 보입니다. 이는 리포지토리의 크기를 작게유지하기 위함도 있는 것 같습니다. 깃허브에서 설명에 따르면 리포지토리의 크기는 1GB, 5GB 미만을 권장한다고 합니다. 리포지토리가 작을..

최근 들어 소수점을 다루는 일들이 종종 생깁니다. 그리고 이 소수점들을 이용해 연산을 할 때가 많은데 그러다 보니 소수점 관련 문제들을 마주하게 되면서 BigDecimal을 사용하게 되었습니다. 일단 소수점을 이용해 연산할 때 생기는 문제들에 대해서 살펴보도록 하죠. 소수점 + 소수점 = ? 간단하게 테스트 코드를 만들고 이를 실행시켜보도록 하겠습니다. class DecimalTest { @Test fun `소수점 더하기 테스트`() { val a = 10.1 val b = 9.2 val c = a + b print(c) Assert.assertTrue(c == 19.3) } } 위의 코드를 실행시키기 전 우리는 코드만 봤을 때는 전혀 문제가 없는 것처럼 보입니다. 하지만 실제로 이 코드를 실행해보면 아..

몇 달 전부터 꾸준히 밤에 산책이랑 달리기를 하고 있는데 그때마다 '향수가 있으면 좋겠다'라는 생각을 가졌다. 이전에는 몰랐는데 누군가 내 옆을 지나갔을 때 향수 향이 나면 나도 모르게 뒤돌아보게 되는 것 같다. 그리고 나한테도 이런 향이 나면 좋겠다라는 생각이 들었다. 남자 향수를 내 손으로 사본적이 한번도 없어서 유튜브에 추천 향수를 쳐보니 미들 노트가 어쩌고.. 탑 노트가 어쩌고.. 한다. 이왕 이렇게 된 거 그래도 기초 지식은 있어야 할 것 같아서 글로 끄적거려 보려고 한다. 향수의 3가지 노트 탑 노트 : 뿌린 후 초반에 15-30분까지 느껴지는 첫 향. 확산속도가 빠르고 가장 먼저 느껴진다. 시트러스 계열들(라임, 오렌지, 레몬 등 감귤 계열의 향)이 모두 탑 노트에 해당된다. 미들 노트 : ..

스프링 시큐리티의 PreAuthorize를 사용하다가 조심해야 할 부분인 것 같아 글로 적어봅니다. Gradle + Kotlin + Spring Boot + Spring Security 조합으로 프로젝트를 구성하였는데 이 구성을 블로그 글에 하나씩 올리자니 너무 내용이 길어지는 것 같아 전부 설명하지 않고 일부분만 코드를 올리도록 하겠습니다. Gradle Dependency 추가 implementation "org.springframework.boot:spring-boot-starter-security" Security Configure @Configuration @EnableWebSecurity @EnableGlobalMethodSecurity(prePostEnabled = true) class Sec..

InnoDB 스토리지 엔진 아키텍처 InnoDB는 MySQL에서 사용할 수 있는 스토리지 엔진 중 거의 유일하게 레코드 기반의 잠금을 제공해서 높은 동시성 처리가 가능한 스토리지 엔진입니다. InnoDB의 특징들을 하나씩 알아보도록 하겠습니다. Primary Key 클러스터링 InnoDB의 모든 테이블은 기본적으로 프라이머리 키를 기준으로 클러스터링되어 디스크에 저장됩니다. 프라이머리 키 외에 세컨더리 인덱스가 존재하는데 이곳에는 레코드의 주소(디스크의 데이터 위치)가 아닌 프라이머리 키의 값을 논리적인 주소로 사용합니다. 따라서 디스크는 프라이머리 키 기준으로 저장되어 있어 프라이머리 키를 이용한 레인지 스캔은 상당히 빨리 처리될 수 있습니다. Foreign Key 지원 외래 키에 대한 지원은 Inno..

오늘의 주제는 테스트 코드를 적절하게 이용해서 버그를 예방하기입니다. (물론 아닐 수도 있지만..) 대개 테스트 코드를 작성하는 이유는 지속적으로 내가 만든 코드가 정상 동작하는지를 체크하기 위함일 겁니다. 하지만 이 외에도 테스트 코드는 정말 유용하게 사용할 수 있습니다. 제약을 테스트 코드로 예시를 좀 들어보겠습니다. A 서버에는 Food라는 Enum 클래스가 존재합니다. B 서버에서는 A 서버의 이넘 클래스 정보를 가져와 외부에 등록을 한다고 합니다. 이때 외부에 등록하는 것이다 보니 사이즈나 길이 등의 제약이 존재하게 되었습니다. 최대 10자까지 등록할 수 있다고 하네요. 이러한 상황을 알고 있는 개발자가 Food안에 있는 Enum 값을 모두 10자리 미만으로 만들도록 하였고 주석도 잘 달아주었습..
AOP 주요 용어 알아보자. 용어 의미 Joinpoint Advice를 적용 가능한 지점을 의미. 메서드 호출, 필드 값 변경 등이 Joinpoint에 해당 Pointcut Joinpoint의 부분 집합으로서 실제로 Advice가 적용되는 Joinpoint를 나타낸다. Advice 언제 공통 관심 기능을 핵심 로직에 적용할 지를 정의하고 있다. ex) 메서드 호출 전, 후 Weaving Advice를 핵심 로직 코드에 적용하는 것을 weaving이라고 한다. 코드를 핵심 로직 코드에 삽입하는 것이 weaving Aspect 여러 객체에 공통으로 적용되는 기능을 Aspect라고 한다. Spring AOP와 AspectJ의 목표는 다르다. Spring AOP는 프로그래머가 직면하는 가장 일반적인 문제를 해결..

이전에 회사에서 RPS(Request Per Second) 올리기 위한 작업을 한 적이 있었는데 이때 트랜잭션이 중요한 해결점이 되었던 게 생각나서 정리할 겸 글을 써본다. 스프링 트랜잭션 정말 좋긴 한데.. 트랜잭션 음.. 좋다! 트랜잭션 안에서 실행되는 일련의 작업들을 하나의 작업으로 보장되고 실패 시 롤백도 할 수 있으니 좋다. 트랜잭션이 없었다면 오류 발생 시 이전 작업을 되돌리는 것도 개발자의 몫이었겠지..? 각설하고 이 좋은 트랜잭션이 부하 테스트에서는 아주 나쁜 놈(?) 이었다. 자세히는 설명할 수 없지만 API 중 3~7초 정도 시간이 소요되는 API가 있다. 트랜잭션 좋으니 당연히 주요 로직에 트랜잭션을 붙였는데 부하 테스트를 하다 보니 Connection 타임아웃 에러가 보였다. 무엇인..