티셔츠의 기적
티셔츠의 기적, 당장 집에 있는 옷 찾아봐야 겠군여.
브라우저 디스크 캐쉬 크기
꽤 오래전이긴 합니다만, 중요한 포스팅이었던 Performance Research, Part 2: Browser Cache Usage – Exposed! 를 보면, 실험 결과 웹 사이트 방문자의 40~60%는 empty cache로 접근한다는 내용이 있습니다. Steve Souder는 Call to improve browser caching란 포스팅에서 그 이유를 4가지로 추측하고 있는데, 그 중 가장 현실성 있는 대답은 “resources got evicted”라고 말하고 있습니다. 즉, 브라우저 캐쉬 용량의 제한으로 새로운 리소스가 저장되고 이전 리소스는 삭제되었다라고 판단하고 있습니다.
이를 해결하기 위한 방안으로는 1. 디스크 캐쉬 용량 늘리기, 2. 삭제 알고리즘(LRU 기반 알고리즘) 개선 두가지를 얘기하고 있습니다. 1번의 경우 브라우저가 기본 용량이 큰 상태로 출시될 때만 의미가 있을듯 하고(물론 사용자가 설정을 통해 수정할 수 도 있겠지만, 이런 방식으로는 대세에 전혀 영향을 못 미치겠죠.), 2번의 경우는 리소스의 타입에 따른 가중치를 부여한 LRU 알고리즘을 간단히 얘기하고 있습니다.
저의 경우야 개발을 위해 브라우저를 사용하는 빈도가 높아, 캐쉬를 가급적 작게 잡아 쓰고, Firefox의 경우는 메모리 캐쉬도 끄고 사용할때도 있긴 하지만, 일반적인 상황에서야 수백 GB의 디스크가 기본이라 수백 MB 정도를 브라우저 캐쉬로 사용한다고 해서 디스크 용량이 부족하진 않겠죠. 하지만 혹시 디스크 캐쉬 사이즈를 늘림으로 인해서 발생하는 문제점은 없을까요?
답이나 생각이 있는건 아니고, 그냥 궁금하네요. ^^; 웹 사용 측면만 본다면 전혀 문제될 것이 없을듯 하고, 오히려 성능 개선이 일어나는게 당연한 듯 한데… ㅎㅎ
참고로, Steve Souder 아저씨가 Browser Disk Cache를 통해 Browser Disk Cache Survey를 진행하고 있으니, 한번 참여해 보심이 어떠실지요?
그리고, 4월 초에 Mozilla Web Caching Summit가 열렸었는데, 여기서도 디스크 용량을 늘리는 것에 대한 연구가 필요하다고 결론을 내리고 있네요.
참고
Buffalo LinkStation과 Time Machine
2010. 5. 23 Updated
잘 된다고 생각했었는데, 뭔가 이상하던구요. Incremental backup 이라고는 하지만, 매번 100MB 정도씩 백업이 발생하는 것도 그렇고, 맥북 전원을 껐다 켜면 매번 디스크를 못찾겠다는 것도 그렇고… 암튼 그래서 새로 지우고 다시 시도 중입니다. 대신 순서와 방법을 좀 바꿨는데 다음과 같습니다. 기본적으로 해야 할 일들은 아래와 동일합니다.
- Time Machine과 관련된 모든 설정을 초기화 하고, NAS에 저장된 백업 이미지 및 해당 폴더를 모두 삭제했습니다.
- 백업용 이미지 파일을 먼저 생성했습니다. 디스크 유틸리티를 사용하지 않고 다음의 명령어로 직접 생성했습니다. 처음 생성시 이미지 크기를 200GB로 설정했고(아래의 크기 변경 과정은 수행하지 않았습니다), 파일명 규칙에서 hostname.ethernetid를 hostname_ethernetid로 변경했습니다.
hdiutil create -size 200g -fs JHFS+X -volname "Backup" hostname_xxxxxxxxxxxx.sparsebundle - NAS에서 backup만을 위한 별도 계정을 만들었습니다.
- 백업용 공유 폴더를 생성하고, backup user만이 접근할 수 있도록 권한을 설정하였습니다.
- NAS에서 Time Machine function을 enable하였습니다.
- NAS의 백업용 폴더에 이미지 파일 복사, 여기서 잠깐 컴 재부팅
- Mac에서 Time Machine on, 디스크 선택(위에서 작성한 폴더 선택하고 backup으로 로그인),
/Users디렉토리를 제외한 모든 디렉토리는 백업 대상에서 제외하도록 옵션 수정, 백업 시작
잘 될지 모르겠네요… 가장 큰 문제는 자동으로 백업이 안되고 매번 디스크를 찾아서 실행해야 했던 부분인데…
그리고 재밌는건 찾아본 문서에서 이미지 파일의 파일 시스템을 HFS+J 로 하면 된다고 했는데, 저의 경우는 아래 작성한거처럼 대소문자 구분이 안되는 파일시스템이라 백업할 수 없다는 메시지만… 아마도 한글 때문이라 생각되네요.
엊그제 Buffalo LinkStation LS-QL을 집에 들여놓게 되었습니다. 일전에 맥북이 맛탱이 가서 새로 설치한 경험이 있던지라, 맨 먼저 Time Machine으로 백업을 시도 했습니다. 근데, 메뉴얼에 있는데로 했더니 이놈이 제대로 동작하지 않더구요. 어찌 어찌 해서 결국 성공(현재 풀 백업 중) 했고, 아래는 그 과정입니다.
0. Mac의 Time Machine 설정 끄기
큰 문제는 없는 듯 하지만, 일단 환경 설정의 Time Machine이 on 되어 있다면 off해두는게 좋을 듯.
1. 백업용 공유 디렉토리 만들기
Web Admin tool > Shared Folders > Shared Folders Setup
그냥 만들면 되는데 Shared Folder Support 항목에 Apple이 체크되어 있는지만 확인하면 될 듯.
2. NAS의 Time Machine 활성화
Web Admin tool > Time Machine
Time Machine Function을 enable로 설정하시고, Target folder는 앞에서 만든 디렉토리로 선택한 후 Apply 를 클릭합니다.
3. Time Machine 백업을 위한 번들 이미지 파일 생성
여기부터가 시키는데로 하면 안되는 부분 –;
2번에서 Time Machine을 enable 한 후 아래에 있는 Mac Information을 입력하고 Apply를 클릭하면, 백업용 번들 이미지를 생성시켜 주지만 정상 동작하지 않습니다. 그래서 일단 Admin tool에 있는 기능을 사용하지 않고 디스크 유틸리티로 직접 이미지를 생성하였습니다.
Mac의 디스크 유틸리티를 실행한 후, 새로운 이미지 버튼을 클릭하여 아래 화면과 같이 설정하여 새로운 이미지 파일을 만듭니다. 파일명과 포맷에 대해서는 아래 내용 참고하시기 바랍니다. (아래 이미지에서는 파일명이 .으로 구분되어 있는데 _으로 하는게 좋을 듯 합니다. 대부분의 문서에서 그렇게 되어 있어서.)
- 파일명은 hostname_ethernetID.sparsebundle 이어야 합니다. 그리고 반드시 en0 인터페이스(유선 네트워크 카드)의 ethernet id를 사용해야 합니다. 위 항목은 시스템 환경설정에서 확인할 수 있습니다. enternet id는 :로 분리된 16진수로 나오는데 그냥 : 빼고 붙여주시면 됩니다. 만약 id가 12:34:56:78:90:ab 이면 1234567890ab 가 됩니다. 또, 디스크 유틸리티로 만들면 확장자를 sparseimage인 거 같기도 했는데, 그냥 sparsebundle로 바꾸시면 됩니다.
- 포맷은 반드시 대소문자구분, 저널링으로 선택해야 합니다. Web admin tool에서 이미지를 만들면 대소문자 구분이 안되는 이미지를 만들어 전체 백업이 되지 않습니다. 이 문제 때문에 이미지를 직접 생성해야 합니다.
4. 이미지 파일을 NAS에 올리고 크기 변경
3번 단계에서 만든 이미지 파일을 1번 단계에서 만든 Time Machine 용 공유 디렉토리로 복사합니다. 그리고 터미널에서 아래 명령으로 파일 크기를 늘려줍니다. 이 부분은 왜 해야 하는지 잘 모르겠네요. 그냥 시키는데로… ^^
hdiutil resize -size 50g hostname.1234567890ab.sparsebundle참고로, NAS에서 Time Machine을 enable하면 Finder의 왼쪽 공유 목록에 “NAS이름-TimeMachine”으로 컴퓨터가 하나 더 나옵니다. 거기에 보면 Time Machine 용으로 공유하는 디렉토리가 나옵니다.
5. Time Capsule이 아닌 장비의 Time Machine 지원 설정
이것도 시키는데로. 대략 읽어 보니, Time Capsule이 아닌 장비에서 Time Machine을 사용하려면 아래의 명령을 실행해야 한다고 하는 듯.
sudo defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 16. Mac의 Time Machine 설정
Mac의 환경 설정에서 Time Machine을 켜고, 디스크 선택을 클릭해서 앞서 만든 NAS상의 Time Machine용 디렉토리를 선택합니다.
여기까지 하면 아마도 백업을 시작할껍니다. ^^
혹시 잘 안되면, Time Machine & Time Capsule support on your LinkStation 참고하시길. 제가 쓴 글은 이 문서를 기반으로 성공한 것이긴 하지만, 문서 내용과 틀린 부분이 있습니다. 특히 3단계 주의!
다음번에는 iTunes Media 서버 시도하기!!! 요건 더 힘들거 같은 느낌이.
JavaScript 동적 로딩
일반적으로 성능 개선을 위해 동적으로 JavaScript를 로딩하도록 구성하는데,
var domscript = document.createElement('script');
domscript.src = 'main.js';
document.getElementsByTagName('head')[0].appendChild(domscript);
이 코드만 봐 왔었는데, 아래와 같은 방식이 있네요.
var ga = document.createElement('script');
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
ga.setAttribute('async', 'true');
document.documentElement.firstChild.appendChild(ga);
코드 내용을 보면 아시겠지만 Google Analytics에서 사용하던 코드이고, 2009년 12월 버전입니다. 위처럼 사용하는 이유는 document.getElementsByTagName('head')[0]가 null 일 수 있기 때문. 나라면 그럴리가 없겠지만, Google Analytics의 경우는 모든 상황을 고려해야 할 터이니 이해가 되네요.
그런데 위 코드를 좀 더 개선한 코드가 아래라고 합니다.
var ga = document.createElement('script');
ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(ga, s);
JavaScript를 동적으로 로딩하기 위해서는 무조건 script 태그가 존재할테니, document.getElementsByTagName('script')[0]는 null이 될 수 없겠네요. 이 코드는 마찬가지로 Google Analytics의 2010년 2월 버전입니다. 앞 코드의 경우 로딩되는 스크립트 태그가 정확히 어디에 붙을지 모를 수 있는데, 이러한 불확실성을 조금은 제거한거라 생각되네요.
마지막 코드는 jQuery에서 사용하는 방식입니다.
var head = document.getElementsByTagName ("head")[0] || document.documentElement;
// Use insertBefore instead of appendChild to circumvent an IE6 bug.
// This arises when a base node is used (#2709 and #4378).
head.insertBefore(script, head.firstChild);
재밌는 부분은 appendChild 대신 insertBefore를 사용했다는 점입니다. 주석에서 쓰여 있듯이. IE6의 bug(http://dev.jquery.com/ticket/2709, http://dev.jquery.com/ticket/4378) 때문이라는데, 이 부분은 찬찬히 확인해 봐야 할 듯.
본 글은 High Performance Web Sites blog의 appendChild vs insertBefore을 바탕으로 작성되었습니다.
추가적으로 appendChild vs insertBefore의 내용을 보면, 아래와 같은 내용이 나옵니다.
It turns out that not all web pages have a HEAD tag, and not all browsers will create one when it’s missing.
즉, 어떤 브라우저들은 HEAD 태그가 존재하지 않는 경우 자동으로 생성해준다는 것인데, 사실 대부분의 브라우저가 자동으로 HEAD 태그를 생성하는거 같습니다. 그 다음번 포스팅인 AutoHead – my first Browserscope user test을 보면 이를 위해 테스트를 수행했고, 그 결과 페이지가 AutoHead Browserscope User Test 입니다. 아주 많은 브라우저들이 자동으로 생성해 준다는 것을 알 수 있네요.
오호 이런것이… ^^
