Mendix 첫 접속 지연 줄이기: 워밍업과 캐시

• 시리즈 7/16
• 개발
• Mendix 10
• 성능

오랜만에 접속하면 로그인 후 첫 화면이 뜨기까지 1분 넘게 걸렸고, 다시 접속하면 10초 안팎이었다. 목록 페이지를 오갈 때도 매번 서버 조회를 기다려야 했다. 서버 쪽은 주기적 워밍업으로, 화면 쪽은 브라우저 캐시로 대응했다.

첫 조회만 느린 이유

로그인 자체가 느린 것이 아니었다. 로그인 직후 열리는 대시보드가 전체 데이터를 조회하는데, 오래 사용이 없으면 DB가 그 테이블을 메모리 캐시에서 내린다. 첫 조회는 디스크에서 읽고, 그다음부터는 메모리에서 읽는다. 사진 컬럼 때문에 테이블이 2GB를 넘어 차이가 더 컸다.

서버: Scheduled Event 워밍업

1. Microflow 생성대시보드가 쓰는 조회 Java Action을 호출하고 결과는 버림. 액티비티 1개
2. Scheduled Event 생성위 Microflow를 15분 간격으로 실행
3. 런타임 설정 확인ScheduledEventExecution 값이 ALL인지 확인. 꺼져 있으면 실행되지 않음
4. 로그로 확인15분마다 조회 로그가 찍히는지, 다음 날 첫 접속이 빨라졌는지

mxruntime:
  ScheduledEventExecution: ALL

화면: 페이지 간 캐시 공유

Mendix는 페이지를 이동해도 window 객체가 유지된다. 3편에서는 이 특성이 문제였지만, 캐시에는 쓸모가 있다. 목록 페이지 4개는 같은 데이터를 날짜로 조회하고 점검 유형은 화면에서 나누기 때문에, 캐시 키에서 페이지 구분을 빼고 날짜 범위만 남겼다.

var CACHE_TTL = 10 * 60 * 1000;   // 10분

function loadList(from, to, force, onDone) {
  var key = from + '|' + to;      // 페이지 구분 없이 공유
  window._listCache = window._listCache || {};
  var hit = window._listCache[key];

  if (!force && hit && Date.now() - hit.ts < CACHE_TTL) {
    onDone(hit.data);
    return;
  }
  fetchFromServer(from, to, function (rows) {
    window._listCache[key] = { ts: Date.now(), data: rows };
    onDone(rows);
  });
}

// 저장, 삭제, 업로드 후에는 전체 무효화
function afterChange() {
  window._listCache = {};
  loadList(currentFrom, currentTo, true, render);
}

다른 사용자가 등록한 데이터는 최대 10분 늦게 보인다. 업무 특성상 실시간성이 중요하지 않아 받아들였다.

다음 단계: 결과를 미리 만들어 두기

워밍업과 캐시로 체감 속도는 해결했지만, 조회 자체는 여전히 무거웠다. 이후 대시보드와 목록 모두 스케줄러가 결과 테이블을 미리 만들고, 화면은 그 결과만 읽도록 바꿨다.

점검 목록

• 느린 것이 로그인인지, 로그인 직후 첫 화면의 데이터 조회인지 구분했는가
• Scheduled Event가 실제로 실행되는지 로그로 확인했는가
• 캐시 키가 서버 조회 조건과 정확히 같은가
• 데이터 변경 후 캐시를 지우는가

• #Mendix
• #ScheduledEvent
• #캐시
• #성능개선
• #대시보드
• #JavaScript