"Flaskehals" er et fantastisk beskrivende begrep. Den beskriver en kunstig begrensning på en eller annen form for kommunikasjon, interaksjon eller overføring av informasjon. Og det får en til å tro at en magisk kombinasjon av flaks, penger og oppfinnsomhet kan knuse den flaskehalsen og la alle gode ting flyte.
Problemet med ytelsesflaskehalser er at de kan være vanskelige å identifisere. Er det CPU? Nettverket? En klønete bit av kode? Ofte er den mest åpenbare synderen faktisk nedstrøms for noe større og mer mystifiserende. Og når ytelsesgåter forblir uløste, kan IT-ledelse komme til å møte et Hobsons valg mellom å innrømme uvitenhet og finne på unnskyldninger.
Heldigvis, som med medisinske diagnoser eller detektivarbeid, hjelper erfaring. Basert på årene med sleuthing og eksperimentering, har vi samlet 15 av de mest sannsynlige plagene - og foreslåtte rettsmidler - for å hjelpe din IT-drift med å spore og knekke ytelsesproblemer.
Noen av disse flaskehalsene er mer åpenbare enn andre. Mest sannsynlig har du noe å si om noen luskede spoilere (og vi vil gjerne høre historiene dine om dem). Men ved å identifisere vanlige fartsdrepere på tvers av IT-disipliner, håper vi å sette i gang din søken etter å skape den infrastrukturen som ressursene dine tillater best.
Nr. 1: Det er sannsynligvis ikke serverne
Serveroppgraderinger pleide å gjøre hele forskjellen, og det er grunnen til at den gamle sagen "Når alt annet mislykkes, kast mer maskinvare på den" vedvarer i dag. Det er fremdeles sant i noen tilfeller. Men hvor mye av IT er egentlig så beregningskrevende? Generelt kan du spare mye tid og penger ved å vri det hårete øyeeplet vekk fra serverens maskinvare. Den nedre enden av serverspekteret har mer enn nok hestekrefter til å håndtere daglige oppgaver.
Her er et konkret eksempel. I et nettverk med over 125 brukere så en eldre Windows-domenekontroller ut til å være moden for erstatning. Denne serveren kjørte opprinnelig Windows 2000 Server og ble oppgradert til Windows Server 2003 for en tid tilbake, men maskinvaren forble uendret. Denne HP ML330 med en 1 GHz CPU og 128 MB RAM fungerte som en Active Directory-domenekontroller som hadde alle AD FSMO-rollene, kjørte DHCP og DNS-tjenester samt kjørte IAS (Internet Authentication Services).
Melasse, ikke sant? Faktisk gjorde det faktisk jobben helt fint. Den ble erstattet av en HP DL360 G4 med en 3Ghz-prosessor, 1 GB RAM og speilvendte 72 GB SCSI-stasjoner. Med alle disse tjenestene kjører den nesten ikke belastning i det hele tatt - og ytelsesforskjellen er umerkelig.
Det er enkelt å identifisere applikasjoner som spiser all CPU og minne, men de pleier å være ganske spesialiserte. For nesten alt annet vil den ydmyke vareboksen gjøre susen.
Nr. 2: Få fart på spørsmålene
Du kan opprette den niftiest applikasjonen i verden, men hvis tilgang til back-end-databaseservere skaper en flaskehals, vil ikke sluttbrukerne eller kundene dine være fornøyde. Så finjuster databasespørringene og maksimer ytelsen.
Tre grunnleggende tiltak kan hjelpe deg med å forbedre søkeytelsen. For det første inkluderer de fleste databaseprodukter verktøy (for eksempel DB2 UDB for iSeries ’Visual Explain) som kan dissekere spørringen din under utviklingen, og gi tilbakemelding på syntaksen og den omtrentlige timingen for de forskjellige delene av SQL-setningene. Bruk denne informasjonen til å finne de lengste delene av spørringen og dele dem videre for å se hvordan du kan forkorte utføringstiden. Enkelte databaseprodukter inkluderer også verktøy for ytelsesrådgivning, som Oracle’s Automatic Database Diagnostic Monitor, som gir anbefalinger (for eksempel å foreslå at du oppretter en ny indeks) for å få raskere spørsmål.
Deretter slår du på verktøy for databaseovervåking på en staging-server. Du kan bruke et tredjepartsovervåkingsprodukt, for eksempel Fidelias NetVigil, hvis databasen din mangler overvåkingsstøtte. Når monitorene er aktivert, kan du generere trafikk mot databaseserveren ved hjelp av lastetestingskript. Undersøk dataene som er samlet for å se hvordan spørsmålene dine ble utført mens de var under belastning; denne informasjonen kan føre deg til ytterligere justering av spørsmål.
Hvis du har nok serverressurser til å etterligne produksjonsmiljøet for blandet arbeidsbelastning ganske tett, kan du utføre en tredje runde med søkjustering ved hjelp av et lastetestingsverktøy, for eksempel OpenSTA, pluss databaseovervåking for å se hvordan spørsmålene dine fungerer sammen med andre applikasjoner som treffer database.
Når databaseforholdene endres - med volumvekst, registrering av slettinger og så videre - fortsett å teste og stille. Det er ofte vel verdt innsatsen.
Nr. 3: Hva koster virusbeskyttelse?
Virusbeskyttelse på kritiske servere er et grunnleggende krav, spesielt for Windows-servere. Effekten kan imidlertid være smertefull. Noen virusscannere er mer påtrengende enn andre og kan redusere serverytelsen betydelig.
Prøv å kjøre ytelsestester med og uten at virusscanneren kjører for å avgjøre virkningen. Hvis du ser en markant forbedring uten skanneren, er det på tide å lete etter en annen leverandør. Sjekk også spesifikke funksjoner. Deaktiver skanninger i sanntid, og ganske ofte vil du øke ytelsen.
Uansett hvor godt skrevet virksomhetslogikken din, når du distribuerer den til mellomnivået, må du stille inn applikasjonsserverens kjøretidsmiljø for å maksimere ytelsen.
Som en vintage stereoanlegg med mange knapper for å tilpasse lydkvaliteten, gir applikasjonsservere fra leverandører som BEA, IBM og Oracle et svimlende sett med kontroller. Trikset er å vri knappene på riktig måte, avhengig av egenskapene til applikasjonen din.
Nr. 4: Maksimere mellomnivået
Uansett hvor godt skrevet virksomhetslogikken din, når du distribuerer den til mellomnivået, må du stille inn applikasjonsserverens kjøretidsmiljø for å maksimere ytelsen.
Som en vintage stereo med mange knapper for å tilpasse lydkvaliteten, leverer applikasjonsservere fra leverandører som BEA, IBM og Oracle et svimlende sett med kontroller. Trikset er å vri knappene på riktig måte, avhengig av egenskapene til applikasjonen din.
For eksempel, hvis applikasjonen din er servlet-tung, vil du aktivere caching av servlet. På samme måte, hvis applikasjonen din bruker mange SQL-setninger for å støtte en stor brukerbase, vil du aktivere klargjort hurtigbuffering og angi maksimal størrelse på hurtigbufferen, slik at den er stor nok til å støtte den tiltenkte arbeidsmengden.
Et av de viktigste områdene der ytelsesjustering virkelig kan hjelpe er med databasekoblingsbassenget. Angi minimums- eller maksimumsforbindelsene for lave, og du er sikker på at du lager en flaskehals. Hvis du setter dem for høyt, vil du sannsynligvis se en avmatning som følge av den ekstra kostnaden som er nødvendig for å opprettholde det større tilkoblingsbassenget.
Hvis du vet den tiltenkte arbeidsmengden, kan du stille applikasjonsserverens kjøretid ved å slå på verktøy for ytelsesovervåking, for eksempel IBMs Tivoli Performance Viewer for WebSphere på en iscenesatt applikasjonsserver. Generer mengden arbeidsmengde du forventer ved å bruke et lastgenereringsverktøy, og lagre deretter overvåkingsresultatene og spill dem av for å analysere hvilke knotter som må justeres.
Når du er i produksjon, er det lurt å slå på passiv overvåkning med lav overhead for å holde orden på kjøretiden. Hvis arbeidsmengden din endres over tid, vil du utføre en ny ytelsesvurdering.
Nr. 5: Optimaliser nettverkstilkoblingen
De fleste mellomstore bedriftsservere har nå to gigabit-nettverkskort - men de fleste av dem bruker ikke det andre røret. Videre har prisene på gigabit-brytere falt gjennom gulvet. Med en 120 Mbps-kobling til filserveren din, kan et antall klienter på 100 megabit oppnå filhastighet på samme tid samtidig.
Selv uten gigabit-bytte, bør NIC-binding være en stift. Når det er enklest, gir binding av to nettverkskort deg redundans, men legg til overføringsbalanse, og du kan effektivt doble den utgående båndbredden. Bruk av koblingsassistert teaming vil gi samme effekt på innkommende trafikk. Nesten alle store serverleverandører tilbyr NIC-teamdrivere - og det er også tredjepartsverktøy. Det er et stort, billig båndbreddeforbedring.
Nr. 6: Avvikle webserverne dine
Er det virkelig så mye du kan gjøre for å stille inn en webserver og maksimere ytelsen? Faktisk er det - hovedsakelig ved å justere en håndfull kritiske innstillinger for å matche den produksjonstrafikken du forventer.
For webservere som allerede er i produksjon, begynn med å samle sanntidsstatistikker for webservere (de fleste store webservere har den innebygde funksjonaliteten). Gå deretter til iscenesettelse for å bestemme hvilke parametere, om noen, som trenger justering.
Aktiver webserverens ytelsesovervåkingsverktøy på iscenesettingsserveren. Utfør en lastetest og inspiser relevante parametere, for eksempel svartid, sendte og mottatte byte, og antall forespørsler og svar.
Nøkkelparametere du vil stille inn, avhengig av trafikkvolumet, inkluderer caching, threading og tilkoblingsinnstillinger.
Aktiver hurtigbufring for ofte brukt innhold; noen webservere lar deg cache filer dynamisk basert på bruk, mens andre krever at du spesifiserer hva som skal caches. Forsikre deg om at din maksimale bufferstørrelse er tilstrekkelig for trafikken du forventer. Og hvis webserveren din støtter hurtigbufferakselerasjon, aktiver det også.
For trådinnstillinger og tilkoblingsinnstillinger, still inn minimum og maksimum i samsvar med forventet arbeidsmengde. For tilkoblinger må du også definere maksimalt antall forespørsler per tilkobling og tidsavbruddsinnstillingen for tilkoblingen. Ikke sett noen av disse verdiene for små eller for store, ellers kan det føre til forsinkelser.
Nr. 7: WANs ve
Tror du at du trenger å gjenvinne WAN-båndbredde? Du kan enkelt bruke en pakke på trafikkformende apparater eller cachemotorer i et forsøk på å tømme WAN-båndbredden. Men hva om det ikke er røret?
Første ting først: Før du kjøper noe, få en solid ide om hvilken trafikk som krysser WAN. Nettverksanalyseverktøy som Ethereal, ntop, Network Instrument’s Observer eller WildPackets EtherPeek NX kan gi deg et nytt innblikk i hva som egentlig er på ledningen.
Du kan oppleve at replikeringstidene for Active Directory er satt for lave, og ganske enkelt å konfigurere lengre replikasjonsintervaller kan gi deg pusterom i løpet av arbeidsdagen. Er det noen brukere på eksterne steder som kartlegger aksjer til feil servere og drar store filer over WAN uten å vite det? Flyter fortsatt restene av et IPX-nettverk med lang funksjonshemming? Noen WAN-problemer går ut på feil konfigurasjon av applikasjoner, der trafikken blir dirigert over WAN når den burde vært lokal. Regelmessige rapporter om WAN-trafikkmønstre vil spare penger og hodepine.
Nr. 8: La oss spille fine
Alt for ofte konkurrerer applikasjoner, webtjenester og nettsteder fra flere avdelinger over hele virksomheten om serverressurser. Selv om hver av disse komponentene kan være godt innstilt i seg selv, kan en applikasjon fra en annen avdeling som også bruker de samme produksjonsklyngene ha et dårlig innstilt spørsmål eller noe annet problem, noe som igjen påvirker brukerne eller kundene dine.
På kort sikt er alt du kan gjøre å jobbe med systemadministratorene og avdelingen som har ytelsesproblemet for å få oppløsning for brukere eller kunder. På lengre sikt kan du opprette et fellesskap på tvers av alle avdelingene som bruker produksjonsklyngene der objektene dine distribueres. Arbeid på tvers av teamene for å sikre at det er tilstrekkelig finansiering for et iscenesettelsesmiljø som virkelig er representativt for det blandede produksjonsmiljøet. Til slutt vil du ønske å utvikle en serie referanser som kan brukes til å validere ytelse for blandet arbeidsmengde i iscenesettelsesmiljøet.
Nr. 9: Caching, forming, begrensning, herregud!
Hvis WAN er virkelig underdimensjonert - og du ikke har råd til et langdistanse rammeverknettverk - kan trafikkforming og caching hjelpe til med å rense røret.
Trafikkformende konfigurasjoner er mer kunst enn vitenskap. Prioritering av apper er ofte mer politisk enn teknisk, men kan ha enorme effekter på opplevd nettverksytelse.
Caching er et annet dyr helt. Det krever mindre arbeid enn trafikkforming, men effekten vil sannsynligvis være mindre. Cachemotorer lagrer og serverer lokale kopier av ofte tilgjengelige data for å redusere WAN-trafikk. Ulempen er at dynamisk innhold ikke kan lagres i virkeligheten, slik at e-post ikke får samme ytelse.
Nr. 10: Forutsigende lapping
Du kommer på jobb på mandag bare for å lære at en haug med skrivebord er hengt eller at ytelsen til en kritisk applikasjon har redusert til en gjennomsøking. Etter å ha undersøkt bestemmer du at en lapp som ble påført i løpet av helgen er årsaken.
Derfor trenger du verktøy som støtter patch-tilbakeslag. Enda bedre, ta med patch-testing som en del av din patch-management-strategi. Først må du ta regelmessig oversikt over applikasjonene og teknologiene som spilles på stasjonære datamaskiner og servere. De fleste systemadministrasjonsverktøy, for eksempel Microsofts SMS, har muligheten til å ta beholdning for deg automatisk.
Gjenta deretter applikasjonene og teknologiene til et iscenesettingsmiljø. Hvis operativsystemet og infrastrukturprogramvaren din ikke inkluderer verktøy for patch-testing, kan du skaffe deg et tredjepartsverktøy som FLEXnet AdminStudio eller Wise Package Studio.
Alternativt kan du skrive noen skript for å trene plattformen eller teknologien funksjonelt med de nyeste oppdateringene. Du må gjenta dette scenariet (og justere skript) når nye oppdateringer kommer og når programvareendringer gjøres.
