2.업무영역

2.1비동기 통신

  1. form의 onload event에서 수행하는 transaction은 비동기 통신으로 구현합니다.

  2. 동기 통신을 사용할 경우 서비스 응답시간이 늦어 질 경우 응답이 오기 까지 화면이 멈추어 있는 현상이 발생될 수 있습니다.

2.2화면 단순화 및 분할

  1. 다수의 Component로 구성된 복잡한 형태의 화면의 경우 브라우저 사양에 따른 성능 저하가 발생될 수 있습니다.

  2. 이러한 복잡한 화면의 경우 초기에 반드시 보여주지 않아도 되는 경우, 특정 영역을 Division등으로 구성하여 후 처리 할 수 있도록 개선 합니다.

  3. 주로, CS형태의 화면을 컨버전하는 경우 이러한 형태가 많으며 문제가 발생하기 이전에 초기에 개발자 가이드등을 통해 인지가 되도록 합니다.


  - 페이지가 다수의 컴퍼넌트로 구성되고 상당히 길게 구성되어 있는 경우 
    팝업으로 구성하거나, 나누어 볼 수 있도록 구성
  

 - 기본 페이지를 보이고 난 후 나머지 페이지는 후 처리

2.3TabPage

  1. 다수의 TabPage로 구성되고 각 페이지가 url link되어 있는 경우, 성능이 나오지 않는 다면 preload 옵션을 false로 하여 성능을 개선 합니다.

  2. TabPage를 url로 link 하지 않고 컴퍼넌트를 직접 올려 사용하는 경우, 최대한 간결하게 구성하도록 하며 다수의 컴퍼넌트로 구성되는 경우 URL Link로 페이지를 분리 및 preload 속성을 적용하여 초기 로딩 시간을 단축 하도록 합니다.


 - Tab의 preload 속성

2.4Event Fire

  1. For 문등으로 다수의 작업이 진행되고, 이 문장내에서 각 컴퍼넌트의 속성값등을 변경 할 경우 event가 fire 됩니다.

  2. 이와 같은 처리를 할 때는 event를 off하여 속성변경에 따른 불필요한 구문을 줄일 수 있습니다.

 this.Dataset01.set_enableevent(false);
 for(var i=0;....) {
    ....
    this.Dataset01.setColumn(i,"COL01",...);
 }
 this.Dataset01.set_enableevent(true);
 this.Grid01.set_enableredraw(false);
 for(var i=0;......) {
   ....
   this.Grid01.setProperty(...
   ...
 } 
 this.Grid01.set_enableredraw(true);

2.5Grid Expression

  1. 이벤트 발생시 그리드에 보여지는 데이터 건수 만큼 expression문이 수행되기 때문에 그만큼 시간이 소요되며 업무에 따라 사용유무를 결정하되 가급적 서버에서 처리하여 결과값을 던져주는 방식으로 변경하는게 좋고 동적으로 변경해야 하는 부분이 있어 사용해야 한다면 반복문등 성능에 문제가 없는지 점검 해야합니다.

  2. 데이터가 많을 경우, expression은 최소화 및 최대한 간결하게 처리하여야 합니다.

  3. 데이터변경, 스크롤등시 그리드영역은 다시 표현되어야 하므로 이때 마다 expression은 다시 수행되므로 이를 고려 하여야 합니다.

그리드
expr:comp.parent.fn_Compare(...)

화면
this.fn_Compare = function()
{
   this.Dataset01.findRow(...);
   this.Dataset01.filter(...)
   return;
}

* expression의 구문 처리가 복잡할 수록 그리드 성능은 떨어짐.

2.6통신 후 후처리 간결화

  1. 조회,저장 이후 실제 서비스 수행 시간 대비 응답속도가 늦는 경우 응답이후 처리 문장 점검이 필요합니다.

  2. 확인이 어려울 경우 서비스 시작, 끝, CallBack 이후 수행문장별 수행시간등을 로그로 남겨 원인을 추적 합니다.

2.7대량 데이터 처리

  1. 대량의 데이터를 조회 할 경우 처리에 따른 대기 시간으로 인한 사용자의 불편함과 다량의 데이터를 메모리에 적재하여 메모리 한계 문제도 발생될 수 있습니다.

  2. 대량데이터는 페이징 처리, 조회 조건 상세화, 조건 제한등을 통해 사전에 문제가 발생하지 않도록 검토가 필요합니다.


 -

2.8데이터셋을 이용한 파일전송

  1. 소량의 파일로 제약하는 경우 무관하나, 이러한 제한이 없는 경우 파일 전송 및 수신은 file up/download 기능을 사용하도록 합니다.

  2. 대량의 파일을 데이터셋으로 전송,수신하는 경우 일괄처리에 따른 PC 및 서버 비용이 증가 됩니다.

2.9open 창 제약

  1. HTML의 경우 application.open 즉 HTML의 window.open을 사용할 경우 엔진을 다시 로드 및 파싱하는 절차를 거칩니다.

  2. 이로 인하여 PC성능이 좋지 않거나, 네트워크 환경이 좋지 못한 경우 성능 이슈가 발생될 수 있습니다.

  3. 가급적, 브라우저 내부에서 실행되도록 창을 구성하거나, MDI형태로 구성하도록 권장하며 open창은 최소로 사용하도록 합니다.

2.10IE8 스크립트 중단 메세지

  1. IE8의 경우 한번의 스크립트 수행 시 5백만개 이상의 명령을 수행하는 경우 경고 메세지를 출력합니다.

  2. 이와 같은 메세지를 발생하지 않기 위해서는 스크립트가 과도하게 수행되지 않는 지 확인 하고, TIMER등을 사용하여 스크립트를 분리해서 수행하도록 합니다.


  - 스크립트 중단 메세지
for(var i= ......) {
   ....
 }

 * timer를 이용하여 분리
 
 for(var i= ......) {
   ....
    if(i == 1000) {
        tnis.tempLoop = i;
        this.setTimer(1,10);
        return;
    }
 }

2.11resize, visible

  1. size를 변경하거나 visible 속성을 변경 또는 동적으로 컨텐츠를 생성하는 경우 웹브라우저는 해당 시점 마다 redraw 및 reflow가 발생됩니다.

  2. 과도하게 많은 컨텐츠를 담고 있는 페이지에서 이러한 동작이 빈번히 반복된다면 성능상의 영향을 받게 되므로 이를 고려하여야 합니다.

// form loading 시
this.form_onload = function(...)
{
    this.div00.set_visible(false);   // reflow , redraw
    this.div00.set_height(0);       // reflow , redraw
     ....
}

2.12이벤트내 과도한 스크립트 처리

  1. 이벤트 내에서 과도하게 많은 스크립트가 수행되면, 이로 인한 체감 성능이 떨어 질 수 있습니다.

  2. 특히, 그리드 및 데이터셋등의 이벤트 내에서 점검이 필요하며, 다수의 이벤트가 중복 수행되지 않도록 주의 하도록 합니다.

2.13화면전환속도

1. 보통 MDI화면과 같은 형태로 구성을 하므로 자주 발생하는 유형입니다.

2. 복잡한 화면을 많이 열어 놓은 상태에서 자주 발생합니다.

3. 열어 놓은 화면 갯수가 많아서 발생할 수 있습니다.

4. 단순한 화면만 열어 놓은 경우에도 간혹 발생 할 수 있습니다.

열어 놓은 화면이 많을 수록 메모리 점유율 상승, DOM객체 증가등 이로 인해 화면 전환시 수행해야

할 작업도 증가하여 속도 저하가 발생합니다.