CHAPTER 8 HIGH-PERFORMANCE DEPLOYMENTS servers by another
CHAPTER 8 HIGH-PERFORMANCE DEPLOYMENTS servers by another firewall, but not always. When making this decision, you need to consider how secure your business tier needs to be: if someone hacks into your Web server, do you need to stop the intruder there, or are security measures at the Web server sufficient? Inserting a fire- wall between your Web and application servers is a good idea for security, but it adds additional overhead to your requests as well as additional responsibilities to your workload to manage and maintain it. If you are working with users personal and/or financial information, then I would consider a firewall placed between the Web and business tiers essential. But if you are only displaying the contents of an online catalog or maintaining a message forum, then the urgency to do so is reduced. As previously mentioned, application servers can be broken down into a dynamic Web tier and a business tier, each equipped with its own set of hardware and software servers. In the case of a cluster, each tier should access a consistent primary business server and fail over appropriately. This will help mitigate the load. Finally, as requests are made against the database, these requests need to be properly load balanced. Fortunately, in large environments, this is handled for you by your database clustering software. And for small environments, database clustering is too expensive to be feasible, so load balancing is accomplished by refactoring your data model to allow data to be maintained in distinct database instances. Load Testing Strategy Before closing this chapter, we ll revisit the different performance testing phases. In development, we implement performance unit tests; in integration and QA, we implement a performance integration test and a performance integration load test; and in the production staging environment, we implement a production staging performance test and a production staging performance load test. Remember when implementing production staging tests that your deployment strategy must be represented in your production staging environment. It is not sufficient to load test your application running in a shared environment with other applications competing for resources without implementing the same tier breakdown in your deployment strategy. Requests spend time traveling between tiers and passing through firewalls, so for the highest degree of confidence, be sure to create a production staging environment that resembles your production environment. Ideally, you would maintain a production staging environment that either mirrors production or is a stripped-down version of production. For example, if you have six application server instances in your business tier in production, two might suffice in production staging. But testing your entire application server on the same machine or missing any of its tiers reduces confidence as applications are rolled out to production. As a general rule, when scaling down a production environment to create a staging environment, scale down the environment proportionally. For example, if you have four Web servers and eight application servers, then production might have two Web servers and four application servers. If you drop down to two Web servers and two application servers, you will find it difficult to extrapolate the behavior of the Web servers when forced to spread the load between two servers (each) instead of one.
Looking for affordable and reliable webhost to host and run your business application? Then look no more and go to servlet web hosting services.