Software Engineering for Internet Applications - Student Community

It isn't challenging to throw hardware at a performance problem.What is challenging is setting up that hardware so that the service isworking if any of the components are operational rather than only ifall of the components are operational.We'll examine each layer individually.11.1.1 Persistence LayerFor most interactive Web applications the persistence layer is arelational database management system (RDBMS). The RDBMSserver program is parsing SQL queries, writing transactions to thedisk, rooting around on the disk(s) for seldom-used data, gluingtogether data in RAM, and returning it to the RDBMS client program.The average engineer's top-of-the-head viewpoint is that RDBMSperformance is limited by the speed of the disk(s). The programmersat Oracle disagree: "A properly configured Oracle server will runCPU-bound."Suppose that we have a popular application and need 16 CPUs tosupport all the database queries. And let's further suppose that we'vedecided that the RDBMS will run all by itself on one or more physicalcomputers. Should we buy 16 small computers, each with one CPU,or one big computer with 16 CPUs inside? The local computer shopsells 1-CPU PCs for about $500, implying a total cost of $8000 for 16CPUs. If we visit www.sun.com we find that the price of a 16-CPUSunfire 6800 is too high even to list on the site but if the past is anyguide we won't get away for less than $200,000. We will pay 25 timesas much to get 16 CPUs of the same power but all inside onephysical computer.Why would anyone do this?Let's consider the peculiarities of the RDBMS application. TheRDBMS server talks to multiple clients simultaneously. If Client Aupdates a record in the database and, a split-second later, Client Brequests that record, the RDBMS is required to deliver the updatedinformation to Client B. If we were to spread the RDBMS serverprogram across multiple physical computers, it is possible that ClientA would be served from Computer I and Client B would be servedfrom Computer II. A database transaction cannot be committedunless it has been written out to the hard disk drive. Thus all thatthese computers need do is check the disk for updates beforereturning any results to Client B. Disk drives are 100,000 timesslower than RAM. A single computer running an RDBMS keeps an202and cpk.config_param_key_id =cpv2.config_param_key_idand cpk.key_name = 'redirect'and cpv1.value_index = 1and cpv1.param_value = :requested_urland cpv2.value_index = 2-- that was pretty ugly; maybe we can encapsulate-- it in a viewcreate view redirectsasselect cpv1.param_value as from_url,cpv2.param_value as to_urlfromconfig_param_keys cpk,config_param_values cpv1,config_param_values cpv2where cpk.config_param_key_id =cpv1.config_param_key_idand cpk.config_param_key_id =cpv2.config_param_key_idand cpk.key_name = 'redirect'and cpv1.value_index = 1and cpv2.value_index = 2-- a couple of Oracle SQL*Plus formatting commandscolumn from_url format a25column to_url format a30-- let's look at our virtual table nowselect * from redirects;FROM_URL TO_URL------------------------- ------------------------------/wtr/thebook/ /panda/N-way joins notwithstanding, how tasteful is this approach to storingparameters? The surface answer is "extremely tasteful." All of ourinformation is in the RDBMS where it belongs. There are no magicnumbers in the code. The parameters are amenable to editing fromadmin pages that have the same form as all the other pages on thesite: SQL queries and SQL updates. A little more time spent with thisproblem, however, and one asks "Why are we querying the RDBMS1 million times per day for information that changes once per year?"147