Optimizing Apache/tomcat Configuration

Apache| optimization recently had to delve into publishing and publishing system management and testing related issues. There is ample evidence that the vast majority of apache/tomcat configuration, Apache is the device, all the burden of response, including static multimedia files are actually done by Tomcat, and Tomcat is actually very inefficient, about one-tenth of Apache. Therefore, the goal of integration is not achieved, but in the optimal configuration of local basic success, it is intended to test the Web server in the actual trial, but encountered a "Martix phenomenon": No explanation can not be repeated abnormal performance.
It seems that in the tomcat/apache of the match to the real, today wrote the article prompted a realistic problem, Apache has no effect, more serious is, 107 and 106 do not match, 107 can not even repeat 106 of the match. Because the amount of pictures will be many, so this is a very real problem. I think the only way is to download to the local, refer to the information may be a complete configuration of the reference. After all, the configuration is now a few years ago, and it was not done by me. If the process is OK here, then I believe it is beneficial to provide the system with the ability to deal with the speed. ...... After a day's struggle, the main time is to reinstall all the relevant software on the local device, including the local DNS server, there is no way to test the virtual host interpretation. So mainly in the evening testing, in-depth study of the Apache/tomcat, the basic understanding of the relationship between the two, confirm the original configuration is only "surface success", in fact, complete all the answers by Tomcat, Apache is just deaf ears-furnishings. But when all the tests are done locally, ready to be updated on the web, there is the "Matrix phenomenon" again: there are inexplicable differences; unexplained, natural disappearance.

The first difference is that, according to the latest understanding, the multimedia path that Apache interprets is different from the page path that Tomcat interprets, so you have to trim both on the page, otherwise the picture and the multimedia will not be available because of the differences in the path, and in the original setting, So the two are the same. The idea of the experiment was very successful locally, but on the Internet, on the contrary, the path explanation is all right-the problem is that I have tested and modified the path explanation locally: God, what do you want? In fact, the worker.properties filter is exactly the same. If that's not too weird, then the second difference is even weirder.

The first is to use the original httpd.conf always on the virtual host DocumentRoot is blocked access, in the forced use of local settings file replacement (as the path, the problem is not big) after become OK. This right is unknown somewhere wrong, then the strange again and again: whether the virtual host, all just explained to the first virtual host directory, in other words, the virtual host, complete failure. Take that setup file back to the local test but it's all normal. Then again to the online test, this time is followed by normal ... The reason is unknown, the only possibility ... Seems to be a kind of Firefox cache ... Anyway, it's a stupid account. It's so confusing. But the former image must be changed by the Apache explanation is conclusive, otherwise, the system performance will be excessive consumption, static large file processing, not Tomcat's strengths.

Our world is a physical world, its basic characteristics are homogeneous and repeatable, the whole modern science is built on this basis. If there is no such thing as homogeneous repeatability, my feeling is that I am living in the matrix.

Continued: Today in the local test got the same result as the distal end, at least it seems to be a material world again! The only possible explanation (but also very far-fetched) is that Firefox has a very different caching strategy for browsers that have visited or for accelerated reasons. Be aware of this in future operations.

Many people are already familiar with this structure, and there are a lot of howto on the internet, but the most critical file Worker.properties settings may not be correct, such as:

INFO=AJP13 forwarding over sockettomcatid=localhost:8009[uri:/jsp-examples/*][shm:]disabled=1

If uri:/jsp-examples/*, like the above, believe that Apache does not use, basically is Tomcat bear all the burden. Obviously, if this is the case, the system is burdened, I mean the Java server, and it will be much more than it should be. The above configuration should be modified so that Apache, primarily HTML and graphics as well as multimedia downloads, rather than Tomcat, is expected to provide the load capability of this collocation system greatly.

...... Write here the day before yesterday, suddenly feel this configuration quite familiar, quickly go to check, sure enough now the project in the setting is this appearance, but further test let me a bit astray, for a while proved to be so, a moment to show that is the case. Software this thing if the lack of logical inevitable connection, people are nothing good to do. In any case, continue to the above ideas, like the configuration above, that all the/jsp-examples/* subordinate directory is to Tomcat processing, Apache does not work accordingly. The correct configuration should be: [uri:/jsp-examples/*.jsp][uri:/jsp-examples/servlet/*]

If you use struts like this, you probably need to add a suffix like *.action. This way, files that are not of this type will be handed to Apache. This setting: [uri:/*] is extremely risky, which means that all requests are responded to by Tomcat; however, it seems that Ajp13 has done preventative measures, in fact, Hou AJP13 put all the requests into the sewer, do nothing. The negative effect is the root directory of the virtual host I can not at any rate be able to directly identify index.jsp guidance. can only use HTML instead, but this is not a big deal, if it is a small home, you can turn on the spot, and if it is a large home page, itself will be converted to the regular output HTML page. Obviously, using wildcards in this structure is the easiest to match, but it's also wrong.
When you combine Apache with Tomcat, you get an unexpected benefit of simplifying the development directory by using the connection form to interpret some of the main jsp/servlet files from Apache outside the directory. In the actual development process, if the planning is not good, not long will accumulate a lot of useless picture files, the working directory is more than a G is very normal; If the open section allows users to upload files and so on, but because Tomcat can not explain the symbolic link, This can not move these pictures outside the directory, can only be implemented using a full URL, and after the rational configuration of Apache/tomcat, although Tomcat can not explain the link symbol, but Apache can, so, the above problem solved.