티셔츠의 기적
티셔츠의 기적, 당장 집에 있는 옷 찾아봐야 겠군여.
승근이의 LifeLog – We learn many things by imitation!
꽤 오래전이긴 합니다만, 중요한 포스팅이었던 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가 열렸었는데, 여기서도 디스크 용량을 늘리는 것에 대한 연구가 필요하다고 결론을 내리고 있네요.
잘 된다고 생각했었는데, 뭔가 이상하던구요. Incremental backup 이라고는 하지만, 매번 100MB 정도씩 백업이 발생하는 것도 그렇고, 맥북 전원을 껐다 켜면 매번 디스크를 못찾겠다는 것도 그렇고… 암튼 그래서 새로 지우고 다시 시도 중입니다. 대신 순서와 방법을 좀 바꿨는데 다음과 같습니다. 기본적으로 해야 할 일들은 아래와 동일합니다.
hdiutil create -size 200g -fs JHFS+X -volname "Backup" hostname_xxxxxxxxxxxx.sparsebundle
/Users 디렉토리를 제외한 모든 디렉토리는 백업 대상에서 제외하도록 옵션 수정, 백업 시작잘 될지 모르겠네요… 가장 큰 문제는 자동으로 백업이 안되고 매번 디스크를 찾아서 실행해야 했던 부분인데…
그리고 재밌는건 찾아본 문서에서 이미지 파일의 파일 시스템을 HFS+J 로 하면 된다고 했는데, 저의 경우는 아래 작성한거처럼 대소문자 구분이 안되는 파일시스템이라 백업할 수 없다는 메시지만… 아마도 한글 때문이라 생각되네요.
엊그제 Buffalo LinkStation LS-QL을 집에 들여놓게 되었습니다. 일전에 맥북이 맛탱이 가서 새로 설치한 경험이 있던지라, 맨 먼저 Time Machine으로 백업을 시도 했습니다. 근데, 메뉴얼에 있는데로 했더니 이놈이 제대로 동작하지 않더구요. 어찌 어찌 해서 결국 성공(현재 풀 백업 중) 했고, 아래는 그 과정입니다.
큰 문제는 없는 듯 하지만, 일단 환경 설정의 Time Machine이 on 되어 있다면 off해두는게 좋을 듯.
Web Admin tool > Shared Folders > Shared Folders Setup
그냥 만들면 되는데 Shared Folder Support 항목에 Apple이 체크되어 있는지만 확인하면 될 듯.
Web Admin tool > Time Machine
Time Machine Function을 enable로 설정하시고, Target folder는 앞에서 만든 디렉토리로 선택한 후 Apply 를 클릭합니다.
여기부터가 시키는데로 하면 안되는 부분 –;
2번에서 Time Machine을 enable 한 후 아래에 있는 Mac Information을 입력하고 Apply를 클릭하면, 백업용 번들 이미지를 생성시켜 주지만 정상 동작하지 않습니다. 그래서 일단 Admin tool에 있는 기능을 사용하지 않고 디스크 유틸리티로 직접 이미지를 생성하였습니다.
Mac의 디스크 유틸리티를 실행한 후, 새로운 이미지 버튼을 클릭하여 아래 화면과 같이 설정하여 새로운 이미지 파일을 만듭니다. 파일명과 포맷에 대해서는 아래 내용 참고하시기 바랍니다. (아래 이미지에서는 파일명이 .으로 구분되어 있는데 _으로 하는게 좋을 듯 합니다. 대부분의 문서에서 그렇게 되어 있어서.)
3번 단계에서 만든 이미지 파일을 1번 단계에서 만든 Time Machine 용 공유 디렉토리로 복사합니다. 그리고 터미널에서 아래 명령으로 파일 크기를 늘려줍니다. 이 부분은 왜 해야 하는지 잘 모르겠네요. 그냥 시키는데로… ^^
hdiutil resize -size 50g hostname.1234567890ab.sparsebundle
참고로, NAS에서 Time Machine을 enable하면 Finder의 왼쪽 공유 목록에 “NAS이름-TimeMachine”으로 컴퓨터가 하나 더 나옵니다. 거기에 보면 Time Machine 용으로 공유하는 디렉토리가 나옵니다.
이것도 시키는데로. 대략 읽어 보니, Time Capsule이 아닌 장비에서 Time Machine을 사용하려면 아래의 명령을 실행해야 한다고 하는 듯.
sudo defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1
Mac의 환경 설정에서 Time Machine을 켜고, 디스크 선택을 클릭해서 앞서 만든 NAS상의 Time Machine용 디렉토리를 선택합니다.
여기까지 하면 아마도 백업을 시작할껍니다. ^^
혹시 잘 안되면, Time Machine & Time Capsule support on your LinkStation 참고하시길. 제가 쓴 글은 이 문서를 기반으로 성공한 것이긴 하지만, 문서 내용과 틀린 부분이 있습니다. 특히 3단계 주의!
다음번에는 iTunes Media 서버 시도하기!!! 요건 더 힘들거 같은 느낌이.
일반적으로 성능 개선을 위해 동적으로 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 입니다. 아주 많은 브라우저들이 자동으로 생성해 준다는 것을 알 수 있네요.
오호 이런것이… ^^