Профессиональное: Автоматизированное тестирование: Многопоточности пост
Вся описываемая ниже эпопея началась достаточно давно.
Пожалуй вот этот пост и был началом этой истории.
Именно тогда по примеру своего товарища cartmendum я попытался измерить то, что уже имею.
Измерения не порадовали глаз, но породили в мозгу желание изменить соотношение времени между подготовкой к тестированию и самим тестированием.
Мысль о том, что многопоточность при развертывании схемы тестового стенда может существенно сократить общее время тестового раунда пришла в голову легко и непринужденно. Соль ситуации была лишь в том, что многопоточным программированием я никогда не занимался, да и полигона (в виде выделенного мощного сервера) для проверки гипотезы ни у меня, ни у организации тоже не было.
Прошло много времени, тов. cartmendum писал много интересных вещей, в том числе про то как анализировать время задач и выявлять в них Waste.
А потом,в сентябре этого года к нам из далекого Китая от фирмы с неблагозвучным для русского уха названием Huawei приплыл новенький сервер.
И вот тогда было решено отложить все в сторону, и проверить гипотезу.
А заодно и измерить какие результаты мы получим.
Дописал движок, приготовил Excel, и начал.
Вот что получилось на выходе.
Так изменялось общее время развертывания по мере увеличения числа параллельно запускаемых потоков.
Самый главный вывод который был сделан - если запускать более трех потоков развертывания одновременно серьезного прироста производительности ждать не стоит.
Хотя у сервера остаются свободные аппаратные ресурсы, время меняется не сильно.
Более того - так как с большой вероятностью функция времени развертывания от числа потоков является степенной, то у нее есть асимптота (смысл асимптоты курите в педивикии).
Вторым аргументом в пользу этой гипотезы послужило то, что абсолютное время развертывания на каждом типе ОС при росте числа параллельных потоков также начало расти при числе потоков больше трех.
Таким образом я с помощью Excel выяснил сколько потоков можно запускать без потери эффективности.
При таком количестве потоков мы получаем троекратное сокращение общего времени развертывания.
Ну и двухкратное сокращение общего времени процесса в целом (развертывание + тестирование).
До релиза всей этой радости в продакшн еще далеко, но первый шаг уже сделан.
К чему я все это написал???
Пожалуй вот этот пост и был началом этой истории.
Именно тогда по примеру своего товарища cartmendum я попытался измерить то, что уже имею.
Измерения не порадовали глаз, но породили в мозгу желание изменить соотношение времени между подготовкой к тестированию и самим тестированием.
Мысль о том, что многопоточность при развертывании схемы тестового стенда может существенно сократить общее время тестового раунда пришла в голову легко и непринужденно. Соль ситуации была лишь в том, что многопоточным программированием я никогда не занимался, да и полигона (в виде выделенного мощного сервера) для проверки гипотезы ни у меня, ни у организации тоже не было.
Прошло много времени, тов. cartmendum писал много интересных вещей, в том числе про то как анализировать время задач и выявлять в них Waste.
А потом,в сентябре этого года к нам из далекого Китая от фирмы с неблагозвучным для русского уха названием Huawei приплыл новенький сервер.
И вот тогда было решено отложить все в сторону, и проверить гипотезу.
А заодно и измерить какие результаты мы получим.
Дописал движок, приготовил Excel, и начал.
Вот что получилось на выходе.
Так изменялось общее время развертывания по мере увеличения числа параллельно запускаемых потоков.
Самый главный вывод который был сделан - если запускать более трех потоков развертывания одновременно серьезного прироста производительности ждать не стоит.
Хотя у сервера остаются свободные аппаратные ресурсы, время меняется не сильно.
Более того - так как с большой вероятностью функция времени развертывания от числа потоков является степенной, то у нее есть асимптота (смысл асимптоты курите в педивикии).
Вторым аргументом в пользу этой гипотезы послужило то, что абсолютное время развертывания на каждом типе ОС при росте числа параллельных потоков также начало расти при числе потоков больше трех.
Таким образом я с помощью Excel выяснил сколько потоков можно запускать без потери эффективности.
При таком количестве потоков мы получаем троекратное сокращение общего времени развертывания.
Ну и двухкратное сокращение общего времени процесса в целом (развертывание + тестирование).
До релиза всей этой радости в продакшн еще далеко, но первый шаг уже сделан.
К чему я все это написал???
- Считайте. Не все можно измерить цифрами, не на все можно придумать метрики, иногда это как минимум бесполезно, порою даже вредно. Но все равно - считайте. Цифры - вещь куда как более строгая, чем слова.
- Визуализируйте. Картинки воспринимаются еще лучше чем цифры.
- Ищите waste. Его не обязательно устранять как только вы его нашли - у меня почти год не было возможности это сделать. Но надо знать где он, понимать его природу. Это даст вам пищу для размышлений, и почву для идей как это исправить.