"Flaskehals" er et vidunderligt beskrivende udtryk. Den beskriver en kunstig begrænsning af en eller anden form for kommunikation, interaktion eller overførsel af information. Og det får en til at tro, at en magisk kombination af held, penge og opfindsomhed kan knuse den flaskehals og lade alle gode ting flyde.
Problemet med præstationsflaskehalse er, at de kan være svære at identificere. Er det CPU'en? Netværket? En klodset bit kode? Ofte er den mest oplagte synder faktisk nedstrøms for noget større og mere mystificerende. Og når præstationsgåder forbliver uløste, kan IT-ledelse måske stå over for et Hobsons valg mellem at indrømme uvidenhed og finde på undskyldninger.
Heldigvis, som med medicinske diagnoser eller detektivarbejde, hjælper erfaringen. På baggrund af vores mange år med sleuthing og eksperimentering har vi samlet 15 af de mest sandsynlige lidelser - og foreslåede løsninger - for at hjælpe din it-drift med at opspore og revne ydeevneproblemer.
Nogle af disse flaskehalse er mere åbenlyse end andre. Mest sandsynligt har du noget at sige om nogle luskede spoilere (og vi vil meget gerne høre dine fortællinger om dem). Men ved at identificere almindelige hastighedsdræbere på tværs af it-discipliner håber vi at starte din søgen efter at skabe den mest effektive infrastruktur, som dine ressourcer tillader.
Nr. 1: Det er sandsynligvis ikke serverne
Serveropgraderinger plejede at gøre hele forskellen, hvorfor den gamle sav "Når alt andet fejler, kast mere hardware på den" fortsætter i dag. Det er stadig sandt i nogle tilfælde. Men hvor meget af IT er egentlig så computertunge? Generelt kan du spare meget tid og penge ved at dreje dit hårede øjeæble væk fra serverhardware. Den nederste ende af serverspektret har mere end nok hestekræfter til at håndtere hverdagens opgaver.
Her er et konkret eksempel. På et netværk med over 125 brugere syntes en ældre Windows-domænecontroller at være moden til udskiftning. Denne server kørte oprindeligt Windows 2000 Server og blev opgraderet til Windows Server 2003 for nogen tid siden, men hardwaren forblev uændret. Denne HP ML330 med en 1 GHz CPU og 128 MB RAM fungerede som en Active Directory-domænecontroller, der bar alle AD FSMO-roller, kørte DHCP og DNS-tjenester samt kørte IAS (Internet Authentication Services).
Melasse, ikke? Faktisk gjorde det faktisk jobbet fint. Den blev erstattet af en HP DL360 G4 med en 3Ghz-processor, 1 GB RAM og spejlede 72 GB SCSI-drev. Med alle disse tjenester kører den næsten ikke belastning - og præstationsforskellen er umærkelig.
Det er let at identificere applikationer, der spiser al din CPU og hukommelse, men de har tendens til at være ret specialiserede. For næsten alt andet vil den ydmyge vareboks gøre tricket.
Nr. 2: Fremskynd disse forespørgsler
Du kan oprette den smukkeste applikation i verden, men hvis adgang til back-end-databaseservere skaber en flaskehals, vil dine slutbrugere eller kunder ikke være tilfredse. Så finjuster disse databaseforespørgsler, og maksimer ydeevnen.
Tre grundlæggende foranstaltninger kan hjælpe dig med at forbedre forespørgselens ydeevne. For det første inkluderer de fleste databaseprodukter værktøjer (såsom DB2 UDB til iSeries 'Visual Explain), der kan dissekere din forespørgsel under udvikling og give feedback om syntaksen og den omtrentlige timing af de forskellige sektioner i SQL-sætningerne. Brug disse oplysninger til at finde de længste dele af forespørgslen og opdele dem yderligere for at se, hvordan du kan forkorte udførelsestiden. Nogle databaseprodukter inkluderer også ydeevnevejledningsværktøjer, som Oracle's Automatic Database Diagnostic Monitor, der giver anbefalinger (såsom at foreslå, at du opretter et nyt indeks) for at fremskynde forespørgsler.
Tænd derefter databaseovervågningsværktøjer på en iscenesættelsesserver. Du bruger muligvis et tredjepartsovervågningsprodukt, såsom Fidelias NetVigil, hvis din database mangler overvågningssupport. Når monitorerne er aktiveret, genererer du trafik mod databaseserveren ved hjælp af belastningstest-scripts. Undersøg de indsamlede data for at se, hvordan dine forespørgsler klarede sig under belastning; disse oplysninger kan føre dig til yderligere justering af forespørgsler.
Hvis du har nok serverressourcer til at efterligne dit miljø med blandet arbejdsbelastningsproduktion forholdsvis tæt, kan du udføre en tredje runde af forespørgseljustering ved hjælp af et belastningstestværktøj, såsom OpenSTA, plus databaseovervågning for at se, hvordan dine forespørgsler fungerer sammen med andre applikationer, der rammer database.
Efterhånden som databaseforholdene ændres - med volumenvækst, registrering af sletninger osv. - skal du fortsætte med at teste og tune. Det er ofte værd at gøre.
Nr. 3: Hvilke omkostninger er virusbeskyttelse?
Virusbeskyttelse på kritiske servere er et grundlæggende krav, især for Windows-servere. Virkningen kan dog være smertefuld. Nogle virusscannere er mere påtrængende end andre og kan reducere serverens ydeevne betydeligt.
Prøv at køre præstationstest med og uden at din virusscanner kører for at bestemme virkningen. Hvis du ser en markant forbedring uden scanneren, er det tid til at lede efter en anden leverandør. Kontroller også specifikke funktioner. Deaktiver scanninger i realtid, og ofte bringer du ydeevnen op.
Uanset hvor godt skrevet din forretningslogik, når du distribuerer den til det midterste niveau, skal du indstille applikationsserverens runtime-miljø for at maksimere ydeevnen.
Som en vintage stereoanlæg med mange knapper til at finjustere lydkvaliteten, leverer applikationsservere fra leverandører som BEA, IBM og Oracle et svimlende sæt kontrolelementer. Tricket er at dreje drejeknapperne på den rigtige måde afhængigt af attributterne til din applikation.
Nr. 4: Maksimering af det midterste niveau
Uanset hvor godt skrevet din forretningslogik, når du distribuerer den til det midterste niveau, skal du indstille applikationsserverens runtime-miljø for at maksimere ydeevnen.
Ligesom en vintage stereoanlæg med mange knapper til at finjustere lydkvaliteten, leverer applikationsservere fra leverandører som BEA, IBM og Oracle et svimlende sæt kontrolelementer. Tricket er at dreje drejeknapperne på den rigtige måde afhængigt af attributterne til din applikation.
For eksempel, hvis din applikation er servlet-tung, vil du aktivere servlet-caching. Ligeledes, hvis din applikation bruger mange SQL-sætninger til at understøtte en stor brugerbase, vil du aktivere forberedt caching af udsagn og indstille den maksimale størrelse på cachen, så den er stor nok til at understøtte den tilsigtede arbejdsbyrde.
Et af de største områder, hvor performance tuning virkelig kan hjælpe, er med databaseforbindelsespuljen. Indstil minimums- eller maksimumforbindelserne for lave, og du er sikker på at oprette en flaskehals. Indstil dem for højt, og du vil sandsynligvis se en afmatning som følge af den ekstra omkostning, der er nødvendig for at opretholde den større forbindelsespool.
Hvis du kender den tilsigtede arbejdsbelastning, skal du indstille applikationsserverens kørselstid ved at aktivere ydeevneovervågningsværktøjer såsom IBMs Tivoli Performance Viewer til WebSphere på en iscenesat applikationsserver. Generer den mængde arbejdsbyrde, du forventer ved hjælp af et belastningsgenererende værktøj, gem derefter overvågningsresultaterne, og afspil dem for at analysere, hvilke knapper der skal justeres.
Når du er i produktion, er det en god ide at aktivere passiv overvågning med lav overhead for at holde styr på runtime. Hvis din arbejdsbyrde ændres over tid, vil du gerne udføre en ny effektivitetsanmeldelse.
Nr. 5: Optimer netværksforbindelse
De fleste enterprise-servere på mellemniveau har nu dobbelt gigabit-NIC'er - men de fleste af dem bruger ikke det andet rør. Desuden er gigabit switch priser faldet gennem gulvet. Med et 120MBps-link til din filserver kan et antal 100-megabit-klienter opnå trådhastighedsfiladgang samtidigt.
Selv uden gigabit-skift skal NIC-binding være en hæfteklammer. Når det er enklest, giver binding af to NIC'er dig redundans, men tilføj send belastningsbalancering, og du kan effektivt fordoble den udgående båndbredde. Brug af switch-assisteret teaming vil give den samme effekt på indgående trafik. Næsten alle større serverleverandører tilbyder NIC-teamdrivere - og der er også tredjepartsværktøjer. Det er en stor, billig båndbreddeforøgelse.
Nr. 6: Afvikling af dine webservere
Er der virkelig så meget, du kan gøre for at tune en webserver og maksimere ydeevnen? Faktisk er der - hovedsageligt ved at justere en håndfuld kritiske indstillinger for at matche den produktionstrafik, du forventer.
For webservere, der allerede er i produktion, skal du begynde med at indsamle statistik i realtid over webserveren (de fleste større webservere har den indbyggede funktionalitet). Gå derefter til iscenesættelse for at bestemme, hvilke parametre, hvis der er behov for justering.
Aktivér webserverens præstationsovervågningsværktøjer på iscenesættelsesserveren. Udfør en belastningstest og inspicer relevante parametre, såsom svartid, sendte og modtagne byte og antallet af anmodninger og svar.
Nøgleparametre, du vil indstille afhængigt af trafikmængden, inkluderer caching, threading og forbindelsesindstillinger.
Aktivér caching for ofte brugt indhold; nogle webservere giver dig mulighed for at cache filer dynamisk baseret på brug, mens andre kræver, at du angiver, hvad der skal cachelagres. Sørg for, at din maksimale cachestørrelse er tilstrækkelig til den trafik, du forventer. Og hvis din webserver understøtter cacheacceleration, skal du også aktivere det.
For tråd- og forbindelsesindstillinger skal du indstille minimums- og maksimumsniveauer i overensstemmelse med forventet arbejdsbyrde. For forbindelser skal du også definere det maksimale antal anmodninger pr. Forbindelse og forbindelses timeout-indstillingen. Indstil ikke nogen af disse værdier for små eller for store, ellers kan der opstå afmatninger.
Nr. 7: WAN's ve
Tror du, at du har brug for at genvinde WAN-båndbredde? Du kan nemt bruge et bundt på apparater til trafikformning eller cachemotorer i et forsøg på at begrænse brugen af WAN-båndbredde. Men hvad hvis det ikke er røret?
Første ting først: Før du køber noget, skal du få en god idé om, hvilken trafik der krydser WAN. Netværksanalyseværktøjer som Ethereal, ntop, Network Instrument's Observer eller WildPackets EtherPeek NX kan give dig et nyt kig på, hvad der virkelig er på ledningen.
Du kan finde ud af, at replikeringstider for din Active Directory er indstillet alt for lave, og ved blot at konfigurere længere replikationsintervaller kan du få vejrtrækningsrum i løbet af arbejdsdagen. Er nogle brugere på fjernplaceringer, der kortlægger aktier til de forkerte servere og trækker store filer på tværs af WAN uden at vide det? Flyder stadig resterne af et IPX-netværk med længe handicappede rundt? Nogle WAN-problemer koges ned til applikationsfejlkonfiguration, hvor trafik ledes over WAN, når den skulle have været lokal. Regelmæssige rapporter om WAN-trafikmønstre sparer penge og hovedpine.
Nr. 8: Lad os lege godt
Alt for ofte konkurrerer applikationer, webservices og websteder fra flere afdelinger i hele virksomheden om serverressourcer. Selvom hver af disse komponenter kan være velindstillet i sig selv, kan en applikation fra en anden afdeling, der også bruger de samme produktionsklynger, have en dårligt afstemt forespørgsel eller et andet problem, hvilket igen påvirker dine brugere eller kunder.
På kort sigt er alt, hvad du kan gøre, at arbejde med dine systemadministratorer og den afdeling, der har ydeevneproblemet, for at få en opløsning til dine brugere eller kunder. På længere sigt skal du oprette et fællesskab på tværs af alle de afdelinger, der bruger produktionsklyngerne, hvor dine objekter er implementeret. Arbejd på tværs af hold for at sikre, at der er tilstrækkelig finansiering til et iscenesættelsesmiljø, der virkelig er repræsentativt for det blandede arbejdsmængdeproduktionsmiljø. I sidste ende vil du gerne udvikle en række benchmarks, der kan bruges til at validere blandet arbejdsindsats i mellemstationer.
Nr. 9: Caching, formning, begrænsning, åh min!
Hvis dit WAN virkelig er underdimensioneret - og du ikke har råd til et langdistanceret frame-relæ-netværk - kan trafikformning og caching hjælpe med at rense røret.
Trafikformende konfigurationer er mere kunst end videnskab. Prioritering af apps er ofte mere politisk end teknisk, men kan have enorme effekter på opfattet netværksydelse.
Caching er et helt andet dyr. Det kræver mindre arbejde end trafikformning, men virkningen vil sandsynligvis være mindre. Cachemotorer gemmer og serverer lokale kopier af almindeligt tilgængelige data for at reducere WAN-trafik. Ulempen er, at dynamisk indhold ikke rigtig kan cachelagres, så e-mail får ikke den samme præstationsbump.
Nr. 10: Forudsigelig lappning
Du ankommer til arbejde på mandag kun for at lære, at en masse desktops er hængt, eller at udførelsen af en kritisk applikation er bremset til en gennemgang. Efter at have undersøgt bestemmer du, at et plaster, der blev påført i weekenden, er årsagen.
Derfor har du brug for værktøjer, der understøtter patch-rollbacks. Endnu bedre, inkluder patch test som en del af din patch-management strategi. For det første skal du tage regelmæssig opgørelse over applikationer og teknologier, der spilles på desktops og servere. De fleste systemadministrationsværktøjer, såsom Microsofts SMS, har evnen til automatisk at opgøre lager for dig.
Gentag derefter applikationerne og teknologierne i et iscenesat miljø. Hvis dit operativsystem og din infrastruktursoftware ikke indeholder værktøjer til patchtest, skal du hente et tredjepartsværktøj som FLEXnet AdminStudio eller Wise Package Studio.
Alternativt kan du skrive nogle scripts til funktionelt at udøve platformen eller teknologien med de nyeste programrettelser. Du bliver nødt til at gentage dette scenario (og justere scripts), når nye patches ankommer, og når der foretages softwareændringer.
