Намерете и коригирайте 15 тесни места за изпълнение

„Тесно гърло“ е чудесно описателен термин. Той описва изкуствено ограничение на някаква форма на комуникация, взаимодействие или трансфер на информация. И това кара човек да повярва, че някаква магическа комбинация от късмет, пари и изобретателност може да разбие това тесно място и да остави всички добри неща да текат.

Проблемът с тесните места за изпълнение е, че те могат да бъдат трудни за идентифициране. Процесорът ли е? Мрежата? Неумела част от кода? Често най-очевидният виновник е всъщност след нещо по-голямо и по-загадъчно. И когато загадките за изпълнението останат неразгадани, ИТ мениджмънтът може да се изправи пред избора на Хобсън между признаване на невежество и измисляне на оправдания.

За щастие, както при медицинските диагнози или детективската работа, опитът помага. Изхождайки от годините ни на заплитане и експериментиране, ние събрахме 15 от най-вероятните заболявания - и предложихме лекарства -, за да помогнем на вашата ИТ операция да проследи и пробие проблеми с производителността.

Някои от тези тесни места са по-очевидни от други. Най-вероятно имате какво да кажете за някои свои подли спойлери (и бихме искали да чуем приказките ви за тях). Но чрез идентифициране на често срещани убийци на скорост в ИТ дисциплините, ние се надяваме да започнем стремежа ви да създадете най-ефективната инфраструктура, която вашите ресурси ще позволят.

№ 1: Вероятно не са сървърите

Надстройките на сървърите, използвани да направят всичко различно, поради което старият трион „Когато всичко друго се провали, хвърлете повече хардуер върху него“ продължава и днес. Това все още е вярно в някои случаи. Но колко от ИТ наистина са толкова изчислително интензивни? Като цяло можете да спестите много време и пари, като отклоните космата си очна ябълка от сървърния хардуер. Долният край на сървърния спектър има повече от достатъчно конски сили за справяне с ежедневните задачи.

Ето един конкретен пример. В мрежа от над 125 потребители възрастен контролер на домейни на Windows изглеждаше узрял за подмяна. Този сървър първоначално работеше с Windows 2000 Server и беше надграден до Windows Server 2003 преди известно време, но хардуерът остана непроменен. Този HP ML330 с 1Ghz CPU и 128MB RAM работеше като домейн контролер на Active Directory, носещ всички роли на AD FSMO, изпълняващ DHCP и DNS услуги, както и IAS (Internet Authentication Services).

Меласа, нали? Всъщност наистина свърши добре работата. Неговата подмяна беше HP DL360 G4 с 3Ghz процесор, 1GB RAM и огледални 72GB SCSI устройства. Пренасяйки всички тези услуги, той изобщо не натоварва изобщо - и разликата в производителността е незабележима.

Лесно е да се идентифицират приложения, които ще изядат целия ви процесор и памет, но те са доста специализирани. За почти всичко останало скромната стокова кутия ще свърши работа.

№ 2: Ускорете тези заявки

Можете да създадете най-доброто приложение в света, но ако достъпът до сървъри на база данни от задния край създава пречка, вашите крайни потребители или клиенти няма да бъдат доволни. Така че прецизирайте тези заявки към базата данни и увеличете производителността.

Три основни мерки могат да ви помогнат да подобрите ефективността на заявката. Първо, повечето продукти за бази данни включват инструменти (като DB2 UDB за iSeries 'Visual Explain), които могат да дисектират вашата заявка по време на разработката, като предоставят обратна връзка за синтаксиса и приблизителното време на различните раздели на SQL изразите. Използвайки тази информация, намерете най-дългите части от заявката и ги разбийте допълнително, за да видите как бихте могли да съкратите времето за изпълнение. Някои продукти на базата данни включват и инструменти за съвети за ефективност, като автоматичния диагностичен монитор на базата данни на Oracle, които предоставят препоръки (като например да ви предложат да създадете нов индекс) за ускоряване на заявките.

След това включете инструментите за мониторинг на база данни на подреждащ сървър. Можете да използвате продукт за мониторинг на трети страни, като NetVigil на Fidelia, ако вашата база данни няма поддръжка за мониторинг. С активирани монитори генерирайте трафик срещу сървъра на базата данни, използвайки скриптове за тестване на натоварване. Проучете събраните данни, за да видите как се изпълняват заявките ви, докато сте под товар; тази информация може да ви отведе до по-нататъшно променяне на заявката.

Ако имате достатъчно сървърни ресурси, за да имитирате сравнително средата на вашето смесено работно натоварване, можете да изпълните трети кръг от настройка на заявка с помощта на инструмент за тестване на натоварване, като OpenSTA, плюс мониторинг на база данни, за да видите как вашите заявки се изпълняват заедно с други приложения, които ударят база данни.

Тъй като условията на базата данни се променят - с нарастване на обема, изтриване на записи и така нататък - продължете да тествате и настройвате. Често си заслужава усилията.

№ 3: Каква цена, защита срещу вируси?

Защитата от вируси на критични сървъри е основно изискване, особено за сървърите на Windows. Въздействието обаче може да бъде болезнено. Някои скенери за вируси са по-натрапчиви от други и могат значително да намалят производителността на сървъра.

Опитайте да провеждате тестове за производителност със и без вашия вирусен скенер, за да определите въздействието. Ако забележите значително подобрение без скенера, е време да потърсите друг доставчик. Също така проверете конкретни функции. Деактивирайте сканирането в реално време и доста често ще подобрите производителността.

Без значение колко добре е написана вашата бизнес логика, когато я разполагате на средния слой, ще трябва да настроите средата на изпълнение на сървъра за приложения, за да увеличите максимално производителността.

Подобно на ретро стерео с множество копчета за настройване на качеството на звука, сървърите за приложения от производители като BEA, IBM и Oracle предоставят шеметен набор от контроли. Номерът е да завъртите копчетата точно по правилния начин, в зависимост от атрибутите на вашето приложение.

№ 4: Максимизиране на средния слой

Без значение колко добре е написана вашата бизнес логика, когато я разполагате на средния слой, ще трябва да настроите средата на изпълнение на сървъра за приложения, за да увеличите максимално производителността.

Подобно на ретро стерео с множество копчета за настройване на качеството на звука, сървърите за приложения от производители като BEA, IBM и Oracle предоставят шеметен набор от контроли. Номерът е да завъртите копчетата точно по правилния начин, в зависимост от атрибутите на вашето приложение.

Например, ако приложението ви е тежко на сървлети, ще искате да активирате кеширането на сървлети. По същия начин, ако вашето приложение използва много SQL изрази, за да поддържа голяма потребителска база, ще искате да активирате подготвеното кеширане на изрази и да зададете максималния размер на кеша, така че да е достатъчно голям, за да поддържа предвиденото работно натоварване.

Една от основните области, в които настройката на производителността наистина може да помогне, е с пула за връзка с база данни. Задайте минималната или максималната връзка твърде ниски и със сигурност ще създадете пречка. Задайте ги твърде високо и вероятно ще видите забавяне в резултат на добавените режийни разходи, необходими за поддържане на по-големия пул от връзки.

Ако знаете планираното работно натоварване, настройте времето за изпълнение на сървъра за приложения, като включите инструменти за мониторинг на производителността като IBM Tivoli Performance Viewer за WebSphere на подреждащ сървър на приложения. Генерирайте количеството натоварване, което очаквате, с помощта на инструмент за генериране на натоварване, след това запишете резултатите от мониторинга и ги възпроизведете, за да анализирате кои копчета се нуждаят от настройка.

Когато е в производство, е добра идея да включите пасивно наблюдение с ниски разходи, за да следите времето за изпълнение. Ако работното ви натоварване се промени с течение на времето, ще искате да извършите нов преглед на ефективността.

№ 5: Оптимизиране на мрежовата свързаност

Повечето корпоративни сървъри от средно ниво вече имат двойни гигабитови мрежови карти, но повечето от тях не използват втората тръба. Освен това цените на гигабитовите комутатори спаднаха. Със 120MBps връзка към вашия файлов сървър, редица 100-мегабитови клиенти могат да постигнат едновременно достъп до файлове с кабелна скорост.

Дори без превключване на гигабит, NIC свързването трябва да бъде основна. В най-простия случай свързването на два NIC ви дава излишък, но добавяте балансиране на натоварването на предаването и можете ефективно да удвоите изходящата честотна лента. Използването на екип с подпомагане на превключването ще осигури същия ефект върху входящия трафик. Почти всеки основен доставчик на сървъри предлага NIC екипни драйвери - а има и помощни програми на трети страни. Това е голямо, евтино увеличаване на честотната лента.

№ 6: Прекратяване на вашите уеб сървъри

Наистина ли можете да направите толкова много, за да настроите уеб сървър и да увеличите максимално производителността? Всъщност има - главно чрез коригиране на няколко критични настройки, за да съответства на производствения трафик, който очаквате.

За уеб сървърите, които вече са в производство, започнете със събиране на статистически данни за уеб сървъри в реално време (повечето основни уеб сървъри имат тази функция вградена). След това преминете към етап, за да определите кои параметри, ако има такива, се нуждаят от корекция.

Активирайте инструментите за наблюдение на производителността на уеб сървъра на подготвителния сървър. Изпълнете тест за натоварване и проверете съответните параметри, като например времето за реакция, изпратените и получените байтове и броя на заявките и отговорите.

Основните параметри, които ще искате да настроите в зависимост от обема на трафика, включват кеширане, нишки и настройки за връзка.

Активиране на кеширането за често използвано съдържание; някои уеб сървъри ви позволяват да кеширате файлове динамично въз основа на използването, докато други изискват да посочите какво ще се кешира. Уверете се, че вашият максимален размер на кеша е достатъчен за трафика, който очаквате. И ако вашият уеб сървър поддържа ускоряване на кеша, активирайте и това.

За настройките на резбата и връзката задайте минимумите и максимумите в съответствие с очакваното натоварване. За връзки също ще трябва да дефинирате максималния брой заявки за връзка и настройката за изчакване на връзката. Не задавайте нито една от тези стойности твърде малка или твърде голяма, защото може да се получи забавяне.

№ 7: Горкото от WAN

Мислите ли, че трябва да си върнете WAN честотната лента? Можете лесно да похарчите пакет за уреди за оформяне на трафика или кеширане на двигатели в опит да ограничите използването на WAN честотна лента. Но какво, ако не е тръбата?

Първи неща: Преди да купите каквото и да било, придобийте солидна представа за това какъв трафик преминава през WAN. Инструментите за мрежов анализ като Ethereal, ntop, Observer на Network Instrument или EtherPeek NX на WildPacket могат да ви дадат нов поглед върху това, което всъщност е по жицата.

Може да откриете, че времето за репликация за вашия Active Directory е зададено твърде ниско и простото конфигуриране на по-дълги интервали на репликация може да ви купи място за дишане през работния ден. Някои потребители в отдалечени местоположения картографират ли споделяния на грешни сървъри и изтеглят големи файлове през WAN, без да го осъзнават? Все още ли се движат остатъците от отдавна забранена IPX мрежа? Някои проблеми с WAN се свеждат до неправилна конфигурация на приложението, където трафикът е насочен през WAN, когато е трябвало да остане локален. Редовните отчети за моделите на WAN трафик ще спестят пари и главоболие.

No 8: Да играем хубаво

Твърде често приложенията, уеб услугите и уеб сайтовете от множество отдели в предприятието се конкурират за сървърни ресурси. Въпреки че всеки от тези компоненти може да бъде добре настроен сам по себе си, приложение от друг отдел, който също използва същите производствени клъстери, може да има лошо настроена заявка или някакъв друг проблем, който от своя страна засяга вашите потребители или клиенти.

В близко бъдеще всичко, което можете да направите, е да работите със системните си администратори и отдела, който има проблем с производителността, за да получите решение за вашите потребители или клиенти. В дългосрочен план създайте общност във всички отдели, които използват производствените клъстери, където са разположени вашите обекти. Работете в различни екипи, за да сте сигурни, че има достатъчно финансиране за сценична среда, която наистина е представителна за смесената производствена среда. В крайна сметка ще искате да разработите серия от бенчмаркове, които могат да се използват за валидиране на ефективността на смесеното натоварване в променителната среда.

No 9: Кеширане, оформяне, ограничаване, о!

Ако вашата WAN е наистина маломерна - и не можете да си позволите мрежа за рамково реле на дълги разстояния - оформянето на трафика и кеширането могат да помогнат за отпушване на тръбата.

Конфигурациите за оформяне на трафика са повече изкуство, отколкото наука. Приоритизирането на приложения често е по-скоро политическо, отколкото техническо, но може да има огромни ефекти върху възприеманата производителност на мрежата.

Кеширането е съвсем различен звяр. Това изисква по-малко работа от оформянето на трафика, но въздействието вероятно ще бъде по-малко. Механизмите за кеширане съхраняват и обслужват локални копия на често достъпвани данни, за да намалят WAN трафика. Недостатъкът е, че динамичното съдържание не може истински да се кешира, така че електронната поща няма да се радва на същата производителност.

No 10: Прогнозно закърпване

Пристигате на работа в понеделник, само за да научите, че куп настолни компютри са окачени или че работата на критично приложение се е забавила до обхождане. След разследване вие ​​установявате, че причината е пластирът, който е поставен през уикенда.

Ето защо се нуждаете от инструменти, които поддържат връщане на корекции. Още по-добре включете тестването на кръпки като част от вашата стратегия за управление на кръпки. Първо, трябва да правите редовен опис на приложенията и технологиите в игра на настолни компютри и сървъри. Повечето инструменти за управление на системи, като SMS на Microsoft, имат способността да правят инвентаризация за вас автоматично.

След това репликирайте приложенията и технологиите в променителна среда. Ако вашата операционна система и софтуерът за инфраструктура не включват инструменти за тестване на корекции, вземете инструмент на трета страна, като FLEXnet AdminStudio или Wise Package Studio.

Като алтернатива можете да напишете някои скриптове за функционално упражняване на платформата или технологията с най-новите кръпки в игра. Ще трябва да повторите този сценарий (и да коригирате скриптове), когато пристигат нови кръпки и когато се правят софтуерни промени.