그리드에 이미 뿌려진 로컬 데이터를 웹으로 가서 다시 추출하는 것보다 당연히 로컬에서 원하는 값을 추출하는 것이 빠른 것은 당연지사... 게임 디비 98만여개의 데이터에서 상위 유저 정보 검색이나 그런 기능에서 한바탕 붙었습니다.

닷넷 개발자 >> 이런 건 MS-SQL Report 서비스로 하면 깔끔하고 이쁘게 나옵니다.

컴맹 >> 대부분 아시겟지만 결과물을 실무자 차원에서 엑셀이나 csv로 받길 원하죠

닷넷 개발자 >> 그렇더라도 통합된 개발환경에서 만들어진다는 것이 유지 보수에 편합니다

컴맹 >> 이미 로컬 그리드에 받아 놓은 98만 여개의 데이터를 다시 웹 서버까지 가서 sort하고 퀄리 올리고 하는 것은 느릴 뿐 아니라 비효율적입니다

닷넷 개발자 >> 요즘 서버 성능이 얼마나 좋아졌는데 그런 것을 문제 삼습니까?

컴맹 >> 시뮬레이션 해서 쿼리를 날려보시면 아시겠지만 몇 초 동안 정지되는 보틀랙이 나타납니다. 좋은 방법이 아니죠 그러면 sp로 최적화를 좀 해주셔야할 것 같습니다. 전 컴맹이라 sp를 몰라서요

닷넷 개발자 >> 몇 년동안 썼던 구조인데 뭐가 문제라는 겁니까? 느리면 쿼드 코어 서버로 바꾸면 되지...

컴맹 >> 근본적인 구조 문제를 최적화 하지 않으면 문제가 됩니다.

닷넷 개발자 >> (@$$^$&&$&$^@) ....

단순하게 1회용 암호 인증 키를 보내주는 서버가 필요하게 되었다. 구조도 간단하여 인디로 만들고 파이썬을 붙여서 시드 키와 옵션을 설정할 수 있게 한시간 동안 쓱싹 만들었다.

닷넷 개발자 >> 만든 건 봤는데, 동작은 하긴 하네요. 서버 프로그램은 서비스를 올리거나 IIS에서 올리는 것이 안전합니다. 그럴 때 필요하라고 닷넷이 존재하는 겁니다.

컴맹 >> 그럼 서비스로 변경하죠. (20분 후 서비스로 돌았다.)

닷넷 개발자 >> 메모리 릭이나 안정성에 문제 없습니까?

컴맹>> 인디 기반이라 동접은 초당 2천 정도에서 잘 동작합니다. 아시다시피 스팩 상 OTP가 나가는 것이 초당 500회이기 때문에 문제가 안됩니다.

닷넷 개발자 >> 유저가 늘어나면 어떻게 확장할 겁니까?

컴맹 >> 서비스를 하나 더 추가해서 로컬 유저가 접속할 때 랜덤하게 서버 서비스에 접속하면 됩니다. CPU 부하가 문제라면 DNS 기반이니 DNS 라운드 로빈을 하면 되고, 유지 보수 효율이 문제면 가상화로 하이퍼 - V로 확장하면 됩니다.

그러나 닷넷 개발자는 DNS 라운드 로빈이나 하이퍼 V라는 걸 몰랐다. 설명에 설명을 하고 말싸움을 하길...

닷넷 개발자 >> 그런데 왜 스크립트를 파이썬으로 했나요? 이런 건 XML로 해야 유지 보수 편한 거 아닌가요?

컴맹 >> 조건 문하고 변수 4개에 함수 8개입니다. XML은 구조상 조건문에 따른 함수 할당이나 그런 쪽 구현히 힘듭니다. XML은 데이터 타입과 데이터를 가진 미니 디비일 뿐입니다.

닷넷 개발자 >> 그게 말이 됩니까? XML이 최고인데! 안되는 것이 뭔가요?

컴맹 >> 알다시피 온라인 게임에서 XML이 퇴출되기 시작한 이유가 바로 XML 파싱이 느리다는 점 때문이고 XML은 스크립트 언어의 확장성이 부족하다는 점 때문인데 팀장님 같으시면 XML을 조건문하고 변수 4개, 함수 8개로 구성을 어떻게 하시겠습니까?

결국 된다고 우기는 모드로 전환. 그럼 해보고 성능 비교해보자고 말을 끊었습니다....

단 사흘 일 봐주는 건데 계속 되는 딴지로 약속된 개발 기간이 넘어가는 상황이 계속 발생할 것 같습니다.

믿는 사람으로써 "오직 예수!"라는 표현을 그리 좋아하지 않는데

IT 업계에서는 "오직 MS!"만 소리치는 인간들이 있군요...

쓰기 편하고 빨리 개발하고 안정적이면 장땡인데... 낼 오전까지 두고 보고 개발의 싹수가 안 보이면 그만 GG치고 나갈 예정입니다.

http://blog.naver.com/testcode