1CS514: Intermediate Course in Computer SystemsLecture 5: Sept. 15, 2003PerformanceCS514Performance| The single overriding goal for systems builders is to obtain maximum performance without loss of robustness| What are the major determinants of performance? Today we will look at:z The costs of various common operationsz Speed of the various platform technologiesz Caching and other common tricksz Relationship between caching and replication. Cache consistency issues.2CS514Changing Goals| Performance goals circa 1980:z Focus on getting the compiler to produce the best possible codez Forced you to write code with CPU in mind, even to declare “register” variables carefully| “Memory mapping and protection boundary crossings” were rare| Multithreading was uncommonCS514Changing goals| Performance goals circa 1990z The Internet became widely deployed| 1980 issues remained, but…z The network was frequently in the “critical path”z Multithreading much more common| This changed the emphasis for developers:z Often the delay before a message was sent, or received, was centralz Had to be aware of layers of the operating system and network that each message would traverse and to think about communication relationships.3CS514Changing goals| Performance goals circa 2000z Now we’ve gone to object-oriented architectures and Web Services| Implications?z There are some very slow paths sitting around!z Network much more heavily used| Moreover, the network itself has become more complex.z Distinctions between a local area network and the Internet WAN are fadingz A “private network” may span a single Gig-Ethernet switch or a backbone ISPCS514“Basic” costs| A shifting landscapez Very dependent on hardware choice• CPU speed, but also…• Size of L1 cache, cache design• E.g. interleaving factors, line size, etc• Presence and size of L2 cache• Cache hit rates• Performance of I/O bus, dev. Controllersz Also on O/S architecture• Cost of context switching, operating system calls• Overall design of the operating system4CS514Two large classes of machines| Clients: PCs and workstationsz Sit on your desktopz These days, usually run Windows XP or Linux. Sun Solaris a fading option.z User application runs herez Performance is less of an issue but you need to multithread and exploit pre-built GUI toolkits| Serversz Sit in a data center accessed over netz Right now, Linux and other UNIX variants are most popular platform choice. Windows has made minor inroads. z Performance is a dominant issue here and demands a great deal of sophistication from the developer| But often, the real key to performance is the wire itself!CS514Technology Trends: Processor/Memory Gap| Processor speed continues at Moore’s lawz Roughly double every 18 months| Memory and bus speeds growing much more slowlyz 15% increase per year5CS514Technology Trends: Network Speeds| Network speeds have made tremendous leaps in the last few yearsz 2000-GigE, 2002-10GigE, 2004-100GigEz 10x increase every two years!| But slower networks still common| Network performance varies wildlyz Bandwidth and latency| Access speed (i.e. broadband) tends to be the WAN bottleneckCS514O/S latency: the most expensive overhead on LAN communication!05101520253035401985-19901995-2000O/Soverhead aspercentage6CS514Broad observations| O/S imposed communication latencies has risen in relative terms over past decade!| Other performance curves have generally “tracked” one-anotherz Moreover, media objects have grown in size at least as fast as the capacity to move them has risenz Disks have “maxed out” and hence are looking slower and slowerz Due to O/S latencies, memory of remote computers isn’t currently an appealing resource| Web Services architecture could impose a 10x growth in overhead on paths that go the whole nine yards!CS514Performance parameters worth keeping in mind| Cost of a null system call. Cost of doing a “select” system call.| Cost of a method invocation to a service running outside your address space| Context switching overhead for threads and for heavyweight processes| Maximum TCP transfer rate| Cost of a remote method invocation| Round-trip cost to send a small message7CS514Can we reduce performance to a set of rules of thumb?| There are a number of generic performance tricks worth knowing| On a given platform you need to design tiny little stand-alone code loops to figure out what really matters| Gprof (code timing profiler) is a very helpful tool! z The more you know the more you can focus on the bottlenecksCS514Generic insight #1| System calls are expensivez Many developers are casual about using “select”, hence core loop could require 3 or 4 system calls per operation performedz Often, it turns out that select is the most costly operation you can do!| So… think hard about your “main loop”8CS514Example| A common style| Better options?z Use one thread per incoming socket and do blocking rcvsz Another separate thread can use select and check time, putting it in a shared global variablez NIS lookup can usually be avoided by caching resultsz If we have some single maximum size for messages, can allocate off a free list from a poolselect(….);msg_body = malloc(…);rcvmsg(..);gettimeofday(...);nis_lookup(…):Non-blocking selectThen fetch msgAllocate just the right size objectMap IP address to nameNote arrival timeCS514Generic insight #2| Threads: Gotta love ‘em. Gotta hate ‘em.| Threads can be very costlyz Context switching can be slowz Thread scheduling (and mis-scheduling) a common problem! z Each thread will need a lot of memory for the stack and other overheads• C, C++: Your program soon starts to thrash!• Java and C# avoid this but they have other forms of high overhead (i.e. background garbage collection)9CS514Example?| Formula for really bad performance: have multiple threads on run queue when in fact only one thread can “do anything”z E.g. thread a wakes up thread b, then blocks on a semaphore only after thread b is runnable.z O/S will often get the context switching wrong, running b, then a, then b again (if not worse)Signal(B.sema);wait(A.sema);wait(B.sema);Signal(A.sema);wait(B.sema);CS514Threads and sockets| Sockets is the classic style of network programming| Thread model and socket model were never thought out in a clear side-by-side way| Today we live with a messy legacy of this initially haphazard design!10CS514Thread issues on UNIX/Linux| Problem here relates to
View Full Document
Unlocking...