masyan, SychevIgor, olegfil, zolti — после ваших сообщений я подумал и переделал тест в части Azure. Не сказать, чтобы ему это сильно помогло, итоговый расклад не поменяло, но все что смог — то сделал.
Ядер то столько же — 4, тип инстанса другой. Возможно ограничение триала, да. А может что-то еще. Но тем не менее я делаю ретест с использованием F4s. По производительности там все неплохо, но в пересчете на деньги все равно печально.
Я эти строки не сохранял отдельно, в статье есть пример вывода и скрипт. Но учитывая что включен сихронный режим, известен размер блока и IOPS, то латенси можно посчитать же.
Окей, там есть F4s. Могу сделать ретест на нее. Там есть еще F4s_v2, но Azur мне говорит что она мне недоступна с моей подпиской. Странно, ну да ладно.
P.S. В списке и A-тип обозначен как General purpose, что ну никак не намекает на то, что они слабые.
Vultr выглядит очень вкусно с точки зрения цен, правда он не совсем «облако», так как кроме серверов ничего не предоставляет, как я вижу, что не совсем вписыватеся в условия теста.
написали далеко идущие выводы якобы опираясь на то что «обычный» человек будет делать так-же как Вы (то есть не пользоваться поиском в интернете)?
Вы italic написание в статье специально игнорируете?:)
У меня к вам такой вопрос, раз все просто — почему из интерфейса вообще можно купить машину дороже, но слабже и при этом она первая в списке?
А так, я там уже выше писал — озвучивайте материковый регион в Европе, тип инстанса с 4CPU/8Гб памяти (именно столько, не больше, не меньше) и я сделаю перетест. Мне не сложно, я за справедливость.
Ну значит это в конкретном случае скорость из Амазона через CloudFlare до Амазона была хуже, чем из Гугла через CloudFlare до Амазона. Дело в CloudFlare.
Кстати, никогда не замечал, чтобы у Амазона сеть была плохая, но у Гугла по этому поводу есть отличная фича — у них аналог VPC (это не совсем именно VPC, там вообще несколько другой концепт) кросс-региональный и можно в рамках одной сети без всяких пирингов запускать нагрузку в любом регионе с очень быстрой локальной сетью.
Как правило, переезд в облако начинается именно с перетаскивания какой-то текущей нагрузки с параллельным перепиливанием ее под особенности платформы. Но, конечно, всякое бывает.
Но вообще, достаточно много проектов при мне начинались с «нам нужны виртуалки, объектный сторадж, базы и балансер», что в целом есть практически у всех (у большой тройки точно есть) и самое дорогое в этом наборе, не считая трафика (который вполне может встать дороже, чем все остально вместе взятое) — это виртуалки.
Набор сервисов как минимум большой тройки весьма схож и все умеют практически все, что можно представить, плюс — со своими уникальными сервисами.
Я кстати в статье специально сделал ремарку по поводу того, что речь идет исключительно о «накликать виртуалок в облаке и посмотреть насколько они быстрые», а не о выборе платформы как таковой с учетом всех ее особенностей.
Ну и, еще раз, если даже подходящую виртуалку выбрать настолько неочевидно, то это не признак того, что все настолько круто, что архитект нужен, а того, что все настолько мутно, что архитект нужен.
На смотря на всю крутость трех больших платформ в плане количества сервисов (а AWS как бы не побольше Azure будет), на двух из них по крайней мере невозможно купить машину дороже, но слабже, натыкиывая ее в интерфейсе.
Тогда надо хотя бы указать, что одним только наращиванием диска можно ту же дисковую производительность поднять
В условиях теста четко указан размер диска.
Из AWS можно выжать очень неплохую производительность диска, но это за рамками обзора.
а если использовать reserved instance, то и цены на треть упадут, с ходу.
И это уже не on-demand, а у нас сравнение условий по on-demand нодам.
Так-то почти любой вендор может еще и персональные условия дать при определенных обстоятельствах, причем достаточно вкусные, но это не повод ориентироваться на них.
На счет AWS по-умолчанию — тут очень размытое понятие. Reserved вот тоже много кто не берет по определенным причинам (непостоянная нагрузка, неуверенность в типе нод, быстроменяющиеся обстоятельства), так что pay as you go вполне корректное сравнение, дальше идет набор уловок, чтобы замкнуть кастомера на себя.
Если интересует именно GPU, то там никаких чудес, производительность та же, как если бы вы использовали заявленную карту локально (за вычетом производительности самой машины в тех вопросах, что не касаются GPU расчетов). У AWS/GCE в документации подробно написано что за карты используются, а тесты их легко гуглятся.
Базы как сервис интересны в первую очередь другим — отсутствием затрат на обслуживание, пусть даже путем некоторой переплаты.
Для того же ClickHouse сейчас такой сервис предлагает только Yandex, так что сравнивать такое не очень корректно. Да и не у всех впринципе есть сервис баз.
С Azure к сожалению все весьма запутано и неоднозначно, вместе с ценовой политикой.
Если человек просто придет выбирать облако, равно зная, а точнее не зная, тонкости каждого из вариантов, то он получит как раз такую картину.
У них в самой системе ценообразования сломан принцип «дешевле-больше(быстрее)» и если кому-то надо быть архитектором по этому облаку чтобы просто выбрать подходящую машинку — ну, это, мягко говоря, не очень хорошо.
Но я тут уже попросил товарища из комментария выше предложить свой варинт машины для перетеста, так что посмотрим.
Честно говоря я бы сказал это обо всем интерфейсе Azure. Мне всегда казалось, что AWS накрутил у себя излишне сложно, пока вот его не увидел.
Дело в том, что от размера диска и его типа зависят и его параметры по performance (iops/Throughput)
У AWS тоже. Диск был 32 Гб, потому что он не умеет выдавать произвольный размер, в отличие от всех участников, условие было — диск на 50Гб, ну я и оставил дефолтный. Можно было бы на 64 наверное, но к производительности диска (в целом), претензий то больших нет.
стоимость ресрсов в разных регионах отличаются именно по этому — взял где-то в Европе- звучит крайне не серьезным подходом
Если бы я шел путем оптимизиции стоимости в целом, я бы взял машины на AWS и GCE в Штатах, они там самые дешевые, но тем не менее я взял материковую Европу, так как у всех остальных сервера там же.
Что касается типов машин. Из всех предложенных вами 4 ядрами и именно 8 Гб памяти обладает только F4s v2 которая, теоретически, в 2 раза быстрее.
Это явно не поменяет финансовую картину, но давайте так.
У вас я так понимаю есть подходящая компетенция — предложите мне вариант машины, в которой ровно 4 ядра и ровно 8 гб памяти с диском на 50Гб (ну или пусть будет 64) в Европе на материке, я его померю и добавлю в эту (сделаю апдейт) или следующую статью (если наберется материала). Идет?
Именно. А у других они отсутствуют. Ровно по этой причине я тестировал машинки «по-умолчанию», без каких либо оптимизаций и фич (стоящих отдельных денег), которые к тому же есть у одних, но нет у других.
Но, к слову, если докинуть в тестовую машинку выделение процессора, утроить размер диска и изменить его тип на io1, то стоимость машины прилично уедет вперед и станет совсем неконкурента на фоне остальных, тогда ценовое сравнение потеряет смысл.
Да и у иностранных не указаны, на самом деле.
Цель сравнения была понять именно стоимость небольшой машинки в комплекте, а 50Гб диск и так самая минималка. Пересчитать без его стоимости могу конечно, но это совсем однобоко получится.
Но в любом случае, спасибо за предложение.
Поддержу.
Товарищ fwm, у меня несколько вопросов:
1. Сколько было итераций для получения каждой цифры?
2. Сколько машин проверялось в каждом клауде?
Плюс, у вас цифры со скриншотов не бьются с теми, что в таблице. Посмотрите на stress-ng тест, значений со скрина нет в таблице. Что это было?
Сомнения у меня большие в этом тесте, ой большие. Не заказуха ли?
Кстати, у меня есть некоторое кол-во машинок (в разных зонах доступности) в Я.Облаке для одного проекта и я решил прогнать ваши тесты (отдельное «спасибо» за ключи запуска на скриншотах вместо текста).
Все машинки 100%, 2CPU/2GB, нагрузка в виде Kubernetes-мастеров со всей обвязкой не выгружалась. Машинки в разных зонах доступности.
Вот что получилось:
#### 1 CPU, Server 1, iter 1
stress-ng --cpu 1 --cpu-method matrixprod --metrics-brief -t 60
...
stress-ng: info: [29104] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: info: [29104] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: info: [29104] cpu 9577 60.00 59.54 0.24 159.61 160.20
#### 1CPU, Server 1, iter 2
stress-ng --cpu 1 --cpu-method matrixprod --metrics-brief -t 60
...
stress-ng: info: [1585] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: info: [1585] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: info: [1585] cpu 9616 60.00 59.54 0.24 160.26 160.86
#### 2 CPU, Server 1, iter 1
stress-ng --cpu 2 --cpu-method matrixprod --metrics-brief -t 60
...
stress-ng: info: [31641] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: info: [31641] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: info: [31641] cpu 8795 60.01 111.70 0.69 146.56 78.25
#### 2CPU, Server 1, iter 2
stress-ng --cpu 2 --cpu-method matrixprod --metrics-brief -t 60
...
stress-ng: info: [32419] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: info: [32419] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: info: [32419] cpu 8743 60.01 112.04 0.67 145.70 77.57
Для второго сервера:
#### 1CPU, Server 2, iter 1
# stress-ng --cpu 1 --cpu-method matrixprod --metrics-brief -t 60
stress-ng: info: [27228] dispatching hogs: 1 cpu
..
stress-ng: info: [27228] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: info: [27228] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: info: [27228] cpu 10142 60.00 59.71 0.07 169.03 169.66
#### 1CPU, Server 2, iter 2
stress-ng --cpu 1 --cpu-method matrixprod --metrics-brief -t 60
...
stress-ng: info: [27944] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: info: [27944] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: info: [27944] cpu 10121 60.01 59.92 0.00 168.67 168.91
#### 2CPU, Server 2, iter 1
stress-ng --cpu 2 --cpu-method matrixprod --metrics-brief -t 60
...
stress-ng: info: [29059] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: info: [29059] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: info: [29059] cpu 9055 60.01 111.35 1.04 150.90 80.57
#### 2CPU, Server 2, iter 2
stress-ng --cpu 2 --cpu-method matrixprod --metrics-brief -t 60
...
stress-ng: info: [29702] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: info: [29702] cpu 9084 60.00 111.53 0.95 151.39 80.76
Сводными данными:
1. В один поток на одном сервере 9596 средняя, на другом 10131. Даже с учетом фоновой ненулевой нагрузки.
2. В два потока на двухядерных машинах даже МЕДЛЕННЕЕ, чем в один. Вероятно потому, что продаются потоки исполнения процессоров, а не честные физические ядра.
Расскажете, как получились ваши результаты?
P.S. На этих машинках какой то Haswell с 2ГГц на ядро, точнее из системы не видно.
Ядер то столько же — 4, тип инстанса другой. Возможно ограничение триала, да. А может что-то еще. Но тем не менее я делаю ретест с использованием F4s. По производительности там все неплохо, но в пересчете на деньги все равно печально.
P.S. В списке и A-тип обозначен как General purpose, что ну никак не намекает на то, что они слабые.
Вы italic написание в статье специально игнорируете?:)
У меня к вам такой вопрос, раз все просто — почему из интерфейса вообще можно купить машину дороже, но слабже и при этом она первая в списке?
А так, я там уже выше писал — озвучивайте материковый регион в Европе, тип инстанса с 4CPU/8Гб памяти (именно столько, не больше, не меньше) и я сделаю перетест. Мне не сложно, я за справедливость.
Ну значит это в конкретном случае скорость из Амазона через CloudFlare до Амазона была хуже, чем из Гугла через CloudFlare до Амазона. Дело в CloudFlare.
Кстати, никогда не замечал, чтобы у Амазона сеть была плохая, но у Гугла по этому поводу есть отличная фича — у них аналог VPC (это не совсем именно VPC, там вообще несколько другой концепт) кросс-региональный и можно в рамках одной сети без всяких пирингов запускать нагрузку в любом регионе с очень быстрой локальной сетью.
Но вообще, достаточно много проектов при мне начинались с «нам нужны виртуалки, объектный сторадж, базы и балансер», что в целом есть практически у всех (у большой тройки точно есть) и самое дорогое в этом наборе, не считая трафика (который вполне может встать дороже, чем все остально вместе взятое) — это виртуалки.
Набор сервисов как минимум большой тройки весьма схож и все умеют практически все, что можно представить, плюс — со своими уникальными сервисами.
Я кстати в статье специально сделал ремарку по поводу того, что речь идет исключительно о «накликать виртуалок в облаке и посмотреть насколько они быстрые», а не о выборе платформы как таковой с учетом всех ее особенностей.
Ну и, еще раз, если даже подходящую виртуалку выбрать настолько неочевидно, то это не признак того, что все настолько круто, что архитект нужен, а того, что все настолько мутно, что архитект нужен.
На смотря на всю крутость трех больших платформ в плане количества сервисов (а AWS как бы не побольше Azure будет), на двух из них по крайней мере невозможно купить машину дороже, но слабже, натыкиывая ее в интерфейсе.
В условиях теста четко указан размер диска.
Из AWS можно выжать очень неплохую производительность диска, но это за рамками обзора.
И это уже не on-demand, а у нас сравнение условий по on-demand нодам.
Так-то почти любой вендор может еще и персональные условия дать при определенных обстоятельствах, причем достаточно вкусные, но это не повод ориентироваться на них.
На счет AWS по-умолчанию — тут очень размытое понятие. Reserved вот тоже много кто не берет по определенным причинам (непостоянная нагрузка, неуверенность в типе нод, быстроменяющиеся обстоятельства), так что pay as you go вполне корректное сравнение, дальше идет набор уловок, чтобы замкнуть кастомера на себя.
Для того же ClickHouse сейчас такой сервис предлагает только Yandex, так что сравнивать такое не очень корректно. Да и не у всех впринципе есть сервис баз.
Если человек просто придет выбирать облако, равно зная, а точнее не зная, тонкости каждого из вариантов, то он получит как раз такую картину.
У них в самой системе ценообразования сломан принцип «дешевле-больше(быстрее)» и если кому-то надо быть архитектором по этому облаку чтобы просто выбрать подходящую машинку — ну, это, мягко говоря, не очень хорошо.
Но я тут уже попросил товарища из комментария выше предложить свой варинт машины для перетеста, так что посмотрим.
Честно говоря я бы сказал это обо всем интерфейсе Azure. Мне всегда казалось, что AWS накрутил у себя излишне сложно, пока вот его не увидел.
У AWS тоже. Диск был 32 Гб, потому что он не умеет выдавать произвольный размер, в отличие от всех участников, условие было — диск на 50Гб, ну я и оставил дефолтный. Можно было бы на 64 наверное, но к производительности диска (в целом), претензий то больших нет.
Если бы я шел путем оптимизиции стоимости в целом, я бы взял машины на AWS и GCE в Штатах, они там самые дешевые, но тем не менее я взял материковую Европу, так как у всех остальных сервера там же.
Что касается типов машин. Из всех предложенных вами 4 ядрами и именно 8 Гб памяти обладает только F4s v2 которая, теоретически, в 2 раза быстрее.
Это явно не поменяет финансовую картину, но давайте так.
У вас я так понимаю есть подходящая компетенция — предложите мне вариант машины, в которой ровно 4 ядра и ровно 8 гб памяти с диском на 50Гб (ну или пусть будет 64) в Европе на материке, я его померю и добавлю в эту (сделаю апдейт) или следующую статью (если наберется материала). Идет?
Именно. А у других они отсутствуют. Ровно по этой причине я тестировал машинки «по-умолчанию», без каких либо оптимизаций и фич (стоящих отдельных денег), которые к тому же есть у одних, но нет у других.
Но, к слову, если докинуть в тестовую машинку выделение процессора, утроить размер диска и изменить его тип на io1, то стоимость машины прилично уедет вперед и станет совсем неконкурента на фоне остальных, тогда ценовое сравнение потеряет смысл.
Цель сравнения была понять именно стоимость небольшой машинки в комплекте, а 50Гб диск и так самая минималка. Пересчитать без его стоимости могу конечно, но это совсем однобоко получится.
Но в любом случае, спасибо за предложение.
Товарищ fwm, у меня несколько вопросов:
1. Сколько было итераций для получения каждой цифры?
2. Сколько машин проверялось в каждом клауде?
Плюс, у вас цифры со скриншотов не бьются с теми, что в таблице. Посмотрите на stress-ng тест, значений со скрина нет в таблице. Что это было?
Сомнения у меня большие в этом тесте, ой большие. Не заказуха ли?
Кстати, у меня есть некоторое кол-во машинок (в разных зонах доступности) в Я.Облаке для одного проекта и я решил прогнать ваши тесты (отдельное «спасибо» за ключи запуска на скриншотах вместо текста).
Все машинки 100%, 2CPU/2GB, нагрузка в виде Kubernetes-мастеров со всей обвязкой не выгружалась. Машинки в разных зонах доступности.
Вот что получилось:
Для второго сервера:
Сводными данными:
1. В один поток на одном сервере 9596 средняя, на другом 10131. Даже с учетом фоновой ненулевой нагрузки.
2. В два потока на двухядерных машинах даже МЕДЛЕННЕЕ, чем в один. Вероятно потому, что продаются потоки исполнения процессоров, а не честные физические ядра.
Расскажете, как получились ваши результаты?
P.S. На этих машинках какой то Haswell с 2ГГц на ядро, точнее из системы не видно.