장고에서 날짜와 시간을 다루다 보면 timezone 관련 예상치 못한 문제가 많이 일어난다.timezone 세팅을 해 줘야 하는데 가장 오류가 없게 사용하기 위한 방법을 찾았고정리를 해두려 한다 한국시간은 UTC+9 표준 시간보다 9시간 이후라고 보면 되는데 설정에서 USE_TZ = TrueTIME_ZONE = 'Asia/Seoul'설정을 해 두어도 일반적으로 사용하는 timezone.now()로고 정보를 가지고 오면timezone정보가 없는 표준시간으로 가지고 온다. 사용하기에 따라 다르겠지면 9시간의 차이 때문에 이래 저래 문제가 생긴다. 여러 시도를 해보았는데 가장 문제가 없는 방법은timezone.localtime()을 사용하거나timezone.make_ware( {{ datetime }} )형식..
장고에서는 테스트를 정말 잘 지원하고 있는데서비스를 운영하면서 테스트를 거의 작성하지 않으면서 하고 있다가서비스가 점점 커지면서 더이상 미루긴 힘들다고 판단TDD를 조금씩 도입하려 한다. 사실 예전부터 계속 시도하면서 조금씩 쓰고 있었지만 쓰지 못했던 이유가서비스는 이미 많이 진행되었고 테스트를 할 때마다 데이터를 생성해야 하는데 더미를 만드는 일이 너무 큰 일이라시간이 너무 많이 소요되고 이로 인해 긴박한 일정을 맞출수 없었기 때문이다. 테스트 디비를 사용하지 않고 테스트를 진행하려면장고 테스트를 쓸때 필요한 test runner라는 것을 설정 해야 한다 나는 장고 프로젝트를 진행할때 core라는 앱을 하나 생성해서 유틸들을 모아두는데core.test_util.py에다 러너를 이렇게 설정하고# -*- ..
운영하는 서비스에서 서버시간이 4분씩 늦게 흘러가고있었다 생각치도 못한 일이라서 ㅋㅋㅋ 찾는데 한참걸렸음 해결방법을 정리 일단 지금 설정된 시간 설정을 보는 명령어는 date 일반적으로 사용하는 타임서버의 시간을 보는 명령어는 rdate이다 없으면 apt를 이용해서 설치하자 sudo apt-get install rdate 타임서버 시간보기rdate -p timeserver 타임서버 시간 로컬로 맞추기(sudo 권한이 있어야함)rdate -s timeserver 주로 쓰이는 타임서버는 time.bora.nettime.kriss.re.kr이 두가지 인 듯 하다.
장고 쿼리 최적화에서 빼놓을수 없는것들 간단하게 정리하려고한다 https://docs.djangoproject.com/en/1.10/ref/models/querysets/공식문서를 보는것이 가장 좋다. selected_related와 prefetch_related는 둘다 쿼리를 생성할때 연관된 것들을 같이 가져오는 일을 한다. 하지만 실제로 동작하는 방식은 조금씩 다른데 selected_related를 보면 one to one 혹은 foreign key상황에서만 동작을 한다. 예를들어 주소(Address) 가족(Family) 구성원(User) 이라는 모델이 있다고생각을 해보면 id가 1인 구성원의 주소정보를 가져오기위해 일반적으로 이런 코드를 사용한다 user = User.objects.get(pk=1)..
최근들어 서비스를 운영하면서 업데이트이후 서버에 부하가 과도하게 걸리는 현상이 발생했다. 내부적으로 무척 많이 콜되는 api에서 업데이트를 하는 코드가 들어간게 문제였는데. 문제를 해결하면서 두 스토리지 엔진의 차이점을 찾아보았다. 간단하게 비교하면 MyISAM의 경우 InnoDB보다 먼저 개발되었는데select속도는 무척 빠르지만별로 지원하는 기능이 없다또 쓰기(insert, update)작업을 할 때 테이블 단위로 락을 걸어버리기때문에 업데이트 속도가 느리다는 단점이있다. InnoDB의 경우상대적으로 더 무겁지만데이터 무결성보장, 트렌젝션, 복구처리 등 여러 기능들을 지원한다 만들고자하는 제품의 구조를 보고 결정을 하면 될 듯하다.잦은 변경 혹은 생성이 일어나는 서비스에서는 InnoDB를아닌곳에서는 ..