개발하는 시스템의 업무내용상 사용자에게 어떤것이 이로울지 생각해봅니다.
그리고 제공되는 h/w의 탄력성(?) 도 생각하는게 좋겠지요.
딱 한군데 깔려서 생명을 다 할 수도 있겠지만 다른 환경에 설치되는 수 도 있으니까요.
보통 많이 처리 할 수록 좋기야 하지만 응답시간이 너무 길어지면 안좋으므로 어느정도 유효한 응답시간이 필요한 상황이라면 h/w, s/w 적 상황을 적절히 계산해서 유동적으로 MAX를 운용할 수도있겠죠.
이 경우는 유동적일 뿐, MAX는 있는것입니다.
그리고 MAX를 없는 쪽으로 생각해봅시다.
그런데 그 서비스를 제공하는 시스템이 견뎌주는 선이 있을테니까 connection이 많아져 다운되는 그 선을 넘으면 안되겠죠?
물론 시스템에서 그 서비스에 할당하는 리소스의 한계를 고정했다면 해당 서비스에선 MAX가 없어도 리소스상 MAX에 도달하면 시스템에서 제어를 해 줄테니 MAX connection은 정하지 않았지만 실제로 어떤 제한은 있는 셈이네요
위의 경우 모두 MAX connection이 유동적이거나 없거나 하니 동적인 자료구조를 써야하는데...double linked list등이 있겠는데
서비스의 내용상 구성요소(connection)를 랜덤하게 접근하는게 필요하다면 좀 난감하네요. 순차적으로 브라우징 하는 방법 뿐이니까요.
이 경운 리스트가 일정 크기가 넘어갈때마다 해당 위치 인덱스를 하나씩 두고 참조하는것도 차선의 방법이겠네요.
제목처럼 서버프로그램을 하면서 동적자원 할당을 해본적이 없습니다. 할 필요성도 못 느끼구요. 결국 항상 최대값을 결정하고 프로그램을 만들었다는 말이죠.
무제한이라는 말은 사실상 무의미 합니다. 예산에도 언제나 제한이 있고 현재 나와 있는 하드웨어에도 서비스의 기획에도 제한은 존재합니다. 기술적인 문제가 됐든 아니면 정책적인 면에서 고려가 되든 반드시 한계를 정해야 합니다.
다다익선이면 물론 좋지만 처음 프로그램 작성을 시작할때 한계를 명확히 제한하 않으면, 나중에 뻥쟁이가 되거든요. 심한 경우에는 계약위반이 될수도 있습니다.
안정적인 서비스가 가능한 인원이 1000개의 연결이라고 가정해보죠. 그 이상도 연결을 할수 있도록 만들어 1500개의 연결을 허용했습니다. 우와 1000정도가 최곤줄 알았는데 1500까지나 연결됐어 하고 좋아할 사람은 없다고 생각합니다. 500을 더 허용한 덕에 1500개의 모든 연결이 버벅 거릴테니 말입니다. 애초에 1000에서 연결을 더이상 허용하지 않았다면 1000개는 원할하게 서비스를 받고 있었을 겁니다.
개인적으로 "내가 만든 시스템은 제한이 없어"라고 말하는건 의미가 없다고 생각합니다. 자신이 만든 프로그램조차도 파악하지 못하고 있는거라고 생각하기 때문입니다.
개발하는 시스템의 업무내용상 사용자에게 어떤것이 이로울지 생각해봅니다.
개발하는 시스템의 업무내용상 사용자에게 어떤것이 이로울지 생각해봅니다.
그리고 제공되는 h/w의 탄력성(?) 도 생각하는게 좋겠지요.
딱 한군데 깔려서 생명을 다 할 수도 있겠지만 다른 환경에 설치되는 수 도 있으니까요.
보통 많이 처리 할 수록 좋기야 하지만 응답시간이 너무 길어지면 안좋으므로 어느정도 유효한 응답시간이 필요한 상황이라면 h/w, s/w 적 상황을 적절히 계산해서 유동적으로 MAX를 운용할 수도있겠죠.
이 경우는 유동적일 뿐, MAX는 있는것입니다.
그리고 MAX를 없는 쪽으로 생각해봅시다.
그런데 그 서비스를 제공하는 시스템이 견뎌주는 선이 있을테니까 connection이 많아져 다운되는 그 선을 넘으면 안되겠죠?
물론 시스템에서 그 서비스에 할당하는 리소스의 한계를 고정했다면 해당 서비스에선 MAX가 없어도 리소스상 MAX에 도달하면 시스템에서 제어를 해 줄테니 MAX connection은 정하지 않았지만 실제로 어떤 제한은 있는 셈이네요
위의 경우 모두 MAX connection이 유동적이거나 없거나 하니 동적인 자료구조를 써야하는데...double linked list등이 있겠는데
서비스의 내용상 구성요소(connection)를 랜덤하게 접근하는게 필요하다면 좀 난감하네요. 순차적으로 브라우징 하는 방법 뿐이니까요.
이 경운 리스트가 일정 크기가 넘어갈때마다 해당 위치 인덱스를 하나씩 두고 참조하는것도 차선의 방법이겠네요.
서버에서 동적자원 할당을 시도해 본적이 없네요.
제목처럼 서버프로그램을 하면서 동적자원 할당을 해본적이 없습니다. 할 필요성도 못 느끼구요. 결국 항상 최대값을 결정하고 프로그램을 만들었다는 말이죠.
무제한이라는 말은 사실상 무의미 합니다. 예산에도 언제나 제한이 있고 현재 나와 있는 하드웨어에도 서비스의 기획에도 제한은 존재합니다. 기술적인 문제가 됐든 아니면 정책적인 면에서 고려가 되든 반드시 한계를 정해야 합니다.
다다익선이면 물론 좋지만 처음 프로그램 작성을 시작할때 한계를 명확히 제한하 않으면, 나중에 뻥쟁이가 되거든요. 심한 경우에는 계약위반이 될수도 있습니다.
안정적인 서비스가 가능한 인원이 1000개의 연결이라고 가정해보죠. 그 이상도 연결을 할수 있도록 만들어 1500개의 연결을 허용했습니다. 우와 1000정도가 최곤줄 알았는데 1500까지나 연결됐어 하고 좋아할 사람은 없다고 생각합니다. 500을 더 허용한 덕에 1500개의 모든 연결이 버벅 거릴테니 말입니다. 애초에 1000에서 연결을 더이상 허용하지 않았다면 1000개는 원할하게 서비스를 받고 있었을 겁니다.
개인적으로 "내가 만든 시스템은 제한이 없어"라고 말하는건 의미가 없다고 생각합니다. 자신이 만든 프로그램조차도 파악하지 못하고 있는거라고 생각하기 때문입니다.
산넘어 산
댓글 달기