DSO(Dynimic Shared Object) 방식은 mod_so.c 의 모듈을 기반으로 아파치 모듈이 개별적으로 로드 되어 질 수 있도록 해주는 방식이다. 즉, 추가로 모듈을 설치하기 위해 아파치를 재컴파일 하지 않고 모듈만 올려서 이용할수 있는 방식이다.
DSO는 아파치에 설치된 모듈이 필요할 때 시스템에 적재된다. 이는 클라이언트의 요청에 응답하는 요청시간이 다소 느릴 수 있지만, 하드웨어의 속도가 뒷받침된다면 해결이 될 수 있는 부분이다.
현재는 일반적으로 선호하는 방식으로 시스템의 리소스(메모리, CPU)들을 적절하게 효율적으로 사용한다고 볼 수 있다.
또 다른 방식인 Static 방식은 DSO와는 다소 차이가 있다.
이 방식은 아파치에 추가된 모듈이 아파치의 기동과 함께 모든 모듈을 포함하여 시스템에 적재한다.
만약 아파치의 기동과 함께 적재된 어떤 모듈이 클라이언트에 의해 거의 쓰지 않는다면 쓸데없이 시스템 리소스를 점유하고 있으므로 이는 비효율적이라 볼 수 있다. 또한 아파치와 각 모듈들은 설치시 복잡하다.
각 모듈과 설정된 아파치에 또 다시 모듈을 추가하려 할 때 아파치와 모듈을 다시 컴파일하여야 한다.
※ DSO 방식에 configure --enable-rule=SHARED_CORE...로 컴파일된 경우, 실행 파일이 libhttpd.ep가 됩니다.
앞에서 말한 DSO를 사용하면 다음과 같은 장점이 있다:
- 실제 서버 프로세스가 컴파일시
configure 옵션대신 httpd.conf의 LoadModule을 사용하여 실행중에 결합되므로 서버 패키지 실행이 더 유연하다. 예를 들어 한번의 아파치 설치만으로 다른 서버(표준 버전과 SSL 버전, 최소화 버전과 기능추가 버전 [mod_perl, PHP3] 등)를 실행할 수 있다.
- 서버는 설치후에도 제삼자가 만든 모듈을 사용하여 쉽게 확장할 수 있다. 최소한 기업의 패키지 제작자는 아파치 핵심 패키지와 별도로 PHP3, mod_perl, mod_fastcgi 등을 추가 패키지로 만들 수 있어서 큰 이득이다.
- DSO와
apxs를 가지고 아파치 소스 트리 밖에서 작업하고 apxs -i와 apachectl restart 명령어만으로 현재 개발한 모듈의 새 버전을 실행중인 아파치 서버에 반영할 수 있어서 더 쉽게 아파치 모듈을 개발할 수 있다.
DSO는 다음과 같은 단점이 있다:
- 프로그램의 주소공간에 코드를 동적으로 읽어들이는 기능을 지원하지않는 운영체제가 있기 때문에 모든 플래폼에서 DSO를 사용할 수 없다.
- 유닉스 로더가 심볼을 찾아야하기 때문에 서버 시작이 약 20% 정도 늦어진다.
- 서버는 위치독립코드(position independent code, PIC) 때문에 절대주소지정(absolute addressing)보다 느린 상대주소지정(relative addressing)의 복잡한 어셈블러 기법이 필요하므로 어떤 플래폼에서 실행시 약 5% 정도 늦다.
- DSO 모듈을 다른 DSO기반 라이브러리(
ld -lfoo)에 링크할 수 없는 플래폼이 있기때문에 (예를 들어 ELF기반 플래폼은 지원하지만 a.out기반 플래폼은 보통 이 기능을 지원하지 않는다) 모든 종류의 모듈에 DSO를 사용할 수 없다. 다른 말로 DSO 파일로 컴파일하는 모듈은 아파치 핵심과 아파치 핵심이 사용하는 C 라이브러리(libc)와 다른 동적/정적 라이브러리, 위치독립코드를 담고 있는 정적 라이브러리 아카이브(libfoo.a)의 심볼만을 사용할 수 있다. 다른 코드를 사용하려면 아파치 핵심이 그것을 참조하던지, dlopen()으로 직접 코드를 읽어들여야 한다.
