| home / programming / php_mysql2 / 1 |   [previous] |
|
|
|
For complicated web applications that require many different pieces of functionality and many different technologies to implement, we can take the abstraction of tiers a bit further and abstract other major blocks of functionality into different modules. If we were designing a major E-Commerce application that had product catalogs, customer databases, payment processing systems, order databases, and inventory systems, we might want to abstract many of these components so that changes in any of them would have minimal impact on the rest of the system (see Figure 13-5).
Figure 13-5: An n-tiered web application setup example.
We should be constantly thinking about maintaining a balance between abstraction and its cost. The more we break areas of functionality into their own modules, the more time we spend implementing and executing code to communicate between the different modules.
If we see something that is likely to be reused, has a particular implementation that lends itself to an isolated implementation, or is very likely to change, then we would probably consider putting it in its own module. Otherwise, we should be asking ourselves about the benefits of doing this.
Any way that we decide to implement our web application, we will stress the importance of planning in advance. Before you start writing code, you should have an idea of how the various layers of the application will be implemented, where they will be implemented, and what the interface will look like. Not having this in mind before you begin is a sure way to guarantee wasted time as problems crop up. (This is not to say that a well-planned system will not encounter problems as it is being implemented, but the goal is to make them fewer and less catastrophic.)
We have frequently mentioned that the performance and scalability of our web applications are of high concern to us, but we must first define these. Without this, it is difficult to state what our goals are or to decide how to measure our success against them.
Perormance is very easy to define for our web applications. It is simply a measure of how much time elapses between when the user asks for something to happen and his receiving confirmation of its happening, usually in the form of a page. For example, an E-Commerce shoe store that takes 20 seconds to show you any pair of shoes you ask to see is not going to be perceived as having favorable performance. A site where that same operation takes 2 seconds will be better received by the user. The potential locations for performance problems are many. If our web application takes forever to compute things before sending a response to the user, our database server is particularly slow, or our computer hardware is out of date, performance may suffer.
However, beyond things over which we have complete control, there are other problems that can adversely affect our performance. If our ISP (Internet Service Provider) or the entire Internet slows down significantly (as it has a tendency to do during large news events or huge virus/worm outbreaks), our web site’s performance could suffer. If we find ourselves under a denial-of-service (DoS) attack, our web site could appear unusually slow and take many seconds to respond to seemingly simple requests.
The key item to remember is that the user does not know—and probably does not care— what the source of the problem is. To his eyes, our web application is slow, and after a certain point, it irritates or discourages him from using our application. As web application authors, we need to constantly be thinking about the potential problems we might encounter and ways to deal with them as best we can.
While there is a tendency to group them together, scalability and performance are very different beasts. We have seen that performance is a measure of how quickly a web site or web application responds to a particular request. Scalability, on the other hand, measures the degree to which the performance of our web site degrades under an increasing load. A web application that serves up a product catalog page in 0.5 seconds when 10 users are accessing the site but 5 seconds when 1,000 users are using the site sees 1,000 percent degradation in performance from 10 to 1,000 users. An application that serves up a product catalogue in 10 seconds for 10 users and 11 seconds for 1,000 users only sees 10 percent degradation in performance and has better scalability (but obviously worse performance)! While we will not argue that the latter server is the better setup, it serves to demonstrate that observing great performance on a simple test system is not sufficient—we need to think about how that same application will respond to many users accessing it at the same time. As we will discuss in Chapter 29, “Development and Deployment,” you will want to consider using testing tools that simulate high loads on your machines to see how the application responds.
Many people, when faced with the possibility of suboptimal performance or scalability, suggest that you “throw more hardware” at the problem—buy a few more servers and spread the load across more machines. While this is a possible approach to improving performance, it should never be the first one taken or considered.
If our web application was so poorly designed that adding a $20,000 server only gave us the ability to handle 10 more users at a time or improved the speed of our product catalog listings by 5 percent, we would no be spending our money wisely.
Instead, we should focus on designing our applications for performance, thinking about potential bottlenecks, and taking the time to test and analyze our programs as we are writing them. Unfortunately, there are no hard and fast rules or checklists we can consult to find the magic answers to our performance problems. Every application has different requirements and performance goals, and each application is implemented in a very different way.
However, we will endeavor to show you how we think about performance in the design of any samples or web applications we develop.
Writing web applications without a fundamental understanding of the underlying technologies is an unwise task. By having a solid foundation for the workings of the Internet and the various technologies we use in our programs, we can help design them for optimal functioning, security, and performance. While it is not necessary to become an expert in these areas, we should at least have a passing familiarity with how they work. In this chapter, we discussed the various Internet technologies, such as the TCP/IP protocol, HTTP, and Secure Sockets Layer (SSL), and we have defined web applications.
We then looked at how we might go about implementing web applications, specifically looking at 3-tiered and n-tiered application architectures. By dividing our applications into presentation, business logic, and database layers, we can organize our code and reduce the chance of bugs when we make modifications later.
With this basic understanding of technologies and our web applications, the next chapter will discuss how to design and implement the user interface portions of our web application. We will see that this is more than simply writing HTML pages and adding flashy graphics.
This content is excerpted from Chapter 13 of the new book, "Core Web Application Development with PHP and MySQL", by permission of Prentice Hall PTR. ISBN 0131867164, copyright 2005. All rights reserved. To learn more, please visit: http://www.phptr.com/bookstore/product.asp?isbn=0131867164&rl=1.
| home / programming / php_mysql2 / 1 | [previous] |
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 
Created: March 27, 2003
Revised: October 3, 2005
URL: http://webreference.com/programing/php_mysq2/1
