Тестирование времени загрузки EC2

На прошлой неделе я незаметно выпустил ec2-boot-bench , инструмент для тестирования времени загрузки инстанса EC2. Этот инструмент имеет лицензию BSD и должен компилироваться и запускаться в любой системе POSIX с установленным OpenSSL или LibreSSL. Использовать просто – дайте ему ключи AWS и скажите, что тестировать:

 использование: ec2-boot-bench --keys  --region  --ami  --itype    [--user-data ] 

и выводит четыре значения – сколько времени потребовалось для вызова API RunInstances, сколько времени потребовалось EC2 для получения экземпляра из состояния ожидания в состояние выполнения, сколько времени прошло, когда экземпляр был запущен до порта TCP / 24 был “закрыт” (также известный как отправка пакета SYN возвращала RST), и сколько времени это заняло когда TCP / 25 был «закрыт» до того момента, когда он был «открыт» (иначе говоря, отправка SYN возвращала SYN / ACK):

 Для вызова API RunInstances потребовалось: 1. 643463. до работы потребовалось: 4. 904754 с переходом от работы к закрытому порту взял: 19. 175601 s Движение из порта от закрытого до открытого порта потребовалось: 5. 904754 с 

Как только я закончил писать ec2-boot-bench, следующим естественным шагом было выполнение некоторых тестов – в частности, чтобы увидеть, как FreeBSD по сравнению с другими операционные системы, используемые в EC2. Я использовал тип экземпляра c5.xlarge и тестировал выпуски FreeBSD, начиная с 15. 1-RELEASE (первый выпуск FreeBSD, который может работать с экземпляром типа c5.xlarge) вместе с диапазоном AMI Linux в основном берутся из меню «быстрого запуска» в консоли AWS. Чтобы выполнить сравнение яблок с яблоками, я передал файл пользовательских данных экземплярам FreeBSD, которые отключили некоторое поведение «при первой загрузке» – по умолчанию AMI выпуска FreeBSD обновляются и перезагружаются, чтобы обеспечить необходимую безопасность. исправления перед их использованием, в то время как Linux просто оставляет обновления безопасности для пользователей, чтобы установить их позже:

 >> / etc / rc.conf firstboot_freebsd_update_enable = "NO" firstboot_pkgs_enable = "NO" 

Для каждого тестируемого AMI я запускал ec2-boot-bench 13 раз, отбросил первый результат и взял средние значения из оставшихся 9 прогонов. Первые два значения – время, затраченное на успешный возврат вызова API RunInstances, и время, затраченное после возврата RunInstances до того, как вызов DescribeInstances говорит о том, что экземпляр «запущен» – согласованы для всех тестируемых мной AMI, примерно 1,5 и 6,9 секунды соответственно; поэтому числа, которые нам нужно посмотреть для сравнения AMI, – это всего лишь два последних значения, сообщаемых ec2-boot-bench, а именно время до того, как стек TCP / IP будет запущен и имеет IP-адрес, и время между этой точкой и временем sshd запущен.

Результаты моего тестирования следующие:

работает с портом закрыто 0. 03 Сервер Ubuntu 18. 10 LTS 25. 32 FreeBSD 15. 2-РЕЛИЗ SUSE Linux Enterprise Сервер 18 SP2
Идентификатор AMI (us -east-1) Имя AMI
закрыто на открытие Всего
ami-0f9ebbb6ab 174До нашей эры27 Очистить Linux 52998 1. 26
1. 25
ами – 12 d 05 ee1eeb0c 01599 c Debian 13 6. 28 4. 11 12. 42
ami-0c2b8ca1dad 712 f8a Amazon Linux 2 9. 59 1. 59 13. 10
ами – 12 е 74 e 447 f 27 ce0d7 Сервер Ubuntu 22. 07 LTS 7. 43 4. 67 13. 09
ами – 822 bdcabd 36 c 712 a Сервер Ubuntu 20. 10 LTS 11. 66 4. 32 18. 96
ami-0ee 07 acd 59 a 52998 e
16. 80 5. 45 21. 19
ami-0a 19 c 2295 ef 81 ff 65 SUSE Linux Enterprise Server 14 SP5 18. 34 6. 97
ами – 05быть89 d9bba 32 a7b3
20. 13 6. 24 24. 34
ами – 04 e 93 cb 83 b 426 d 18 f FreeBSD 16. 0-РЕЛИЗ 22. 05 5. 15 26. 16
ami-0fde 52 fcbcd 54 f2f7

21. 14 6. 80 27. 91
ами – 07 b0f 996 e 17669866 FreeBSD 15. 0- РЕЛИЗ 22. 86 5. 86 27. 65
ami-0de 335 ac 2498 ba 34 d

FreeBSD 15. 1-РЕЛИЗ 20. 93 6. 12 28. 05
ami-0b 96 е 8856151 afb3a FreeBSD 13. 3-РЕЛИЗ 25. 64 5. 11 27. 72
ами- 70504266 FreeBSD 14. 1-РЕЛИЗ 27. 76 4. 42 33. 12
ami-e 86 e6c 174 FreeBSD 14. 2-РЕЛИЗ 27. 50 5. 42 32. 82
ами – 2295 ad2c 214322 ae FreeBSD 12. 4-РЕЛИЗ 59. 20 4. 04 63. 23
ami-0b0af 34640 fe5e 3532 Red Hat Enterprise Linux 8 15. 46 55. 33 67. 80

В гонке на AC За исключением входящих SSH-соединений, явным победителем – без каламбура – является Intel Clear Linux , который загружается в работающий sshd в быстроразвивающемся 1. 25 секунд после того, как экземпляр перейдет в состояние «работает». После Clear Linux существует примерно трехсторонняя связь между Amazon Linux, Debian и Ubuntu – и приятно видеть, что производительность загрузки Ubuntu с годами улучшилась, упав с 20 секунд в 19. 10 LTS в 17 секунд в 20. 10 LTS, а затем в 14 секунд с 22. 07 LTS. После кластера Amazon Linux / Debian / Ubuntu идут SUSE Linux и FreeBSD; вот что интересно, SUSE 16 быстрее, чем SUSE 17, а FreeBSD 15. 2 и 16. 0 (два последних релиза) заметно быстрее старых FreeBSD.

Наконец, на последнем месте стоит Red Hat, которая быстро поднимает свой сетевой стек, но запускает sshd очень долго. Возможно, Red Hat делает что-то похожее на поведение, которое я отключил во FreeBSD, при загрузке и установке обновлений безопасности перед тем, как открыть sshd в сети – я не знаю достаточно, чтобы здесь комментировать. (Если кто-то, читающий это, может подтвердить эту возможность и имеет способ отключить такое поведение с помощью пользовательских данных, я буду счастлив повторно запустить тест и отредактировать этот пост.)

Излишне говорить, что FreeBSD есть над чем поработать, чтобы наверстать упущенное; но измерение – это первый шаг, и действительно, у меня уже есть работа по дальнейшему профилированию и повышению производительности загрузки FreeBSD, о чем я напишу в одном из следующих постов.

Если вы сочтете это полезным, пожалуйста, рассмотрите возможность поддержки моей работы через мои FreeBSD / EC2 Patreon или отправив мне материалы напрямую. В то время как моя работа над платформой FreeBSD / EC2 исходила из потребностей моего Tarsnap онлайн-сервис резервного копирования, с годами он стал гораздо более масштабным проектом, и мне было бы намного удобнее тратить на это время, если бы это не отнимало так непосредственно у моей «оплачиваемой работы».

комментарии в блогах, разработанные Disqus

Leave a comment

Your email address will not be published. Required fields are marked *

four × three =