13.07.2015 Views

Software Engineering for Internet Applications - Student Community

Software Engineering for Internet Applications - Student Community

Software Engineering for Internet Applications - Student Community

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

It seems reasonable to expect that hardware engineers will continueto deliver substantial per<strong>for</strong>mance improvements and that fashions insoftware development and business complexity will continue to robusers of any enjoyment of those improvements. So stick to 10requests per second per CPU until you've got your own applicationspecificbenchmarks that demonstrate otherwise.11.3 Load BalancingAs noted earlier in this chapter, an <strong>Internet</strong> service with 100 CPUsspread among 15 physical computers isn't going to be very reliable ifall 100 CPUs must be working <strong>for</strong> the overall service to function. Weneed to develop a strategy <strong>for</strong> load balancing so that (1) userrequests are divided more or less evenly among the available CPUs,(2) when a piece of hardware fails it doesn't result in too many errorsreturned to users, and (3) we can reconfigure hardware and networkwithout breaking users' bookmarks and links from other sites.We will start by positing a two-tier server farm with a single multi-CPU machine running the RDBMS and multiple single-CPU front-endmachines, each of which runs the Web server program, interpretspage scripts, per<strong>for</strong>ms SSL encryption, and generally does anycomputation not being per<strong>for</strong>med within the RDBMS.**** insert drawing of our example server farm ****Figure 1: A typical server configuration <strong>for</strong> a medium-to-high volume<strong>Internet</strong> application. A powerful multi-CPU server supports therelational database management system. Multiple small 1-CPUmachines run the HTTP server program.11.3.1 Load Balancing In the Persistence LayerOur persistence layer is the multi-CPU computer running theRDBMS. The RDBMS itself is typically a multi-process or multithreadedapplication. For each database client the RDBMS spawns aseparate process or thread. In this case each front-end machinepresents itself to the RDBMS as one or more database clients. If weassume that the load of user requests are spread among the frontendmachines, the load of database work will be spread among themultiple CPUs of the RDBMS server by the operating system processor thread scheduler.210being on the planet, however, understands that mauve looks differentfrom fuchsia and that Helvetica looks different from Times Roman.Thus the largest number of suggestions <strong>for</strong> changes to a Webapplication will be design-related. Someone wants to add a new logoto every page on the site. Someone wants to change the backgroundcolor in the discussion <strong>for</strong>um section. Someone wants to make aheadline larger on a particular page. Someone wants to add a bit ofwhitespace here and there.Suppose that you've built your Web application in the simplest andmost direct manner. For each URL there is a corresponding script,which contains SQL statements, some procedural code in thescripting language (IF statements, basically), and static strings ofHTML that will be combined with the values returned from thedatabase to <strong>for</strong>m the completed page. If you break down what isinside a Visual Basic Active Server Page or a Java Server Page or aPerl CGI script, you always find these three items: SQL, IFstatements, HTML.Development of an application with this style of programming is easy.You can see all the relevant code <strong>for</strong> a page in one text editor buffer.Maintenance is also straight<strong>for</strong>ward. If a user sends in a bug reportsaying "There is a spelling error onhttp://www.yourcommunity.org/foo/bar" you know that you need onlylook in one file in the file system (/foo/bar.asp or /foo/bar.jsp or/foo/bar.pl or whatever) and you are guaranteed to find the source ofthe user's problem. This goes <strong>for</strong> SQL and procedural programmingerrors as well.What if people want site-wide changes to fonts, colors, headers andfooters? This could be easy or hard depending on how you've craftedthe system. Suppose that default colors are read from a configurationparameter system and headers, footers, and per-page navigationaids are generated by the page script calling shared procedures. Inthis happy circumstance making site-wide changes might take only afew minutes.What if people want to change the wording of some annotation in thestatic HTML <strong>for</strong> a page? Or make a particular headline on one pagelarger? Or add a bit of white space in one place on one page? Thiswill require a programmer because the static HTML stringsassociated with that page are embedded in a file that contains SQLand procedural language code. You don't want someone to bring asection of the service down because of a botched attempt to fix atypo or add a hint.139

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!