Web Hosting Java, JSP, Tomcat 6, J2EE, Servlets, Struts, Jboss

Page 170

Optimization 43: Share Nothing In the previous section (Optimization 42) we established the validity of the principle calling for a reduction in the amount of computation (and hence CPU cycles) executed inside synchronized code. In the most extreme form of this principle we eliminate sharing altogether, leading to the elimination of the synchronized code. In this chapter we introduce various techniques to minimize time spent in synchronized code, but erasing it altogether is even better. Your first question when faced with a synchronization hot spot should be: Can I restructure my design so as to eliminate the need for synchronization? Let’s look at a concrete example involving a Web-server implementation. In Chapter 11 we develop a multithreaded Web server. One type of Web server is a file server for HTML documents. A Web server that does not perform file caching (such as in the early releases of the popular Apache server) will be slowed down by file I/O. The typical solution employed by many Web-server implementations is to cache HTML documents in a memory-resident cache managed by the server. There’s typically a single cache object shared by all threads of the multithreaded server. This shared cache is often the place where all server threads collide, competing for exclusive access. Since the cache is a dynamic object from which files come and go, access to it must be synchronized. There are quite a few potential solutions to this contention hot spot: . Private file chaches. Give each thread a private file cache, independent of the other threads. The need for synchronization is removed along with the lock contention. . Partial sharing. Find a middle ground between having a single server-wide cache on one extreme and providing a cache per thread on the other. We discuss this further in Optimization 44. . Read/write locks. The file cache is read-mostly. Updating (write) the cache is relatively infrequent. See Optimization 45 for further details. The scalability upside of eliminating shared resources is clear. There’s a downside, as well. Providing each server thread with its own copy of the cache leads to a drastic increase in the memory footprint of the server. What if each cache grows to 10 MB and we have 500 active threads? Such a design choice will have to be compensated for by either restricting cache size, limiting the number of concurrent threads, or some combination of both. This design choice is available in many multithreaded applications and it does not always come bundled with a footprint penalty. It should find a place in your bag of tricks. Page 171
Note: If you are looking for cheapest and affordable webspace to host and run your servlet application check Astra servlet hosting services