Как да следите тестовете за ефективност

В момента правя тестове за производителност и натоварване на сложна многослойна система, изследвайки ефекта от различни промени, но имам проблеми с проследяването на всичко:

  • There are many copies of different assemblies
    • Orignally released assemblies
    • Официално пуснати актуални корекции
    • Сглобки, които съм създал, съдържащи допълнителни допълнителни поправки
    • Сглобки, които съм изградил, съдържащи допълнително диагностично регистриране или проследяване
  • Има много корекции на бази данни, някои от горните модули зависят от прилагането на определени корекции на база данни
  • Съществуват много различни нива на регистриране в различни нива (регистриране на приложения, статистика за ефективността на приложението, профилиране на SQL сървър)
  • Има много различни сценарии, понякога е полезно да тествам само 1 сценарий, друг път трябва да тествам комбинации от различни сценарии.
  • Зареждането може да бъде разделено между няколко машини или само една машина
  • Данните, присъстващи в базата данни, могат да се променят, например някои тестове могат да бъдат направени с генерирани данни, а по-късно с данни, взети от активна система.
  • There is a massive amount of potential performance data to be collected after each test, for example:
    • Many different types of application specific logging
    • Следи на SQL Profiler
    • Регистри на събития
    • DMVs
    • Броячи на Perfmon
  • Базата данни(ите) е с размер няколко Gb, така че там, където бих използвал резервни копия, за да се върна към предишно състояние, имам склонност да прилагам промени към всяка база данни, която е налице след последния тест, което ме кара бързо да губя проследяване на нещата.

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

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

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

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


person Justin    schedule 09.09.2009    source източник


Отговори (3)


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

Но вие го дължите на себе си да го опитате.

person orip    schedule 09.09.2009

Склонен съм да се съглася с @orip, скриптирането на поне част от работното ви натоварване вероятно ще ви спести време. Бихте могли да отделите малко време, за да попитате кои задачи отнемат най-много време от гледна точка на вашия труд и доколко те са податливи на автоматизация? Скриптовете са особено добри в събирането и обобщаването на данни - обикновено много по-добре от хората. Ако данните за ефективността изискват много тълкуване от ваша страна, може да имате проблеми.

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

person DaveParillo    schedule 10.09.2009

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

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

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

person Mike Burrows    schedule 11.09.2009