당연히, 윈도우즈의 문제라고 생각했는데... 아니었다.
우선 나의 스토리를 늘어놓고..
특정 IE11에서 indexedDB의 동작이 느리다는 문제(분 단위 수준)를 보고 받았다.
때문에 timeout 지원이 가능한가 확인하고 느리면 대체 하는 방법을 사용하려고 조사하다보니, timeout을 지원하지도 않고, javascript는 single thread이기 때문에 억지도로 불가능하다는 결론을 내렸다.
결국 해당 시스템을 원격하기로 해서 내부 정보를 분석해봤다.
인터넷 옵션 -> 검색 기록 항목에서 설정 버튼 -> 캐시 및 데이터베이스 탭 -> 웹 사이트 캐시 및 데이터베이스 허용 체크항목을 이용하여 indexedDB를 끄고 켤 수 있기 때문에 값을 확인해보았는데, 이때 이 탭를 누른 순간 분단위의 시간이 걸리는 것을 확인하였다.
한단계 더 들어가서 registry의 항목중 HKCU/Software/Microsoft/InternetExplorer/BrowserStorage 아래에 위의 설정 값이 저장되는데, 신기하게도 이 값이 BrowserStorage 항목 자체가 없었다.. (물론 강제로 만들어줘도 나의 문제는 해결되지 않았다.)
어쩔 수 없어 API 호출을 전부 모니터링 하게되었고, 특이점을 한개 발견했다.
아래와 같은 호출이 이상하게 많이 발생하는 것을 확인하였다.
#RtlInitUnicodeString ( 0x13bdc634, "SCWRPPRWork_M" )
#NtOpenSection ( 0x13bdc630, SECTION_MAP_READ | SECTION_MAP_WRITE, 0x13bdc648 )
#NtMapViewOfSection ( 0x0000117c, GetCurrentProcess(), 0x13bdc67c, 0, 0, 0x13bdc670, 0x13bdc678, ViewShare, 0, PAGE_READWRITE )
#NtWaitForSingleObject ( NULL, FALSE, NULL )
#NtClose ( 0x0000117c )
SCWRPRR 로 구글링을하니 삼성 SDS의 PC-DRM이라는 녀석인 것으로 보여진다.
구버전 스타일인 sc stop PcdrmSvc 명령은 실패해서 포기하고, 프로그램 추가/제거에서 NSD 5.0을 제거하고 재부팅을 하고나니,
기분좋게도 캐쉬 탭은 바로바로바로 열리는 것을 확인하였다.
물론 내 문제였던 indexedDB도 바로 빠르게 접근 가능했다.
아마 DRM이 윈도우즈 시스템 전역의 파일 읽고 쓰기를 가로채면서 IE가 만들어 쓰려면 indexedDB의 file db 생성에 무엇인가 관여한게 아닌가 싶다.
이대로라면, 다른 DRM에 의해서도 비슷한 상황이 발생할 가능은 있을테니 또 발생하면 DRM을 의심해봐야겠다. :-)