made by C.L

Delivery Condition :

delivery size : 10~500K (avg 300KB) file
total file size : 1TB
Request per sec -
Minimum : 3000 Requests / sec
Average : 9000 requests / sec
Peak : 36000 Requests / sec
Inactconn : 150,000 / Average
enforce object ttl : 1Day (NO REFRESH/MODIFIED ignore)
daily cache average area size (following ttl time) : most 8.2GB
peak transmit rate : 400MBps
Memory : 16GB

Additional Information
Storage : 3ware sata raid5
capacity : 4TB
Transferating Speed :  READ 190MB/s / ( actually most 30MB/s  left bandwidth for handle cache server, we have a lot of writing, and reading for another service.)


Current Configuration
Using Squid
only first level caching on memory
no secondary level caching

Problem : never cache again when the object has been expired.
1day -> cached object -> 1days over(2days) -> cached object has been expire also purge memory -> 2Days after -> the object never cache again -> user request this -> direct pass throught to origin server

We got a serveral I/O hazard when the expired object is issued in our site by users.

Tried aufs secondary level caching with async i/o , but the result is very poor.
if you have setting like that, you cannot make a traffic over 250Mbps

I'll trying to install squid version 3.
Actually there is no solutions, except zeus web server.
(i saw the report which zeus performance results, it is good for this case,
but still have memory caching problems for seperate process sharing)

Tried Solutions
varnishd - it supporting useful configuration, the vcl have much feather than squid's.
but we got a serveral memory bugs. it isn't perfect yet. do not use to production.
and there is no cache replacement logics such like as LRU, Greedy dual size freqs.
this is very important logic when you operating over memory only system.

lighttpd - too very slow. that is not optimized for cache usage

apache - don't think.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by LeCieL

잡스런팁 몇가지

1. 물론 모르는 사람이 있겠나 싶지만..

select ~ limit 0,30;

하면 0을 기준으로 30개의 record 를 가져온다.

그리고 limit 30,30 을 하면 30번째 row offset 을 건너뛰고 뒤에 30개를 가져온다.

그러나 이 limit 은 인덱스 시킹을 하여 스키핑을 하는것이므로 실제 칼큐레이셔닝이 도는것과 마찬가지다.

따라 i/o 부하가 발생한다.

궁금하다면 데이터를 1억개 가량 삽입하고 limit 90000000,30; 을 때려보라 시간이 얼마나 걸리나.

이건 innodb 에 국한된것이 아니다.

이를 편리하게 넘나들기 위해서는 오라클의 rowid (rowcounting) 기능이 있다면 금상첨화겠지만.. 없으면 삽질해야한다.


2. hbs 에 사용된 기법중 한가지이지만 지금은 내렸다., 페이징쿼리시 number error correcting 중 골때리는 방식중 한가지가 있다 -_-
리스트의 최상위 pk를 기준으로 별도의 해당 페이지의 페이징 테이블에 인서팅하여 이값을 range selecting 을 통해 근접대 값을 sum적용하여 지워진 글에 대한 갯수를 구해온다.
정확하지는 않지만, 나름 외부로 티나지 않게 깨끗한 방법중 한가지였다.
문제는 정확하지가 않는다는것이다.
또한 게시물이 삭제될 경우 해당 range 에 prepare value를 삽입하였다가 나중에 pk가 리스트를 읽을때 근접 영역에 합산시켜버려야 한다.
별로다 -_-

3. PK (Primary Key)를 기준으로 select 를 해올때 편법적으로 negative numbering 을 사용하는 경우가 있다.
pk 를 -1 부터 시작해 음수로 반환시키는 방법이다.

그리고 별도의 no 값등을 통해 이를 서치하는 방법이다.

별문제가 없을것 같은가..

문제가 있다 -_-

대략 15만개의 레코드를 넘어서면 그 이전의 경우 pk가 아닌 다른 index 값 (예: no) 등을 통해 select 를 하면 order 방식을 삽입된 pk 의 순서대로 (그러니까 이경우는 정상이다) 로 가져오지만

그 영역을 넘어서면 mysql 은 이상동작을 하게된다.

무슨말이냐면 1000, 999, 998 식으로 select한 결과가 나와야하는것이 정상이다.

select ~ where no < 160000 limit 30;
을 때리면 요쯤까지는
159999, 159998, 159997, 159996 ~ 등 번호가 역순으로 잘나온다 생각하겠지만..

where no < 1000 limit 30; 을 때리면..
여기선 1,2,3,4 가 나온다는것이다 -_-

자체 인덱스 처리형식이 그렇다고 한다. pk 가 아닌 index 로 range selection 을 주지 않도록 신경쓰자 -_-

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by LeCieL