세션 처리 방식.... 정보
세션 처리 방식....
본문
세션을 그누보드5에서 사용하는 data에 저장하는 방식과 db에 저장하는 방식중 어느것이 더 효율적일까요?
세션을 db에 저장하고 세션 삭제는 다음 로그인 할때 사용자가 자동으로 지우도록 설정했는데....
이렇게 사용 할 경우에도 db 세션 일괄 삭제 기능을 넣는게 좋을까요?
일단은 정상적으로 작동을 하는듯 하네요. 혼자서 테스트 하는건 정말 쉽지 않군요.....ㅡ_ㅡ;;
추천
0
0
댓글 18개
DB에 저장하는 방식을 이용해 보았으나 방문자가 많은 사이트는 과부하가 걸리는 것으로 확인 되었습니다.
물론, 실험 방법이 잘못 되었을수도 있습니다. ㅡㅡ
물론, 실험 방법이 잘못 되었을수도 있습니다. ㅡㅡ
그렇군요. 그냥 세션을 db에 넣으면 어떨까하고 해보았습니다.
그럼 db 저장 방식을 사용자가 선택적으로
사용 할 수 있게 두가지를 사용 할 수 있도록 수정 해야 겠습니다....^^
그럼 db 저장 방식을 사용자가 선택적으로
사용 할 수 있게 두가지를 사용 할 수 있도록 수정 해야 겠습니다....^^
L4 로드벨런서 아래에서
동작하는 웹서버들의 세션을 공유하려고 db세션을 구현해봤었는데요.
접속자가 폭주하면 서버가 뻗어버리더군요. 일정수준 넘어가면 db sleep이 늘어나서 서버가 hang에 걸립니다.
해외의 사례처럼 memcache session 이나 redis 를 이용하는 것이 바람직해보입니다.
동작하는 웹서버들의 세션을 공유하려고 db세션을 구현해봤었는데요.
접속자가 폭주하면 서버가 뻗어버리더군요. 일정수준 넘어가면 db sleep이 늘어나서 서버가 hang에 걸립니다.
해외의 사례처럼 memcache session 이나 redis 를 이용하는 것이 바람직해보입니다.
사용하지않는 세션이 삭제 되어도 부하가 심하게 걸릴까요?
갑자기 어느정도의 접속자가 폭주해야 서버 행에 걸리는지 알수가 있을지 또는 쉽게 테스트 할 방법이 따로 있을까요?
갑자기 어느정도의 접속자가 폭주해야 서버 행에 걸리는지 알수가 있을지 또는 쉽게 테스트 할 방법이 따로 있을까요?
제 환경이 특수했을수도 있습니다.
서버가 오래되어서 디비엔진를 myisam밖에 쓸수 없었거든요. select와 update가 동시에 일어날때 myisam이 table-level-locking이 걸리니까 문제였겠죠.
현재는 세션데이터를 자주 지워주고 update빈도수를 낮춰서 적용해두었습니다.
서버가 오래되어서 디비엔진를 myisam밖에 쓸수 없었거든요. select와 update가 동시에 일어날때 myisam이 table-level-locking이 걸리니까 문제였겠죠.
현재는 세션데이터를 자주 지워주고 update빈도수를 낮춰서 적용해두었습니다.
제생각도 안쓰는 세션데이터를 지워주면 문제가 적을것 같은데...
테스트를 안해 봤으니 장담은 못하겠네요....ㅠㅠ
테스트를 안해 봤으니 장담은 못하겠네요....ㅠㅠ
세션을 삭제하는것 자체도 부하지요~ ^^
쌓이는게 문제가 아니라 디비액세스가 문제가 되는거지요~~
쌓이는게 문제가 아니라 디비액세스가 문제가 되는거지요~~
그런 문제가 또 발생 하는군요...^^;;
어차피 세션이 임시저장데이터들이라면.. db를 사용할때 메모리 디비를 사용한다면, 부하가 그닥 안심할것 같기도 한데... 심하던가요? ㅠ
만들어만 보았지 테스트는 아직 못해보았습니다.
회원 접속이 폭주하는 사이트가 없어서.....ㅠㅠ
회원 접속이 폭주하는 사이트가 없어서.....ㅠㅠ
특정 벤치마킹자료에서는 파일세션을 쓰는것이 성능저하의 주범이라고 보는 시각도 있더군요.
메모리를 활용하는게 낮다 라고 하던데, 메모리디비는 메모리를 활용하는걸로 봐야할까요? 디비를 활용하는걸로 봐야할까요; ㅎㅎㅎ
메모리를 활용하는게 낮다 라고 하던데, 메모리디비는 메모리를 활용하는걸로 봐야할까요? 디비를 활용하는걸로 봐야할까요; ㅎㅎㅎ
현재 나누미 사이트에서 몇년째 사용중인데 이상없이 잘돌아가긴 합니다.
회원 동시접속이 폭주하지 않으니 서버다운현상까진 가보질 못했네요....ㅎㅎ
회원 동시접속이 폭주하지 않으니 서버다운현상까진 가보질 못했네요....ㅎㅎ
파일을 불러와서 생기는 cpu의 부하나 db에서 불러와서 생기는 부하나 그놈이 그놈일듯 하긴한데
요즘 추세가 db를 괴롭혀서 만드는 비동기가 추세이기도 하고
디비서버 예전처럼 픽픽 죽어나가지도 않지 않나요??
요즘 추세가 db를 괴롭혀서 만드는 비동기가 추세이기도 하고
디비서버 예전처럼 픽픽 죽어나가지도 않지 않나요??
여러사이트가 같이 물려있어서 db서버 죽으면 안되죠....ㅠㅠ
암튼 db로 세션을 유지하는건 계속 써오곤 있는데 아직 문제가 없으니....
판단은 사용자에게 맡기는걸로 하고 전 빠져 나갈렵니다....ㅎㅎ
암튼 db로 세션을 유지하는건 계속 써오곤 있는데 아직 문제가 없으니....
판단은 사용자에게 맡기는걸로 하고 전 빠져 나갈렵니다....ㅎㅎ
아무래도 모든 컴퓨터부품중 (CPU, RAM, HDD) 하드디스크 속도가 제일 느리기 때문에
가급적 하드디스크 좀 그만쓰자! 라는 취지인것 같습니다. 가급적 메모리에 올려서 캐싱데이터로 처리하고... 하드디스크 엑세스를 줄이면 그만큼 성능향상이....
사실 하드디스크에 자료내놔! 라고 CPU가 명령한뒤 CPU는 멍때리는 시간이 엄청 많을테니까요. ㅎㅎ
가급적 하드디스크 좀 그만쓰자! 라는 취지인것 같습니다. 가급적 메모리에 올려서 캐싱데이터로 처리하고... 하드디스크 엑세스를 줄이면 그만큼 성능향상이....
사실 하드디스크에 자료내놔! 라고 CPU가 명령한뒤 CPU는 멍때리는 시간이 엄청 많을테니까요. ㅎㅎ
어디 누군가에게 들은 이야기라 정확한건 아니지만...
세상모든 demon중에 젤로 버벅거리는게 i/o관련이라고..
그래서 scsi가 -_-;;;;
세상모든 demon중에 젤로 버벅거리는게 i/o관련이라고..
그래서 scsi가 -_-;;;;
웹서버 4대에 라운드로빈으로 운영중인 서비스가 있습니다.
디비서버는 SSD 이고 내부 네트웍으로 연결된 상태입니다.
세션은 디비에 넣어서 사용중입니다.
아직까지 세션으로 뻗은적은 없네요.
디비서버는 SSD 이고 내부 네트웍으로 연결된 상태입니다.
세션은 디비에 넣어서 사용중입니다.
아직까지 세션으로 뻗은적은 없네요.
좋은 정보 감사합니다....^^
