안녕하세요

wnsqud70님 안녕하세요~이 문제는 제가 직접 확인해봐야 할 것 같습니다. ㅠ혹시 괜찮으시다면, lleellee013@gmail.com 으로 메일 부탁드리겠습니다!

표준출력보다 Slf4J가 느릴 때

dlsrksrhk님 강의 내용에서 더 심화된 분석 글 감사합니다!AsyncAppender에 대한 내용도 언급할까 하다가 환경에 따라 차이가 나지 않을 수도 있어서 다루지 않았는데, 테스트 해주신 것처럼 표준출력이 오히려 빠른 경우 AsyncAppender로 변경했을 때 표준출력보다도 빨라질 수 있습니다.마지막에 이야기 해주신 것처럼, 성능 문제를 떠나서 로그 관리 차원에서 로깅 프레임워크 활용하는게 좋고, 실무 환경이라면 표준 출력이 경쟁적인 상태가 될 거라 로깅 프레임워크를 활용하는게 더 높은 성능을 보일겁니다. 😀남겨주신 내용은 제가 강의 노트란에도 추가해두겠습니다~감사합니다!!

강의 내용을 어느 정도로 파악하고 있는 것이 좋을까요?

형씌님 안녕하세요.우선 질문 주셔서 감사합니다. 프로그래밍을 처음 했을 때로 돌아가보면, 처음에는 하나씩 따라해보면서 문법을 익히고, 그 과정을 이해하면서 자연스레 문법들이 외워졌던 것 같습니다. 물론 처음에 잘 외워지지 않더라도 계속 반복해서 비슷한 코드를 작성하다보니 어느 순간 외워졌던 것 같아요. if 문은 조건식이 참일때 실행이 된다던지,for 문에는 초기식, 조건식, 증감식 순으로 넣어야 한다던지,변수에 대입은 = 로 하고, 실제 동일한지 비교는 ==로 한다던지 같은 것 처럼요. 제가 비록 형씌님이 얼마나 많은 프론트엔드 코드를 작성했는지 알지는 못하지만, 분명 이런 문법들 역시 반복해서 학습하고 작성하다보면 충분히 외워질겁니다. 다만 이걸 지금 꼭 외우고 넘어가야하는가 하면 저는 그렇지는 않은 것 같아요.백엔드 개발자라면 백엔드 개발과 관련된 부분에 좀 더 힘을 싣고 학습하는게 좋을 것 같습니다.프론트엔드 코드는 저도 아직 검색하여 작성하는 경우가 많습니다. 저도 자주 작성하지는 않거든요.물론 강의에서 사용한 코드 정도는 저도 대개는 외워서 작성하는 경우도 있긴 하지만, 이 외의 코드들은 상대적으로 IDE의 도움을 적게 받으면서 작성하는건 아직도 어렵습니다. 만약 프로그래밍 자체를 처음 배우는 사람이라면 외워서 작성할 수 있을 때까지 작성해보라고 권해드리겠지만, 지금 이미 백엔드 언어로 프로그래밍을 하고 계시기 때문에 그럴 필요는 없이 검색해서 작성할 수 있을 정도여도 괜찮을 것 같습니다. 길게 이야기 드렸는데, 혹시 또 궁금한 내용 있으면 질문 남겨주세요.감사합니다.

getStackTrace의 속도가 더 느리게 나옵니다

권선님 안녕하세요~실행 환경이 달라서 정확하게 비교가 된건지는 모르겠지만, 원래라면 getStackTrace가 더 빠르게 실행될 가능성이 높습니다. 권선님이 실행한 것처럼 결과가 나오는건 저도 현재 상태론 정확한 이유는 알 수 없네요 ㅎㅎ..다만, 설령 printStackTrace의 성능이 권선님께서 테스트 해보신 것처럼 조금 더 빠르더라도, 큰 차이는 아니고 예외를 더 적절히 로깅할 수 있다는 측면에서 getStackTrace를 사용하는게 더 좋을 것 같습니다. 궁금하셨던 내용인 getStackTrace의 속도가 더 느리게 나온 이유에 대해 속 시원한 답변을 해드리지 못해서 죄송합니다. (_ _)

블로그 포스팅 질문

Chan님 안녕하세요.강의 내용 정리해서 포스팅 하셔도 괜찮습니다~다만, 글에 강의 출처 남겨주시면 감사하겠습니다. (_ _)

질문있습니다!!

박철현님 안녕하세요~ 넵 말씀하신 내용이 맞습니다.스노우 플레이크를 사용하여 타임스탬프 기반의 정렬이 가능한 유일한 키를 생성할 수 있습니다. 이로 인해 기존의 Select(중복 여부 확인) 후 Insert 방식에서 중복 검사를 위한 비용을 줄일 수 있다는게 강의 내용이었습니다.거기에 더해서 URL 생성 작업을 비동기로 처리하고 클라이언트에게는 응답을 미리 전달하여, 실제 DB Insert 작업은 백그라운드로 진행함으로써 전체 시스템의 Latency를 낮추고 성능을 개선하는 부분도 이해하신 내용이 맞습니다. 😀 또 궁금한 내용 있으면 질문 남겨주세요.감사합니다.

컴파일 단계에서 발생하는 문법 오류에 대한 에러 정의 질문

수하님 안녕하세요~수하님이 이야기하신 "프로그램에서 복구할 수 없는 심각한 문제"는 자바에서 이야기하는 에러에 해당하는겁니다. (아래 트리에서 Exception과 같은 레벨에 왼쪽에 있는 것) (사진) 다만 이건 자바에서 "런타임에 던져지는 에러"를 우리가 에러라고 표현하지만, "에러"라는 표현의 자바에 국한된 표현이 아닙니다.다른 프로그래밍 언어에서도 에러라는 표현은 사용되고, 특히 코드의 문법이 잘못 작성되었을 때 발생하는 에러를 우리는 "컴파일 에러"라고 표현합니다. 아직 실행되지 않은 상태에서 발생하는 문제를 "프로그램에서 복구할 수 없는 심각한 문제" 라고 정의하는 것은 어폐가 있겠죠? 따라서 이를 구분해서 기억해야합니다. 수하님께서 이야기해주신 "에러"는 자바의 런타임에 던져질 수 있는 "프로그램에서 복구할 수 없는 심각한 문제"라고 이야기 할 수 있지만,에러는 다른 컨텍스트(맥락)에서 다양한 의미로 사용될 수 있습니다. 제가 강의에서 소개드린 "컴파일 에러" 처럼요. 혹시 궁금하셨던 내용에 대해 답변이 됐을까요?!또 궁금한 내용 있으면 질문 남겨주세요~감사합니다.

테스트 시나리오 작성에 대한 문의

BeakGwa님 기다려 주셔서 감사합니다!덕분에 잘 다녀왔습니다. 😀 질문 주신 내용에 대해 답변 드려볼게요. 시나리오는 어떤 기준으로 체크를 해 나가는게 나을까요? 단순 FE 클라이언트와 통신을 위한 api 서버라면, 화면 구성 기준으로 혹은, 실제 사용자 흐름 기준으로 시나리오를 작성해보면 될까요?혹은, 다른 좋은 테스트 방법이 있을까요?현재는, 모든 api 에 대해 기본적인 레이턴시 스펙 확인과 프론트 화면 기준 TPS 와 레이턴시를 확인하려고 합니다.이렇게 구성 시, 사용자가 접할 수 있는 시나리오 중, 최악의 시나리오의 TPS 결과가 서버 최대 동접자 수로 판단?-> 가능하다면 실제 사용자들이 서비스를 사용할 것 같은 형태로 시나리오를 작성해주시는게 좋습니다. 1-b에 적어주신 것처럼 프론트엔드에서 호출되는 API, 기타 API들을 구분하여 "최대한 실제에 가깝게" 시나리오를 구성할수록 좋습니다. 그러나 모든 API, 모든 유즈 케이스를 고려하여 시나리오를 작성할 수는 없기 때문에, 우리가 핵심적인 기능이라고 생각되는 요소에 집중하는게 좋긴합니다.예를들면, 인프런에서 할인 행사를 한다고하면 카카오톡, 이메일 등으로 이벤트 페이지의 링크를 발송하겠죠? 그럴 때 이벤트 페이지로 높은 트래픽이 들어올겁니다. 그럼 이벤트 페이지로 유입이 예상되는 유저들의 수를 계산해보고, 예상되는 트래픽을 이벤트 페이지로 접속했을 때 호출되는 API들을 기준으로 시나리오를 작성해보는겁니다.통상적으로 지금 남겨주신 Q&A의 경우 트래픽이 높진 않을겁니다. 따라서 상대적으로 성능 테스트 우선순위는 위의 할인 행사 이벤트 페이지보다는 낮을겁니다.일부러 최악의 케이스를 가정할 필요는 없지만, 보통 실제 예상되는 TPS보다 3~4배 정도의 양으로 테스트 해보시는게 좋긴합니다. 그렇게 됐을 때도 문제없이 트래픽을 처리할 수 있어야 예상보다 높은 트래픽이 오더라도 문제없이 처리할 수 있을겁니다. 현장에서 테스트 스크립트는 github 에 같이 올려 공유를 하게 하나요? 아니면 별도의 테스트 파일을 어딘가에 업로드 해서 팀원과 공유를 하게 되나요?-> 필요하다면 GitHub에 올려서 공유할 수도 있겠지만, 보통 nGrinder 같은걸 공용으로 구축해두고 사용하는 경우가 많은데요, 이때 nGrinder 내에 자체적으로 스크립트를 저장하는 기능이 있습니다. 폴더, 파일 형태로 나눠서 저장해둘 수 있어요. 이걸 주로 활용하고 있긴 합니다. 내용과 관련 없는 얘기지만... 현재 병목 지점을 명확하게 하기 위해, 모니터링 툴을 적용하려고 합니다. 취준생 관전에서 추천 하실 만한 툴이 있을까요?현재 api 서버 인프라 구성은, mysql, redis, enginX, springboot 로 구성되어 있습니다.고려하고 있는 조합은, Prometheus + Grafana 에, 여유가 된다면 스카우터 추가 생각하고 있습니다.-> 1번과 함께 이야기 드릴까 하다가 여기서 이야기 드립니다.성능 테스트와 개선을 진행할 때 유용한 2가지 도구가 있는데, 적어주신 Prometheus + Grafana 같은 '메트릭 수집 도구'와 다른 하나는 적어주신 스카우터나 Pinpoint 같은 APM 입니다. Prometheus + Grafana를 통해 메트릭을 수집해보면서, 트랜잭션 정보 같은건 APM의 도움을 받으시면 좀 더 효율적으로 성능 테스트와 개선을 진행해보실 수 있을겁니다. 메트릭 수집 도구만으로는 분명 한계를 느끼실겁니다. 1번이랑 이어서 더 이야기 드리고 싶은건, 애초애 취준생에게는 실제 서비스 같은 높은 트래픽도 없고 높은 트래픽을 감당할 수 있는 높은 비용의 인프라(서버)도 없습니다. 따라서 예상되는 TPS 자체를 정하는게 어려운 일입니다. 따라서 어느정도 시나리오를 만드시고, APM과 메트릭 수집 도구들을 활용하여 성능 테스트와 개선을 진행해보시기 바랍니다.이렇게 APM, 메트릭 수집 도구에서 병목을 찾아내고 개선하는 과정 그 자체가 취준생이 해볼 수 있는 현실적이고 좋은 성능 테스트, 성능 개선 학습 방법이라고 생각됩니다. 질문에 대한 답변은 여기까지고, 또 궁금한 내용 있으면 질문 남겨주세요~감사합니다.

테스트 시나리오 작성에 대한 문의

BeakGwa님 안녕하세요! 제가 현재 해외에 나와있어서 답변이 어렵습니다. ㅠ 목요일까지 답변 드리겠습니다!

Elasticsearch, logstash 세팅 시 오류 사항 공유

eriolshin10님 제보 감사합니다!맥북 M1 사용하시는분들은 적어주신 파라미터가 필요하겠네요~강의 자료에 업데이트 해두겠습니다. docker compose 관련해서 제안주신것도 감사합니다!