- DOM 우선 고려해야할 Performance Tuning
카테고리 : 튜닝정보 2006/10/30 16:57 Dom 객체를 선언할때 흔히들
var node = document.createElement("div");
위와 같이 선언하여 사용하게 되는데 이 경우는 느린 출력 결과를 보인게 된다.
아래는 내가 작성한 간단한 Performace 튜닝의 결과이다.
DOM, InnerHTML을 이용한 방법이다.
소스를 가져다가 테스트 해보세요.. 직접
<------------------------------------------------------------------------->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<TITLE> New Document </TITLE>
<META NAME="Generator" CONTENT="EditPlus">
<META NAME="Author" CONTENT="">
<META NAME="Keywords" CONTENT="">
<META NAME="Description" CONTENT="">
<script>
function aa()
{
var st = new Date().getTime();
var tNode = document.getElementById("test");
for(var i=0; i<5000; i++)
{
var node = document.createElement("div");
node.innerHTML = i+'번째 생성';
tNode.appendChild(node);
}
var t = new Date().getTime() - st;
var tmNode = document.getElementById("time");
tmNode.innerHTML = ('DOM으로 작성된 시간:'+t);
}
function bb()
{
var st = new Date().getTime();
var tNode = document.getElementById("test");
var h = '';
for(var i=0; i<5000; i++)
{
h += '<div>'+i+'번째 생성</div>';
}
tNode.innerHTML = h;
var t = new Date().getTime() - st;
var tmNode = document.getElementById("time");
tmNode.innerHTML = ('InnerHTML으로 작성된 시간:'+t);
}
function cc()
{
var st = new Date().getTime();
var tNode = document.getElementById("test");
var h = new Array();
for(var i=0; i<5000; i++)
{
h[h.length] = '<div>'+i+'번째 생성</div>';
}
tNode.innerHTML = h.join(' ');
var t = new Date().getTime() - st;
var tmNode = document.getElementById("time");
tmNode.innerHTML = ('DOM으로 작성된 시간:'+t);
}
</script>
</HEAD>
<BODY>
<a href="javascript:;" onclick="aa();">돔으로 만들기</a>
<a href="javascript:;" onclick="bb();">innerHTML 만들기</a>
<a href="javascript:;" onclick="cc();">더 튜닝된 innerHTML 만들기</a>
<div id="test">
</div>
<div id="time">
</div>
</BODY>
</HTML>
<------------------------------------------------------------------------->
뭐 대충 테스트하기 위해서 만들어진 쏘스이므로 그냥 보시길 바랍니다.
테스트 결과는 다음과 같습니다.
DOM으로 작성된 시간 : 2734
InnerHTML로 작성된 시간 : 328
더 튜닝된 innerHTML 만들기 : 125
물론 사용자의 환경에 따라서 저 수치는 다를 수 있으나, 결과값을 저와 동일할 것입니다.
이 문서는 상당히 오래된 문서이면서도 가장 기본적이라고 생각됩니다.
함수 bb, cc의 차이점은 무엇인가?
두 함수는 어찌보면 동일해 보인다.
하지만 cc함수에서는 h라는 배열을 사용하여, 내용을 담고 마지막에 join(' ')문으로 다시 처리해준 것이다.
그것만 하더라도 약 2배의 향상된 속도를 보인다.
간단하지만 대단한 결과이지 않은가? ㅎㅎ;
DOM쓸때는 쓰고 innerHTML쓸때는 써야겠죠..
반복적으로 사용할경우 DOM은 사용자의 화면을 계속 멈추어 버리는 현상을 가져갑니다.
흠...
- javascript, dom, performance
- 얼라리얼 (ulariul)
- 크하하하.. 상두꺼...
- + 친구추가
- where 조건에서 지켰으면 하는 사항
카테고리 : 튜닝정보 2006/10/30 16:27 오래된 문서중에 꽤 쓸만한 내용이 있어서 가져온다.
where 조건에서 지켰으면 하는 사항들과 잘못된 사례를 몇가지 정리한 겁니다.
# 쿼리 튜닝은 WHERE 조건의 처리방식에서 시작한다.
- "인덱스를 파악한다."
=> 어떤 컬럼들로 인덱스가 만들어져 있는지 확인한다.
show index from 테이블명;
- "explain으로 execution plan 정보를 확인한다."
=> 인덱스를 사용하는지 확인한다.
여러 개의 인덱스가 사용가능하면 expected rows가 적은 것을 사용한다.
데이터 건수가 증가할수록 explain 정보가 변경될 수 있으니 지속적으로 모니터링한다.
- "where 조건에서, 컬럼을 연산하지 않는다."
=> 컬럼에 인덱스가 생성되어 있어도 인덱스를 제대로 사용하지 못한다.
잘못된 사례) pay_ok_dt에 인덱스가 생성되어 있는데 사용하지 못하고 full scan 하였음
explain
select dayofmonth(date) as pDay, count(*) as cnt
from table_a
where year(date) = '2005'
and month(date) = '07'
group by pDay;
튜닝 후)
explain
select dayofmonth(date) as pDay, count(*) as cnt
from table_a
where date >= '2005-07-01'
and date < '2005-08-01' group by pDay;
- "where 조건에서, 컬럼의 데이터 타입에 맞는 상수값을 사용한다."
=> 묵시적 데이터 타입 변환시 결과가 다를 수 있으며,
컬럼으로 인덱스가 생성되어 있어도 효율적으로 사용하지 못한다.
인덱스를 사용하더라도 컬럼값을 묵시적으로 형변환하게 되면 오히려 더 느려진다.
잘못된 사례) buy_date의 데이터 타입이 datetime인데 unixtime형태를 사용하여,
인덱스를 사용했으나, datetime을 unixtime으로 형변환을 하여 더 느려진다.
테스트 할려면 일자를 당일로 수정해야 buy_date를 사용함.
explain
select count(*) cnt
from item_use_v1
where buy_date >='1126567284' /* unixtime */
and item_lclss = 'S' AND item_mclss = '10' AND item_code != 'S190001';
튜닝 후)
explain
select count(*) cnt
from item_use_v1
where buy_date >='2005-09-13 08:21:24'
and item_lclss = 'S' AND item_mclss = '10' AND item_code != 'S190001';
- "where 조건에서는, != 보다는 = 처리를 한다."
=> equal 연산을 할 때 인덱스를 효율적으로 사용한다.
예외적으로, 다수의 대상들 중에서 특정 몇개를 제외시킬 경우에는 어쩔 수 없이 != 이나 not in을 사용할 수 밖에 없다.
잘못된 사례)
where mem_sex != 'm'
튜닝 후)
where mem_sex = 'f'
- "where 조건에서, like '비교문자%' 형태를 사용한다."
=> like 연산을 할 때 비교문자 앞에 %를 붙이면 full scan이 발생한다.
이럴 경우에는 기획 및 모델을 수정해야 한다.
잘못된 사례)
where noti_gubun like '%음악'
- SELECT * 보다는 사용할 컬럼을 지정한다.
=> 불필요한 컬럼의 조회를 제거하여 I/O와 트래픽을 줄임으로서 속도향상을 가져올 수 있다.
잘못된 사례)
select * from sessions where sess_id='kimo123';- db, 튜닝정보