2024년 11월 28일 - STANL-2/MOTIVE GitHub Wiki

1. 엑셀 다운로드는 pony와 같은 것들을 이용해서 백에서 구현하는 것이 좋음
2. 검색 조건의 경우에는 1줄로 유지하면서 클릭하면 쭉 내려오도록 설정
3. grid에서 바로 새로운 grid 행을 만들어서 데이터를 입력후 들어갈 수 있도록 하는 것도 좋다.
4. 원하는 데이터를 드래그엔 드랍으로 추가하는 것도 좋다
5. hidden row로 row의 상태값을 두고, 서버로 날라오면 해당 메소드를 실행한다 (ex. create/update/delete)
6. 유입 경로를 기록하거나, 견적을 내본 부분들을 참고해서 해당 모델의 신차가 나오면 메세지 보낼 수 있도록 진행
7. 고객에 대한 고객 정보를 암호화 해서 유지
8. 고객의 구매 내역 보면 좋을 거 같음 + 포인트도 있으면 좋음
9. 하나의 서버를 더 띄우면 좋겠지만, 비용을 절감하기 위해서 가용하는 서버 안에 container를 하나 더 올려서, 의미는 없지만 ,was와 ~를 올려둬서 사용하는 방법 공유해보기
10. apm은 traffic은 탐지 가능하지만 DB 탐지는 불가능하다.
11. cloud watch를 사용해서 DB로 넘어오는 트래픽을 모니터링하면서 부하를 분산한다.

보여주면 좋을 것

• 제품 기준 정보 + 고객 기준 정보 => 계약 + 수주 + 납부 → 통계성 데이터

• 각 단계마다 kick이 될수 있는것들을 하나씩 필요할 거 같다

• 등록 절차가 지루하지 않도록 kick을 만드는게 좋을거 같다

• 제안하는 방향성으로 가는 것도 좋다.

• 성능 테스터

• → 로드러너 (매크로: 1pc에서 동일한 조건으로 계속 traffic을 발생시킴)

• → 역할별로 모니터링 담당자를 두고, 부하를 주고, 먼저 다운되는 곳을 리팩토링 한다. (각 서버를 모니터링)

• → 성능 테스트와 이중화 테스트를 동시에 진행

• 이중화 테스트

• → 하나의 서버를 죽였을때 잘 동작하는지

• → 로드밸런서로 원활하게 잘 나눠서 서버를 보내는지

• → 이중화를 통해서 session 유효를 따진다.

• selenuim으로 부하를 발생 시킬수있다

• 중요 포인트는 계속 지속적으로 서버에 부하를 주고, 그 부하에 따른 문제점을 잘 파악 후 수정하는 과정이 필요

• Tps는 낮다고 무조건 좋고, 높다고 무조건 나쁜거는 아니다 (초당 트랜잭션 수)

성능 테스트

• 클라이언트 유저수를 동시 접속 가능한 사용자 수를 얼마나 했는지를 먼저 지정 필요
• 처음 부터 50명이 한번에 들어와서 한번에 조회를 누르는 것이 아닌, 1명부터 계속 늘어나면서 늘어나는 수에 따른 동시 조회로 테스트 해보면서 응답속도의 유용한 데이터를 보여주는 것이 좋다

한번에 보내는 경우

• row 를 순서대로 전송 (순서를 맞춰서)

제안서 방향성

• 성능 테스트
• 등록 단계에서의 CKEditor
• 대쉬보드
• AI 서비스 ( 계약서 작성 완료하면 수주서에 연결할 수 있도록)
• 서버의 트랜잭션 변경시 시간 연장 & 시간 연장 눌렀을때 연장되도록