Gun's Dev Log

Scouter is an APM optimized for developers. Scouter가 " 개발자를 위한 APM "이라는 목적에 맞게 자유도가 높은 반면, 자잘하게 숨겨진 기능이 많은 APM인지라 이 시리즈를 통해 Scouter의 기능을 하나 하나 알아보도록 하겠습니다. 첫번째 내용은 설치하기 입니다. * Scouter 설치 전 반드시 기억해야할 사항 Scouter는 Agent와 Collector Server 그리고 User용 Client 프로그램으로 구성되며, 이들간의 관계를 잘 아는 것이 중요합니다. 각 서버에 설치된 Scouter의 Agent들이 성능 데이터를 Collector로 전송한다. 사용자는 Client 프로그램을 통해 성능 데이터를 본다. Agent  ⇨⇨⇨   [성능 데이터]  ⇨⇨⇨  Collector (Server) Client  ⇦⇦⇦   [성능 데이터]  ⇦⇦⇦  Collector (Server) * Scouter를 처음 사용하신다면 먼저 아래 동영상을 통해 개략적인 모습을 보시기 바랍니다.   -  Scouter APM Overview Scouter 설치 1. Scouter 다운로드 Scouter 릴리즈 페이지에서 최신버전을 다운로드합니다. Scouter Release Page scouter-all-[version].tar.gz Scouter Collector와 Agent를 포함하는 압축파일입니다. scouter.client.product-[os].tar.gz 각 OS별 Client(Viewer) 프로그램입니다. 2. Scouter Server 설치 및 기동 적절한 위치에 scouter-all-[version].tar.gz 의 압축을 풀어줍니다. Scouter Server를 실행합니다. startup.sh 또는 startup.bat 실행 netstat -an | grep 6100 을 해

Scouter is an APM optimized for developers. XLog 활용 Scouter 개발시 가장 중점을 두었던 것 중 하나가 " XLog 차트 안에서 모든 문제를 다 해결할 수 있도록 하자 " 였습니다. 그래서 XLog 차트는 상당히 많은 기능을 가지고 있으며 그중 중요한 기능들에 대해 설명하도록 하겠습니다. 1. XLog의 조작 (1) 키보드를 통한 간편 이동 실시간 XLog 차트에서 키보드를 사용하여 XLog 차트의 시간을 이동시킬수 있습니다. 이를 통해 가까운 과거 시점으로 빠르게 이동이 가능합니다. (큰 시간을 이동하여야 하면 Load History 메뉴를 사용하여야 합니다.) 좌우 화살표 : 한번 누르는 경우 10초를 이동합니다. 상하 화살표 : 한번 누르는 경우 일정한 비율로 Y축의 스케일을 조절합니다. (2) Y축 항목 변경 <그림. XLog Y축 항목 변경> Y축 항목을 응답시간(ElapsedTime)이 아닌 다른 값으로 변경할 수 있습니다. 현재 서비스가 CPU bound인지 혹은 SQL이나 Api call bound인지를 한눈에 파악할때 주로 사용하게 됩니다. 혹은 SQL 호출 회수가 많은 서비스를 골라내거나, 메모리 사용량이 많은 서비스를 골라낼때 사용하기도 합니다. (3) Load History 과거 특정 시점의 XLog 차트를 로드하기 위해 사용합니다. (4) Summary <그림. XLog 통계> 화면에 표현된 XLog 점들에 대한 통계를 바로 확인할 수 있는 기능입니다. 예를 들면 각 서비스에 대한 총 호출 건수 및 총 응답시간, 평균 응답시간, SQL 및 API 호출에 대한 평균 응답시간 등을 확인할 수 있습니다. (5) Filter XLog를 통한 분석시 가장 많이 사용되는 기능중의 하나입니다. 원하는 조건의 XLog 점들만 보여지도록 하는 기

Project Loom 최신 빌드 얼리 액세스 빌드 제공 ( 2020년 8월 17일) Build 16-loom+105   자바의 동시성 처리 개선을 위해 Ron Pressler의 제안으로 2017년 시작된 Project Loom이 얼마 전 더욱 완성도 높은 형태의 얼리 액세스 빌드로 제공되었다. 개인적으로 관심이 많은 프로젝트이기도 했고 릴리즈가 되면 현재의 비동기 개발 방식에 많은 영향을 미칠 것으로 보이는지라, 올해 개발 세미나 등에서 ( 이전 글- 나는 왜 Reactive streams와 친해지지 않는가? 와 잘 버무려서 )   관련 내용을 다뤄볼까 하는 생각이 있었지만 이놈의 C19 이슈로 거의 모든 개발 세미나가 온라인으로 진행되고 있어 그냥 블로그 글로 남겨본다. 최근 자바 서버 개발에 큰 흐름 중 하나로 등장한 reactive streams라는 어그로(?) 끄는 제목과는 달리 비동기 프로그래밍과 Project Loom 에 대한 글이다. ^^; (물론 여기엔 reactive streams 도 포함된다.) Project Loom 의 동기 Project Loom 제안 Project Loom: Fibers and Continuations for the Java Virtual Machine Project Loom의 동기 자원 사용면에서 효율적이지 못한 스레드 작성하고 디버깅 하기 어려운 비동기 개발 방식 경량 스레드(파이버)를 통한 블로킹 방식의 개발로 이를 해결하기 위함 먼저 Project Loom의 제안  내용 중 프로젝트의 동기 부분만 간단히 살펴 보도록 하자 하나의 서버에서 수백만 개의 소켓을 다룰 수 있지만 OS 스레드를 직접적으로 사용하는 자바에서는 동시에 수천 개 이상의 요청을 효율적으로 다루기 어렵다. 이를 극복하기 위해 최근 수년 간 많은 비동기 라이브러리들이 탄생하였는데 이는 작성하고 이해하고 디버깅하기 편해서가 아니라 단지 자바의 스레드가 성능면에서 효율적이지 못하기 때문 이다. Loom의 목표는 수백만 개를 생성할 수 있는 파이버라고