요즘 짬짬이.. 정말 짬짬이 포럼 게시판 보수작업을 하고 있는데요.
특히 글쓰기에서 파일 업로드 부분을 좀 많이 개선했습니다.
물론 성능이 20~30% 정도 빨라졌고 자잘한 버그들을 개선한 거라서 여러분이 뭐 특별히 체감하긴 힘들겠습니다만... ^^;;
참 씰데없는 걸로 땀빼네.. 하실지도 모르겠습니다만, 뭐 취미삼아 하는 거니깐 맘이 가는 대로 작업을 하는 거지요.

사실 이번에 제일 손이 많이 간 것은 C++빌더 코드로 되어 있던 업로드 컴포넌트를 파스칼.. 그러니까 델파이 코드로 바꾼 건데.. 이 컴포넌트의 메인 코드가 포인터 연산이라 파스칼 코드로 바꾸는 데 좀 신경이 쓰이더군요. 아시다시피, 파스칼에서도 포인터를 충분히 쓸 수 있습니다만 아무래도 C++보다는 좀 덜 자유로와서...

잠도 안오고 일도 하기 싫은 김에 이 HTTP 파일업로드에 대해 생각나는 대로 주절거려보겠슴다.

원래.. 파일 업로드 부분은 델파이나 C++빌더의 5 버전까지는 아예 VCL에 없었습니다만 6 버전부터 파일 업로드가 지원되기 시작했습니다. VCL 6 버전에서 추가된 특정 유닛을 uses하거나(델파이) 링크하면(C++빌더) 파일 업로드가 지원되죠. 근데 이 VCL 6 이상 버전의 파일 업로드 부분이, 클래스 구현 면에서는 참 멋지게 설계되었습니다만, 성능 면에서는 엽기스럽습니다. 300, 400KB 정도까지는 무난하게 업로드가 됩니다만, 1메가가 가까워지면서 지나치게 속도가 느려지기 시작하다가.. 10메가 단위가 넘어서면 황당하게 속도가 느려집니다.

일전에 테스트로 200메가짜리를 업로드했더니 파일 데이터의 전송이 끝난 후로도 10분 이상 파싱이 안끝나고 버벅이더군요. 결국 IIS를 다시 시작시켰습니다. VCL 6 파일업로드의 소스코드를 보면 이런 극악의 성능을 보이는 이유가 있는데.. 뭐 한마디로 말하자면 200메가짜리 파일을 업로드하면 200메가짜리 스트링 변수를 쓰기 때문입니다. 물론 200메가짜리 스트링을 만들어도 그보다는 훨 낫게 할 수도 있는데도, VCL 코드를 보면 여러가지 부분에서 최악의 선택을 많이 했더군요. 결국 대용량에서 엄청나게 느린데다가 CPU 부하도 필요 이상으로 너무 많이 잡아먹습니다. 다만, 위에도 썼다시피 클래스 구조는 참 설계했습니다. (빛좋은 개살구???)

델파이와 C++빌더의 5 버전까지는 그런 극악의 클래스조차도 아예 파일업로드가 지원되지 않았기 때문에, 처음 포럼 게시판을 만들 때는(아마도 1999년 가을 정도였던 듯..) 파일 업로드 루틴을 직접 만들 수밖에 없었습니다. 그래서 C++ 코드로 파일업로드 컴포넌트를 만들었던 건데(며칠전에 파스칼 코드로 바꾸었지만).. 제가 사용한 방식은 대략 다음과 같은 시나리오로 되어있습니다.

1. 일단 HTTP POST로 전송받은 데이터를 그대로 통째로 하나의 파일로 저장합니다. (이 "폼 파일"에는 하나 혹은 복수개의 업로드된 파일과 기타 다른 자잘한 폼 데이터들이 같이 저장됩니다)
2. 그 파일을 메모리맵파일로 오픈해서 메모리 주소공간에 올려놓습니다.
3. 다음으로 이 메모리 공간에서 파싱을 합니다.

복잡하게 파일로 저장한 다음 메모리로 매핑한 이유가 있는데... 그냥 메모리에 버퍼를 만들어서 파일 데이터를 통째로 받아버리면, 버퍼 크기를 늘릴 때마다 메모리 재배치가 발생하기 때문에 1MB 정도만 업로드해도 서버의 메모리가 개판이 됩니다. 일반적으로 HTTP 전송에서 보통 한번에 8KB~40KB 정도씩 전송되는 것이 보통인데, 1MB면 한번 전송되는 블럭이 40KB라고 하더라도 25번이나 나누어서 전송하게 되고, 그때마다 realloc이 일어나면서 기존의 데이터를 복사하게 되는 비효율적인 일이 벌어집니다. 설상가상으로 업로드 데이터가 서버의 물리적 여유 메모리에 비해 대략 1/2 정도 이상 넘어가는 대용량일 경우에는 당연히 실제 메모리로는 모자라게 되므로, 1/2을 넘어서는 순간부터 매 블럭이 전송될 때마다 매번 하드디스크로 스와핑이 발생하므로 어쩔 수 없이 성능이 무쟈게 느려질 뿐 아니라 다른 일반적인 서버 동작의 성능에도 큰 영향을 미치게 됩니다. (여기서 실제 메모리 여유공간이 파일업로드 데이터의 두배가 되어야 스와핑이 일어나지 않는 이유는 realloc 때문입니다)

전송된 데이터를 파일로 바로 저장해버리면, 연속된 데이터에 대해 끊어지지 않는 일련의 주소공간을 가져야 하는 메모리와 달리 하드디스크 파일은 여러 클러스터에 걸쳐서 띄엄띄엄 저장될 수 있기 때문입니다. 따라서 한 파일에 새 데이터 블럭을 추가로 써넣어도 기존의 데이터가 재배치되거나 하지 않습니다. 그럼 왜 그걸 다시 메모리로 매핑하느냐 하면.. 파일로 저장된 상태에서 그대로 파싱하려면 파일 IO 함수를 사용해서 읽고 써야 하는데 절차가 메모리의 경우보다 복잡할 뿐 아니라 성능면에서도 떨어집니다. 따라서 파일을 메모리로 매핑해버리면 완전히 메모리로 다룰 수 있게 되므로 성능상이나 코드상으로도 훨씬 낫습니다.

그러면 대용량이 아니라 작은 용량이라서 메모리 버퍼에 직접 올리는 것이 나은 경우도 있지 않느냐, 라고 할 수도 있습니다만, 그렇게 작은 파일이라면 메모리 버퍼에 쓰거나 파일로 쓰거나 서버 장비에서는 사실 성능 차이는 거의 무시할 정도가 됩니다.

그래서.. 사실 대단한 것도 아니고 잔머리에 불과한 겁니다만, 어쨌든동, 제 업로드 컴포넌트는 상당히 빠릅니다. (자랑입니다^^;;) 당연히 VCL 6 이상의 파일업로드 루틴보다는 훨 빠르고요. 가끔씩 보이는 공개된 자작 파일업로드 클래스나 컴포넌트들보다도 빠릅니다. 요즘은 빌더나 델파이로 웹개발하는 분이 전보다도 더 줄어든 거 같아서 얼마나 필요할지는 모르겠습니다만 조만간 공개는 할 겁니다. 단지 지금 클래스 구조가 맘에 안들어서... --;;;

근데.. 델파이나 빌더도 그렇긴 하지만, 웹 개발 언어라고 할 수 있는 ASP에서도 파일 업로드는 기본 지원이 안됩니다. ASP.NET에서는 기본 포함이 되었는지 어떤지 모르겠습니다만.. 웹 개발 전문으로 만들어진 ASP에서 파일업로드조차 안된다는 것은 정말 웃기지요? 어쨌든 그래서 ASP 개발하다가 파일 업로드가 필요하면 액티브 서버 오브젝트를 사용합니다. 액티브 서버 오브젝트라는 것이 뭐 대단한 것은 아니고 일종의 액티브X인데, ASP 스크립트에서 불러쓸 수 있도록 된 액티브X지요. 이걸 ASP 컴포넌트라고 부르기도 합니다.

당연하지만, 용도와 하는 일은 똑같아도 제가 만든 것은 VCL 버전이기 때문에 ASP 컴포넌트로는 바로 못씁니다. 그래도 껍데기부분만 바꾸면 어렵지 않게 컨버팅할 수 있지요. 참고로 C++빌더와 델파이에서도 이 ASP 컴포넌트를 만들 수 있습니다. ASP 컴포넌트를 보통 VC++로 만드는 것을 생각해보면, C++빌더나 델파이로는 오히려 더 쉽게 만들 수 있지요.

파일업로드가 ASP에서 지원은 안해주고, 또 자주 필요한 기능이라서 파일업로드용 ASP 컴포넌트는 꽤 많이 나와있습니다. 상용도 여러개 있고 공개도 몇가지 되는 거 같더군요. 사실 저희 회사에서도 웹 개발 일이 꽤 많기 때문에 제 팀원들은 제 입사 전에 구매한 파일업로드 컴포넌트를 쓰고 있습니다. 이름이 사이트갤럭시던가...

참고로.. 제 파일업로드 컴포넌트가 꽤 빠르기는 하지만 가장 빠른 것은 아닙니다. 사실 제가 테스트해본 것들 중 가장 빠른 것은 데브피아에서 팔고 있는 덱스트업로드입니다. 왜 그렇게 빠른지는 대충 짐작은 갑니다만.. 뭐 제가 그렇게 못만들어서가 아니라, 빠른 대신 업로드 동안에 CPU 점유율이 제것보다 더 높이 올라가더군요. 결국 단일 업로드의 속도는 빠르지만 CPU 부하가 더 높아서 결과적으로 총 CPU 소요시간은 거의 비슷한 거 같았습니다. 단일 요청에 대해 빠르다고 하더라도 동시에 여러 요청을 처리해야 하는 서버에서 CPU 부하가 더 높은 것은 결과적으로는 좋다고 보이지 않아서 그런 방식은 쓰지 않았죠. 만약 디스크 파일이 아니라 DB상의 객체라면 요청들 사이에 데드락 같은 크로스 락의 가능성도 있고 해서 최대한 빨리 끝내는 것이 더 유리하겠습니다만. (더욱이 SCSII 하드라면 더욱 더)

주저리주저리 썰이 무쟈게 길었는데... (전혀 이해가 안되시는 분도 있겠지만 이런 웹개발 파트는 몰라도 밥벌이에 전혀 지장이 없는 분이 더 많을 겁니다) 제가 문득 글을 쓰고 싶어졌던 원래의 이유는... 제 VCL 컴포넌트의 껍데기를 좀 바꿔서 ASP 컴포넌트로 만들어서 공개로 뿌리면 쓰실 분이 얼마나 될까 해서요. 다른 조건 없이 완전 무료로 뿌리되, C++빌더 혹은 델파이로 만들었다는 크레디트 정도는 나오게 하면 어떨까 싶습니다. 업로드 컴포넌트를 사용하는 페이지에 조그만 Powered by C++Builder 혹은 Powered by Delphi 배너를 올리도록 한다든지...? 넘 과한 요구인감...? 뭐 30X8 정도의 크기면 아주 작은 크긴데.. ^^ 그게 비현실적이라면, 안타깝지만 소스 내에 크레디트를 올리도록 강제할 수도 있겠고...

어떻게 생각해보면, 이미 웹개발자들은 구입을 했든 혹은 공개를 쓰든 어떤 방식으로든 업로드 컴포넌트를 구해쓰고 있을 테니 제가 만들어뿌려도 갖다쓸 사람은 별로 없을 거 같기도 하고... 아리송하네요.