1. Connection을 줄여라.
10초마다 랜덤한 이미지를 DB에서 뽑아와 화면에 뿌려주는 AJAX 루틴이 있다고 하자.
언뜻 보기에 특별한 문제없이 쉽게 구현될 것처럼 보이지만, 실제로는 DB와 HTTP 서버에 꽤 부담을 주게 된다. 실제로 가장 많은 리소스와 시간이 소요되는 것은 바로 이 커넥션 할당부분이다. 알고리즘은 최적화시키고, 데이터는 인덱싱이라도 할 수 있지만, 커넥션 자체에 소요되는 시간은 어떻게도 줄일 수가 없다.
HTTP 프로토콜은 이른바 상태유지가 불가능하다. 그래서 DB 커넥션을 계속 유지하는 것은 어렵다. 물론 EJB등에서 상태세션빈이라든가, 혹은 PHP에서라도 커넥션 유지가 아주 불가능한 것만은 아니다. 다만, 이렇게 커넥션 리소스를 물고 있게 되면 서버자원이 낭비되고 그 결과 다른 접속자의 접속시도가 제한되게 된다. 따라서 대개의 HTTP통신은 Request를 하고 Response가 돌아오는 짧은 시간동안만 커넥션을 물고 있게 한다.
이런 관계로, 10초마다 AJAX를 이용해 이미지를 뽑아오는 기법같은 건, 평균적으로 한 사용자가 1분간 페이지를 유지한다고 하면, AJAX를 쓰지 않았을 때보다 상대적으로 600%의 커넥션 소모를 일으키게 된다.
사장님께 가서 서버와 회선이 모자라니 600% 증설해주세요.. 라고 하자.
권고사직되고 싶지는 않고, 10초마다 랜덤이미지를 1분간 보여주고 싶다면…
AJAX를 쓰지말고 그냥 일반 페이지를 request할 때, 한번의 커넥션 상태에서 6장의 이미지를 랜덤하게 뽑아 JavaScript 혹은 JSON 혹은 숨겨둔 HTML…로 보낸 후, 그냥 JavaScript로 10초마다 로테이팅 시키자.
1분이 모자른 듯 싶다면 아예 10분어치를 한번에 쿼리해서 가져오는 것이 9분 어치가 안쓰여도 AJAX를 쓰는 것보다는 더 이득이다.
2. 메인 컨텐트에 AJAX를 쓰지마라.
카테고리나 메뉴나 광고에 AJAX를 쓰는 것 까지는 좋다.
그러나 메인 컨텐트에 AJAX를 쓰지 말 것.
JavaScript가 disable한 상태이거나 회선불량이라던가, Script Error라든가… 이런 경우 컨텐트가 없는 빈 페이지만 덩그마니 남게 된다.
메뉴나, 사이드바같은 건 어찌되도 좋아, 안보여도 좋고. 허나 메인 컨텐트는 안보이면 안되지…
이 페이지의 핵심기능이 최신글목록이라면, 최신글목록 만은 AJAX를 쓰지 말라는 뜻.
꼭, 반드시 AJAX를 써야겠다면, 그 경우에도 아무것도 없는 빈 컨텐트를 AJAX로 가져와서 채우지 말고, 일단 서버스크립트로 최초 컨텐트는 채워둔 후에, 필요에 따라 AJAX로 변경하는 것은 봐줄만 하겠다. 그래야 AJAX가 안되어도 빈 페이지를 보고 있는 일은 없을 테니까.
3. 크리티컬하지 않은 것만 AJAX를 쓰자.
일단 AJAX를 쓴다 함은, 대개, 현재 보고 있는 페이지와 URL이 매칭되지 않는다는 뜻. 리마커블하게 링크가 걸려야하는 컨텐트, 페이지들은 AJAX를 자제함이 좋다.
그럼 어떤 경우가 AJAX이용에 적당할까?
검색결과페이지는 상대적으로 URL이 덜 중요한 페이지이다. 내용이 수시로 바뀌는 메인 인덱스 페이지라면 AJAX를 써도 크게 상관은 없겠다.
또 덜 중요한 기능- 커멘트 작성같은 -들은 URL과 상관없기 때문에 AJAX로 구현해도 무방하겠다.
4. DB 쿼리보다는 스태틱 빌드를 노려라.
어떤 컨텐트 데이터가 수정, 삭제는 거의 일어나지 않되 추가는 종종 일어나고, 조회는 그 몇배로 자주 이루어지고 있다면, 이에 대한 view를 AJAX로 직접 컨트롤하려는 것은 매우 어리석은 일이다.
이런 경우에는 스태틱 빌드를 쓰자.
데이터가 변경될 때마다 해당 컨텐트를 파일로 만들고(HTML이든, XML이든, JSON이든…) AJAX로는 이 빌드된 파일을 접근해서 읽어오는 쪽이 훨씬 효율적이다.
왜냐하면,
이렇게 빌드된 파일은 다른 사용자들도 동일한 쿼리를 위해 DB커넥션을 할 필요가 없이 바로 그 결과를 파일로 공유할 수 있기 때문이고,
AJAX에 장애가 생겨도 이 파일 주소를 페이지안에 link 나 longdesc로 명기해두었다면 접근성등에 문제가 없어지며,
파일을 읽는 속도가 DB에 연결하는 속도보다는 훨씬 더 빠르기 때문이다.
만약 쿼리가 여러 종류이되 많은 사용자 사이에서 반복되어 나오는 종류라면 최초 쿼리 시에만 DB에서 조회한 후, 그 결과를 파일로 만들고 그 파일이름을 쿼리의 해쉬값을 이용해서 관리하면 여러종류의 쿼리에도 대응할 수 있겠다. 물론 이 경우에는 사용자 맞춤 컨텐트 같은 것에는 약간 힘들 수도 있긴 하다.
5.로드밸런싱(?)
현실적으로 비싼 로드밸런싱 장비를 사용하지 못한다면, 혹은 여러대의 웹서버를 돌릴 수 없다면…
(그런데, 대부분의 웹서비스는, 사실 왠만한 리눅스머신가지고도 훌륭히 퍼포먼스를 낼 수 있다. 이런 커넥션의 낭비만 아니라면…)
간단하게는 서브도메인을 이용해서 일시적으로 커넥션을 늘려서 응답을 빠르게 할 수도 있겠다.
예를 들어 이미지는 image1.sample.com, image2.sample.com, image3.sample.com (내부적으로는 모두 같은 이미지서버)에서 번갈아가며 가져오도록 HTML코드를 작성하고 (그럴려면 일반적인 막코딩으로는 힘들고 별도로 템플릿생성엔진같은 것을 써야하겠다.), ajax call같은 경우에도 ajaxserver1.sample.com, ajaxserver2.sample.com, ajaxserver3.sample.com(역시 내부적으로는 같은 서버)로 분산 호출하게 되면 커넥션이 늘어나게 되어 응답이 빠르다.
그러나 이 방법은 서버의 리소스 사용량을 늘리게 되고, 사용자가 워낙 많은 경우에는 그 시간동안 다른 사용자의 커넥션이 제한되므로 꼭 좋은 방법이라고만은 할 수 없겠다.
AJAX의 오남용을 보고 있자니, Anti-AJAXian이 될 것 만 같은 이 찜찜함…
0개의 댓글