일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- javascript
- Java
- etf
- 금리인상
- 주식
- FCF
- 다형성
- 미국주식
- 무디스
- 기업분석
- XLF
- 그리디 알고리즘
- StringBuffer
- mco
- 현금흐름표
- 오버라이딩
- 객체지향
- 백준
- S&P500
- 알고리즘
- 제태크
- 주린이
- 잉여현금흐름
- 배당성장
- object
- 금리인하
- 접근제어자
- 인플레이션
- 자바
- 프로그래머스
- Today
- Total
목록분류 전체보기 (209)
오늘의하루
성능 향상을 위한 Load Balancing 전략을 검토하고, AWS의 ELB와 오토 스케일링을 활용하여 효과적인 서비스 배포를 준비합니다. Load Balancing Load Balancing은 Scale-Out 전략의 핵심으로, 서버나 리소스의 수를 증가시켜 시스템 성능을 향상시킵니다. 테스트 결과, 30~40개의 스레드가 최적의 성능을 나타내므로 이를 고려하여 Load Balancing 전략을 수립합니다. Nginx를 통한 Load Balancing 설정 Nginx는 Reverse Proxy와 Load Balancing 설정이 간편하며, 적은 자원으로 많은 연결을 처리할 수 있어 선택했습니다. Load Balancing 알고리즘으로는 Least Connections, Generic Hash를 테스트..
사용자를 특정 그룹에 추가 그룹에 사용자를 추가하는 명령은 시스템 관리자 혹은 root 권한을 가진 사용자만 가능하다. $ sudo usermod -aG docker jangto usermod : 사용자 계정을 수정하는데 사용되는 명령어로 사용자 계정의 특성을 변경하거나 그룹에서 추가 또는 삭제 하는 등 작업을 할 수 있습니다. -aG : 이 옵션은 사용자를 그룹에 추가할때 사용되며, a는 append를 의미하고 G는 추가할 그룹을 지정해줍니다. docker : 이 자리에는 그룹의 이름이 들어갑니다. jangto : 이 자리에는 그룹에 추가될 사용자 이름이 들어갑니다. Window에서 docker로 파일 복사 만약 파일이 C드라이브나 D드라이브에 있다면 /mnt/c/ 혹은 /mnt/d/를 붙여서 복사 할..
개선 사항 시간 복잡도 개선: O(N^2)의 시간 복잡도를 가진 메소드를 O(N)으로 개선했습니다. 이로써 데이터 처리 과정의 속도가 향상되었습니다. 압축 해제 라이브러리 사용: 기존에는 ZipInputStream을 사용했으나, Apache의 archivers를 사용하여 압축을 해제하는 방식으로 변경했습니다. 이는 성능과 안정성을 향상시켰습니다. 데코레이터 사용: 주석 제거 전 프로세스에서 ArchiveInputStream으로 Stream을 만들어서 주석 제거 메소드에서 Stream을 사용하여 파일 IO작업의 성능을 높였습니다. 이로써 파일 IO 작업의 효율이 개선되었습니다. 반복적인 작업 개선: 반복적으로 접근하여 파일 IO 작업이 이뤄지는 부분을 개선하여 한 번만 접근하도록 수정하였습니다. 이로써 불..
개선 사항 프로세스 단계 간소화: 불필요한 프로세스 단계를 제거하고, 필요한 작업을 더 효율적으로 처리하기 위해 프로세스를 재구성했습니다. 이로써 프로세스의 실행 속도를 향상시켰습니다. String 객체 생성 최소화: 불필요한 String 객체 생성을 제거하고, 메모리 사용을 최적화하기 위해 InputStream을 활용하여 데이터를 처리하도록 수정했습니다. 버퍼 크기 증가: 프로세스의 효율성을 높이기 위해 버퍼 크기를 4096byte로 증가시켰습니다. 이는 프로세스의 데이터 처리량을 늘려서 성능을 향상시켰습니다. 불필요한 IO 작업 제거: 불필요한 IO 작업을 최소화하여 메모리 사용을 줄였습니다. 이는 프로세스의 부하를 감소시켜서 전반적인 성능을 향상시켰습니다. 환경 설정 Apache JMeter ver..
개선 사항 첨부 파일을 디스크에 저장한 후 분석하던 기존의 방식에서 메모리로 처리하도록 변경하여, 데이터를 일부분씩 분할하여 작은 메모리에서도 처리할 수 있도록 설계를 변경했습니다. 환경 설정 Apache JMeter version : 5.6.3 Spring boot version : 3.2.2 Java version : 17 시나리오 JMeter를 사용하여 100명의 가상 사용자가 동시에 100MB 크기의 zip 파일을 서버에 첨부하고, 해당 파일을 분석한 후 결과를 반환하도록 시나리오를 작성했습니다. 테스트 결과 부하 테스트를 수행한 결과, 사용자의 요청 후 응답까지의 평균 속도와 서버가 처리할 수 있는 양에 집중해야 한다는 것을 확인했습니다. Throughput 비교 1차 테스트 : 10.2/min..
프로젝트 소개 SourceCode.io 프로젝트는 클라이언트가 제공한 zip 파일을 분석하여 원하는 형태의 문자를 추출하여 문서화하고, 동시에 해당 zip 파일의 구조를 반환합니다. 또한, 커스텀 빌드 프로세스를 통해 서버에 zip 파일 형태로 소스 코드를 전송한 후, 해당 코드에 한글이 있는지 확인하고 한글의 개수와 위치를 클라이언트에게 반환합니다. 목표 및 배경 Apache JMeter를 사용하여 SourceCode.io 프로젝트의 부하 테스트를 수행하여 성능을 평가하고 사용자가 원활하게 이용할 수 있도록 성능을 향상시키는 것이 목표입니다. 환경 설정 Apache JMeter version : 5.6.3 Spring boot version : 3.2.2 Java version : 17 시나리오 JMe..
오류 발생 시점 Spring Security와 JWT를 통해 인증 인가를 진행하려고 했고 Jwt Filter에서 @Transactional를 사용했기 때문에 발생하였다. 원인 정확한 원인은 아닌 것 같지만 @Transactional 어노테이션을 사용하면 스프링은 해당 메서드를 실행할 때 트랜잭션을 시작하려고 하지만, 이미 실행 중인 트랜잭션이 없기 때문에 오류가 발생할 수 있습니다. 느낀점 내가 @Transactional을 적용한 곳은 단순히 데이터를 조회하는 용도이므로 트랜젝션이 필요없다. 트랜젝션 관리는 데이터를 변경하는 작업에만 필요하다는건 알고 있었지만 깜빡하고 썻던거 같다. @Transcational은 일반적으로 서비스 계층에서 DB 트랜젝션을 처리하는데 사용된다. 그리고 필터에서 DB에 직접 ..
발생 확인 @aoptest public List testMethod(){ List list = new ArrayList(); list.add(1); list.add(2); return list; } @Around("@annotaion(aoptest)") public ResponseEntity testAOP(ProceedingJoinPoint joinPoint) throws Trowable { try { Object obj = joinPoint.proceed(); return ResponseEntity.ok().body(obj); } catch (Throwable e) { e.printStack(); } } @Getter @AllArgsConstructor public class StatusCode{ Ob..
발생원인 Object 타입으로 받아온 값을 List로 형변환을 시도하던 중 발생하였다. 이는 타입 안전성(Type safety)은 컴파일 중에 타입 제약 조건을 강제하여 런타임 중에 타입 오류를 방지하는 것을 의미하여 예외가 아닌 경고이다. 해결방법 SuppressWarnings 어노테이션 붙이기 SuppressWarnings 관련 옵션은 링크에서 확인 가능합니다. @Getter public class Tistory{ Object data; } @SuppressWarnings("unchecked") List vo = (ArrayList) tistory.getData(); 개발자 답게 타입을 정확히 확인하고 형변환 하기 항상 타입을 정확히 하는 것이 좋아 보인다. @Getter public class Ti..
예외 발생 이유 이 예외는 Fetch Join을 할 때 발생하게 되는데 원인은 2개 이상의 컬렉션이 있는 상태에서 Fetch Join을 하는 경우에 발생하게 된다. 어쩌다 발생했을까? C Entity와 B Entity는 N:1 관계이고 B Entity와 A Entity는 N:1 관계이고 모두 지연 로딩(LAZY)로 되어있다. A Entity에서 특정 Id값으로 조회하여 조회되는 데이터를 Json 형식으로 보내려고 했다. 처음에 별 생각 없이 A Entity 자체를 보내게 되었는데 이때 Stack Overflow가 발생하고 넘어간 데이터를 보니 재귀현상이 발생하고 있었고 이 문제를 해결하기 위해 Fetch Join을 사용하면서 발견했다. 해결 방안 쿼리를 분리하자! 여러 개의 컬렉션을 가져와야 할 경우, ..