Practical tips set for Apache system management (2)-Principles of DSO mode

Source: Internet
Author: User
Article title: Apache system management practical skills set (2)-Principles of DSO mode. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
  
Thank you for your patience. I have read some random preface in my previous article. From this time on, we switched to the Apache technology. the reason why I want to put the Apache DSO mode in the content I explained for the first time is that in there is basically no such content in the Chinese Apche technical materials on the internet-and it occupies an increasingly important position in the Apache architecture (in Apache1.3.17 for win32 version-DSO is already the default installation mode ).
  
So what is DSO? In fact, DSO is short for Dynamic Shared Objects. it is a Dynamic connection mechanism that exists in all operating systems derived from modern Unix. It provides a special format of code at runtime. when the program is running, it transfers the required part from the external memory to the memory for execution. Apache is supported after version 1.3. Apache has long used a module concept to expand its functions and internally uses a scheduling-based list to link the extension module to the Apache core module. therefore, Apache has long been destined to use DSO to load its modules at runtime.
  
Author of mod_ssl and mod_rewrite: Ralf S. engelschall (in my opinion, he is one of the real Apache masters and major developers. his personal homepage is named "Apache 1.3 Dynamic Shared Object (DSO) Support"
The principles of the DSO mode are described in detail (this article is based on this ).
  
  
Let's take a look at the Apache program structure: this is a very complex layer-4 structure-each layer is built on the next layer.
  
The fourth layer is a third-party library developed using the Apache Module. for example, open ssl is generally empty in the official Apache release, however, in the actual Apache structure, the layer structure composed of these libraries must exist.
  
The third layer is some optional additional function modules, such as mod_ssl and mod_perl. Each module at this layer usually implements an independent separation function of Apache. In fact, none of these modules are required. running a minimum Apache does not require any modules at this layer.
  
The second layer is the basic function library of Apache-which is also the core essential layer of Apache-this layer includes the Apache kernel, http_core (Apache core module ), they implement basic HTTP functions (such as resource processing (through file descriptors and memory segments) and maintain the pre-generated (pre-forked) sub-process model, listen to the TCP/IP socket of the configured virtual server, transmit the HTTP request to the processing process, process the HTTP protocol status, read/write buffer, in addition, there are many additional functions such as URL and MIME header parsing and DSO loading), as well as Apache application interface (API) (In fact, the real functions of Apache are still included in internal modules. to allow these modules to fully control the Apache process, the kernel must provide API interfaces.) this layer also includes a general available code library (libap) the Library (libregex) that matches the implementation of regular expressions is also a small abstract Library (libos) of the operating system ).
  
The lowest layer is OS-related platform application functions, which can be different from modern UNIX variants, win32, OS/2, MacOS, or even a POSIX subsystem.
  
What's interesting about this complex program structure is that, in fact, there is a loose connection between Layer 3 and layer 4 and Layer 2, on the other hand, the modules on the third layer are mutually dependent. the significant impact of this structure is that the code on the third and fourth layers cannot be statically connected to the code on the lowest layer. Therefore, the DSO mode becomes a means to solve it. In combination with the DSO function, this structure becomes very flexible, so that the Apache kernel (technically speaking, it should be the mod_so module rather than the kernel) can be started (rather than installed) load necessary parts to implement layer 3 and layer 4 functions.
  
DSO transfers the required parts from the external memory to the memory during program running. There are two ways to perform access: One is that the ld is automatically loaded by the system at the beginning of the program, this load can be achieved through two ways: one is that the system automatically calls ld at the beginning of the executable program. so. The other is manual, which is executed by calling tdlopen ()/dlsym () to the Unix loader on the program system interface in the execution program.
How does Apache implement the DSO function? DSO supports calling a special Apache module based on a module called mod_so.c. this module must statically compile the core of Apache. This is the only module except http_core.c that cannot be put into DSO itself (bootstrapping !). In fact, all other released Apache modules can be placed in DSO, and are allowed by DSO through some settings-allowed-shared settings (see the INSTALL file on the top layer) or change the AddModule command in your src/Configuration to the SharedModule command (see the src/INSTALL file ).
After compiling a module to a DSO named mod_foo.so, you can use the LoadModule command of mod_so to call this module in your httpd. conf file when the service program starts or restarts.
  
To simplify this method of creating DSO files for the Apache Module (especially third-party modules), a new support program named apxs (APache eXtenSion) is used. it can be used to build a DSO-based module located outside the Apache source code tree. This idea is simple: when installing Apache, set the installation program to install the Apache C header file and place the compiler and link program Flag supported by the platform to create a DSO file to the apxs program. In this way, you can use apxs to compile the source code of its Apache module, instead of publishing the source code tree of Apache, and without manually adding the compilation programs supported by the platform and the flag of the program to obtain DSO support.
  
In order to place compiled apache core programs into a DSO Library (only on some supported platforms need to force the link program to output the Apache core address code-a prerequisite for DSO Modularization) the specified SHARED_CORE must be able to be set by setting -- allow-Rule = SHARED_CORE (see the INSTALL file on the top layer) or by changing the Rule command, in your Configuration file, specify SHARED_CORE = yes (see the src/INSTALL file ). the Apache core code is then placed in a file named libhttpd. so DSO Library. Because the static library cannot be linked to a DSO on all platforms, an additional name is libhttpd. the executable program of ep is created. this program not only contains the static code, but also provides the function of the remaining part of main. finally, the httpd program is replaced by the bootstrapping code, which automatically determines that the Unix scheduler can load and start libhttpd. ep, which provides LD_LIBRARY_PATH to libhttpd. so method implementation.
Finally, let's talk about the platform supported by the Apache DSO mode and its advantages and disadvantages-it should be said that the current DSO mode can basically run on any unix platform-except ultrix (because it has no dynamic (Library) loader: No dlopen-style interface under this platform ). its advantage is that the server package can be more flexible during operation and the server package can be simply expanded using a third-party module, even after installation. However, the DSO mode also has some disadvantages, such:
  
1. cannot work on all platforms, for example, ultrix that does not support dynamic connection.
  
2. Apache will slow down by about 20% at startup, because it needs to do some front jobs, and the address code solution now needs to be done by UNIX scheduling program. The server slows down by 5% when running on some platforms, because the relative address code (PIC) sometimes needs to re-compile the relative addressing when it is not necessary, so there is no absolute address fast. so sometimes DSO does not increase the speed.
  
3. because the DSO module conflicts with other DSO-based libraries (ld-lfoo) on some platforms (for example,. the out-based platform often does not support this function, but the ELF-based platform does. you cannot use the DSO mechanism for all types of modules (that is, not all DSO modules can be loaded ). In other words, the module is restricted as a DSO file, and only the APACHE core address code can be used. The APACHE core uses the C library (libc) and all other dynamic and static libraries, or static library file (libfoo. a) independent code contained. The only way to use other code is to determine that the APACHE core contains its own reference for a long time and call the code itself through dlopen, you can also allow SHARED_CHAIN rules when creating APACHE (when your platform supports linking DSO files without using the DSO Library ).
  
On some platforms (many SVR4 systems), when linking Apache httpd executable programs, there is no way to force the linking program to output all the addresses used by DSO. however, without the visible Apache core address code, there is no standard Apache module that can be used as a DSO. the only method is to use the SHARED_CORE feature, because this method forces all the address codes to be output. As a result, Apache src/Configure script automatically forces SHARED_CORE on these platforms, when the DSO feature is used in the Configuration file or in the configure command line.
  
After talking about this, it is a matter of principle. it seems that it is somewhat different from the practicality in my Preface. In fact, DSO is an important aspect in Apache-it is also a relatively high-end content-to make good use of it. it needs to understand its principles. if you have any shortcomings in this article, I will explain how to use the DSO mode in the next article and how to implement the DSO mode of Apache.
  
----- Note: References
Ralf S. Engelschall --
Apache 1.3 Dynamic Shared Object (DSO) Support
The Chinese translation of the software house linux home.
  

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.