Thank you for your patience and look at my article on some random preamble--from the start we go to Apache technology up--I want to put Apache with DSO mode the first time on content-because the Chinese Apche online technical information in basic does not have such content--and it in the Apache architecture in occupies more and more important status (in Apache1.3.17forwin32 version-DSO is already the default installation mode).
Then the DSO? indeed is DynamicSharedObjects DSO (dynamic shared objects), it is derived from the modern Unix operating systems exist in a dynamic connection mechanisms. It provides a run-time code of the special format, the program is running, you will need to part of the redeployment from out-of-core memory. Apache in 1.3 later versions after beginning to support it. Because Apache already use a module concept to extend its functionality and internal use of a list based on scheduling to link expansion module to Apache core module so that Apache was doomed to use DSO to load it at run time. The author of mod_rewrite and mod_ssl RalfS.Engelschall (in my opinion he is the true master of Apache and main developer of his personal home page of the famous "Apache1.3DynamicSharedObject (DSO) Support," on DSO mode principle has a relatively detailed description (this article is basically based on this). Let us first look at Apache's own program structure: this is a very sophisticated four-layer structure--each layer built on top of the next layer. The fourth layer is to use Apache module development of third-party libraries--such as openssl in General in Apache's official release this layer is empty, but in a real Apache structures in these library consists of layer structure must exist. The third layer is the number of optional additional functional modules such as mod_perl, mod_ssl. This layer of each module are typically implemented as a separate Apache separation of function and in fact these modules do not have a is required to run a minimum of Apache does not require any of this layer of the module. The second layer is the Apache's basic function library-this is the essence of the core Apache--this layer layer consists of the Apache kernel, http_core (Apache core modules), they realized the basic HTTP functionality (such as resource handling (by file descriptor and memory segment, and so on), keep the pre-build (pre-forked) child process model, listens to the configured virtual server TCP/IP Sockets, transfer to the HTTP request processing process to handle HTTP protocol status, read/write buffering, there are also many features such as attached URL and MIME header parsing and loading DSO, etc), but also provides Apache application program interface (API) (in fact, the real function of Apache or included in an internal module in the modules in order to allow complete control of the Apache process, the kernel must provide an API interface), this layer also includes general available code libraries (libap) and implementation of regular expression matching library (libregex) there is a small operating system abstraction library (libos). The lowest layer is the OS related platform application functions, the OS can be of different modern UNIX variant, win32, os/2, MacOS, or even if it is a POSIX subsystem. In this complex program structure is the fun part---in fact the third-and fourth-tier and second-tier is loose connection between, on the third floor of the module are interdependent--due to the structure caused by significant impact is the third-and fourth-tier code cannot statically connected to the lowest layer of the platform-level code. Therefore DSO mode becomes resolved it means. Combined with DSO features, this structure is very flexible, you can let the Apache kernel (technically be mod_so module rather than a kernel) at boot time (instead of install) mount the necessary parts to achieve third-and fourth-tier functionality. DSO in program run time will need to part of the redeployment from out-of-core memory access typically there are two ways: one is the ld program by the system automatically loaded when you start, the load can be achieved in two ways: one is automatically by the system in the executable program called ld.so to at the beginning. Another way is to manually, is implementing procedures in program system interface to the Unix loader through the system call/dlsym tdlopen () () to perform. So how did specifically Apache DSO features implemented? special DSO support call Apache modules is based on a named mod_so.c module, the module must be static compile Apache core. This is besides http_core.c outside only modules can be placed into a DSO itself (bootstrapping!). Virtually all of the other releases of Apache modules can be placed into a DSO by individually by setting the establishment by the DSO allows--allow possible-shared settings (see top-level INSTALL file of) or by changing the AddModule command in your src/Configuration to SharedModule command (see src/INSTALL file). A module is compiled into a DSO mod_foo.so's name, you can use mod_so's LoadModule command in yourIn the httpd.conf file in the service starts or restarts after the call to the module. In order to simplify it to Apache module DSO files are created (especially third-party modules), a new support program named apxs (APacheeXtenSion) being used. it can be used to build the modules based on DSO, module is located in the Apache source tree. The idea is simple: when Apache is installed, Setup allows Setup to install ApacheC header file and placed platform support for compiler and linker flags, used to establish the DSO files to apxs program. In this way, the user can use apxs to compile Apache module source code of it instead of Apache release source code tree and not manually added platform support for compiler and understanding the program's logo for DSO support. In order to place the compiled apache core program into a DSO library (only in some of the supported platforms to force the linker output Apache core code--a prerequisite for the DSO modularization) provides the SHARED_CORE must be able to set the--allow-require = SHARED_CORE settings (see top-level INSTALL file of) or by changing the Rule command in your Configuration file provides SHARED_CORE = yes (see src/INSTALL file) .Apache core code then is placed into a DSO library named libhttpd.so. Because static libraries cannot in all of the platforms are linked into a DSO, an additional named libhttpd.ep executable is created, the program will not only contain the static code and provide the main () function of the remaining parts, the httpd program finally been replaced with the bootstrapping code, which automatically determines the Unix Scheduler can load and start libhttpd.ep by providing LD_LIBRARY_PATH to libhttpd.so method implementations. Finally we come to talk about ApacheDSO mode supported platforms and its strengths and weaknesses--it should be said at present DSO mode Basic can run on any unix platform--in addition to ultrix (because it is not dynamic (library) loader: Nodlopen-styleinterfaceunderthisplatform). it has the advantage that the server package to more flexible at run time and the server package to be able to simply use a third-party modules to expand, even after the installation. But at the same time DSO mode also has some disadvantages such as: 1, does not work on all platforms such as said does not support dynamic connections ultrix. 2. Apache at startup slow about 20 per cent, because you want to do some preparation, and the code of UNIX Scheduler now need to do. Server on some platforms when in implemented 5% slower, because relative address code (PIC) sometimes in not necessary will need to recompile the relative addressing, so there is no absolute addresses fast. therefore sometimes DSO will not improve speed. 3, because DSO module will in particular platform and other DSO-based libraries (ld-lfoo) conflict (for example a.out-based platforms often does not support this feature, but ELF-based platform support)-you cannot be all types of module use the DSO mechanism (i.e., not all DSO modules can be loaded). Or change a word that is compiled as a DSO module document is restricted to only using the APACHE core code, APACHE core used by the C library (libc) and all other dynamic and static library, or static library file (libfoo.a) contains independent code. The only way to use other code is to determine the APACHE core itself or already contains its own reference, through dlopen () calls the code yourself, or build Apache allow SHARED_CHAIN rule (when your platform support not DSO library link DSO files). On some platforms (many SVR4 system) in the link when Apachehttpd executable programs have no way to force the linker output all all DSO uses address. but not visible to the Apache core code is the standard Apache modules can be used only as a DSO. is use the SHARED_CORE feature because it allows all of the code are mandatory. As a result, Apachesrc/Configurescript automatically enforces SHARED_CORE on these platforms, when DSO properties are used in the Configuration file or in the configure command line. Talked about so much--are the principles of things--like and I in the prolog of the practicability of some non-the-fact DSO in Apache is very important-is relatively high-end content-to use it you need to have an understanding of its principles-the other deficiencies in this article, we advise criticism-I will be in the next DSO mode used in the article explain how to use and the specific implementation of Apache's DSO mode. -----Note: references RalfS.Engelschall--Apache1.3DynamicSharedObject (DSO) Support software UK linux House Chinese translation.
No comments:
Post a Comment