Software Engineering for Internet Applications - Student Community

Questions of taste aside, an extra 5-10 RDBMS queries per requestis a significant burden on the database server, which is the mostdifficult part of an Internet application to distribute across multiplephysical computers (see the Scaling chapter) and therefore the mostexpensive layer in which to expand capacity.A good rule of thumb is that Web scripts shouldn't be querying theRDBMS to figure out what to do; they should query the RDBMS onlyfor content and user data.For reasonable performance, configuration parameters should beaccessible to Web scripts from the Web server's virtual memory.Implementing such a scheme with a threaded Web server is prettystraightforward because all the code is executing within one virtualmemory space:• look in the server API documentation to find a mechanismfor saying "run this bit of code at server startup time"• build an in-memory hash table where the parameter keysare the hash table keys• load the parameter values associated with a key into thehash table as a list• document an API to the hash table that takes a key as aninput and returns a value or a list of values as an outputA hash table is best because it offers O[1] access to the data, i.e., thetime that it takes to answer the question "what is the value associatedwith the key 'foobar'" does not grow as the number of keys grows. Insome hobbyist computer languages built-in hash tables might beknown as "associative arrays".If you expect to have a lot of configuration parameters it might bebest to add a "section" column to the config_param_keys table andquery by section and key. Thus, for example, you can have aparameter called "bug_report_email" in both the "discussion" and"user_registration" sections. The key to the hash table then becomesa composite of the section name and key name.With Microsoft .NET...Configuration parameters are added to IIS/ASP.NET applications inthe Web.config file for the application.challenges cannot be solved with money and hardware. Consider, forexample, the following questions:• How can 100,000 people hold a conversation?• How can an online learning community support 50,000people with 50,000 different levels of passion for the topicand for participation?• What is the electronic analog of keeping in touch with one'sneighbors? With one's friends?In this chapter we will first consider the straightforward hardware andsoftware issues, then move on to the more subtle challenges thatgrow progressively more difficult as the user community expands.11.1 Tasks in the Engine RoomHere are the fundamental tasks that are happening on the servers ofvirtually every interactive Internet application:• transport-layer encryption (SSL if the site has secureHTTPS pages)• HTTP service• presentation layer (page composition; script execution)• abstraction provision (sometimes called "business logic";any layer of code on top of the raw database where eachprocedure is used by more than one page)• persistenceAt a modestly visited site, it would be possible to have one CPUperforming all of these tasks. In fact, for ease of maintenance andreliability it is best to have as few and as simple servers as possible.Consider your desktop PC, for example. How long has it been sincethe hardware failed? If you look into a room with 50 simple PCs orsingle-board workstations, how often do you see one that isunavailable due to hardware failure? Suppose, however, that youcombine computers to support your application. If one machine is 99percent reliable, a site that depends on 10 such machines will be only0.99^10 reliable or 90 percent. The probability analysis here is thesame as flipping coins but with a heavy 0.99 bias towards heads.You need to get 10 heads in a row in order to have a working service.What if you needed 100 machines to be up and running? That's onlygoing to happen 0.99^100th of the time, or roughly 37 percent.148201