과대 Division,TabPage

사용

공통화면을 Division, TabPage사용하여 URL로 연결하여 많이 사용할 수록, depth가 깊을수록, 요청해야 할 파일이 많고 이에 따른 처리 로직에 따라 화면의 로딩 속도는 저하됨

- 가급적 depth가 1레벨 안에서

최소 사용

- URL을 이용한 서브폼 연결 지양

- Tab인 경우 preload = false 설정

과대 js 파일 include

거의 자식폼을 포함한 모든폼에서 공통 js 하나에 모든 js 스크립트를 include하고 있어 js파일 사이즈가 크면 클수록 폼파일 로딩 속도 보다 js 파일 로딩 속도가 일반적으로 더 걸린다

- 꼭 필요한 js만 include

- Js파일 사이즈가 클경우 스크립트를 여러 개의 파일로 나누어 작성

- 공통적으로 많이 쓰는 js는 제일 상위에 include

- 가급적 js 파일 내에서 다른 js파일 include 사용 자제

- Js 파일은 2레벨 이하로 include 권장

동기(SYNC) 통신

동기통신은 통신 수행이 완료될 때 까지 화면의 모든 동작을 멈추게 됩니다. 여러 개의 동기 통신이 있을때 순차적으로 하나씩 실행하게 됩니다 하지만 비동기 통신은 동시에 여러 개의 통신을 사용할 수 있습니다

비동기 통신 권장

대량 Dataset값 가공

통신 완료후 조회된 데이터 건수 만큼 여러 반복문을 써서 dataset의 특정 컬럼의 값을 가공하는 경우 데이터 건수가 많으면 성능에 지대한 영향을 미칠수 있고 dataset 의 값이 변경될 때 마다 Event가 발생하여 바인딩된 모든 component가 껌벅이는 현상이 발생합니다

- 단순한 dataset 컬럼값 변경은

서버(framework 또는 쿼리)에서 처리

- FireEvent true/false 설정

그리드 Expr 사용

그리드에서 Expr 실행은 data가 load되거나 폼의 활성화, 그리드 선택시 데이터 건수만큼 다시 expr를 표현하기 위하여 그리드를 다시 그리기 때문에 이를 과도하게 사용할 경우 속도가 느려질 수 밖에 없습니다

- 불필요한 Expr 제거 하거나

복잡한 Expr 구문을 최대한

단순화

- 단순한 Expr 구문은 서버에서

처리

- 데이터량을 최소화

대량 데이터 처리

대용량의 데이터를 조회하는 경우 모든 데이터를 dataset에 담아 전송하는 경우나 또는 조회된 데이터 모두를 압축하여 전송하게 되면 서버에 과부하가 발생하게 되며 여러명이 동시에 서비스 요청시 메모리 부족 오류가 발생하게 됩니다

- CSV 통신, FirstRow 방식을

통해 데이터를 분리하여 전송

(CSV:여러Dataset 전송,FirstRow: 하나의 Dataset 만 전송 가능)

- 페이징 처리

리소스(res) 파일 사이즈 크기

어플리케이션 기동시 startxml에 기술된 압축 이미지 파일인 리소스 파일을 불러와 메모리에 적재시키는데 파일사이즈를 최소화 하여 전송속도나 실행 pc의 메모리 사용량을 최소화 해야 합니다

- 사이즈가 크고 사용빈도가

작은 이미지는 URL로 연결

- 불필요한 이미지 제거

- 1M 이하로 파일 사이즈 유지

동기 통신 보다

비동기 통신 권장

순차적으로 하나씩 처리되는 동기통신에 비하여 비동기 통신을 사용하면 병렬처리를 할 수 있기 때문에 화면 Loading 및 처리 속도는 상당히 차이날 수 있습니다. 여러 개의 동기 통신 요청시 어느 하나가 문제가 생기면 대기 시간이 오래 걸릴 수 있어 시스템 전체에 영향을 미칠 수 있습니다