PostgreSQL очень хорошо масштабируется на HT-ядрах. "дополнительное" HT-ядро может добавлять 70% (см. излом на https://elibsystem.ru/node/490).
Т.е. очень грубо, для PostgreSQL 28 ядер с HT2 эффективно будет под 48 ядер без HT.
Умножать ядра на частоту нельзя, но когда очень хочется, то для Intel 48 "эффективных ядер" x 3 ГГц = 144 эффективных ГГц на сервер, а ARM 64 x 2.6 ГГц = эффективных 166 ГГц.
Ну какую-то такую разницу и видно в сравнении производительностей.
На видео выигрыш в 15% в случайном чтении. В остальном разницы существенной нет.
Но и эти 15% могут быть объяснятся архитектурой конкретного чипа в конкретном месте или настройками чего-нибудь. Т.е. измени контроллер и может и этих 15% не будет.
Ceph по ethernet работает. Дисковые ресурсы он тоже только по ethernet умеет отдавать.
Ceph выбирают за отказоустойчивость, выход из строя любого диска или любого (при правильной архитектуре) сервера не приводит к падению работающих на Ceph виртуалок.
В случае выхода из строя диска, который на сервере подключен как DAS (например по nvme), все что на этом диске работает - отвалится.
При использовании сети с nvme ничего принципиально не меняется, тот же FC, только другой -) Соответственно, для отказоустойчивости нужны кластерные файловые системы типа vmfs.
С другой стороны такое же сплошь и рядом, что надо сделать выбор и для этого делаются бенчмарки. Увы, тестировать приходится не всегда то, что знаешь достаточно глубоко.
Если результаты опубликовать, то можно получить критику, которая будет полезна, узнаешь что-то новое.
Добавлю еще плюсов: 4. Высокая скорость разработки сложных интерфейсов на реактивных фреймворках типа React, Vue, для которых также есть большое количество готовых компонент. 5. Как следствие: экономия на создании и поддержке, да и программиста найти проще на JS.
Есть богатый выбор из нативной разработки под каждую платформу отдельно, кроссплатформенной на фреймворках, React Native, Electron и куча другого ПО.
Исходя из требований проекта и надо выбирать, что будет использоваться.
При виртуализации ни зачем. Вернее их иногда виртуалкам пробрасывают, но обычно не нужны.
А зачем эти порты вообще? Что вы в них пихать будете?
Обычно пихают RAID-контроллеры, сетевые карты 10G, адаптеры FC.
RAID-контроллеры не нужны в данном случае, если решили диски локально иметь, FC скорее всего тоже не нужен. Даже в отказоустойчивой конфигурации на пару сетевух 10G много каналов не нужно.
Видеокарты здесь приведены просто как что-то, что способно много полос занять, только и всего.
Сейчас повсюду виртуализация и на сервере не одна задача гоняется, а 100500. Данные множества виртуальных машин надо где-то хранить и это либо покупка выносной очень дорогой хранилки, либо хранить прямо на сервере, но тогда на сервер надо много дисков.
У кого хранилка выносная, надо побольше процессоров да поплотнее, 2U-сервера на 24 диска покупать и не будут.
У вас есть 2U сервер с 24 отсеками под диски и 4 слотами под PCIe-карты, в которые влезет 2 видеокарты по 16 линий.
Вопрос: зачем ставить какие-то хабы к дискам, чтобы "линий сэкономить" поди еще с какими-нибудь кешами, которые будут заканчиваться и правилами "ну из 24 отсеков в ЭТОМ СЕРВЕРЕ ssd пихайте в первые 12, а в остальные 12 пихайте HDD, потому-что мы решили линий сэкономить и хаб на вторые 12 отсеков поставили и там на самом деле 4 линии.
Две видеокарты по 16 линий, это 128 - 32 = 96. Т.е. нехватка линий 2U-серверу ну никак не грозит.
Тогда зачем иметь какие-то ограничения, когда никаких ограничений можно не иметь и в КАЖДЫЙ дисковый отсек привести по линии и забыть, что в какие-то отсеки SSD лучше не подключать?
Чтоб не думать, сколько и каких портов SATA/SAS на мамке разводить. Сколько дисков NVMe в серваке будет и сколько SATA/SAS и выпускать несколько конфигураций серверов с разным соотношением и т.д. и запаривать всем мозг по пропускной способности контроллера.
Унификация, короче, интерфейса подключения, да еще и без тормозов на контроллере, с которой в сервак втыкаются HDD/SSD в любом соотношении и без необходимости кукуху включать.
Ага, даже в самом дешманском EPYC на Zen3 этих линий 128 штук, так что 24 линии выделить на жесткие диски в 2U - не проблема.
Ну я бы по другому акценты расставил. Приказать удалить ресурс спецорганы сервису и сейчас могут. Для этого слушать трафик пользователя не обязательно.
А вот если сервис игнорирует требования государства, оштрафовать его не получается, то тогда начинают давить отключением пользователей.
Если ресурсу без разницы до пользователей, на этом все и завершается, государство удовлетворено, информация заблокирована.
Это не побочный эффект, а цель использования шифрованного канала: чтобы никто в него не лез, даже с целью обезопасить от вредного контента.
А блокировка домена провайдерами - это такой простой способ объяснить сервис-провайдеру, что он либо законодательство РФ выполняет, либо как-нибудь без пользователей из России обойдется.
Adobe AIR уже был (аналог Flutter), при этом на весьма популярном в былые времена AS3. И что, и где он? Это про "Flutter лучше RN". Adobe AIR постоянно ставили в укор не использование нативных компонентов и у RN и было преимущество именно нативные компоненты. В случае с Flutter порицаемый подход AIR почему-то преимуществом оказался.
Почему-то примеры приложений на RN какие-то скупые вышли, а как-же Facebook, Instagram, Skype и множество других?
PostgreSQL очень хорошо масштабируется на HT-ядрах.
"дополнительное" HT-ядро может добавлять 70% (см. излом на https://elibsystem.ru/node/490).
Т.е. очень грубо, для PostgreSQL 28 ядер с HT2 эффективно будет под 48 ядер без HT.
Умножать ядра на частоту нельзя, но когда очень хочется, то для Intel 48 "эффективных ядер" x 3 ГГц = 144 эффективных ГГц на сервер, а ARM 64 x 2.6 ГГц = эффективных 166 ГГц.
Ну какую-то такую разницу и видно в сравнении производительностей.
Думаю, что многие из малоизвестных плагины не поддерживают.
Но припоминаю API для загрузки плагинов, так что если бы это было действительно принципиально, можно было бы и поддержку плагинов обеспечить.
Сам браузер на NW.js по сути тоже работает как расширение.
И как nginx настраивать с PHP-FPM, если nginx еще и статика отдается?
Если уж пошла речь за производительность, то хорошо бы и с preload проверить и unite и php-fpm.
На голой Symfony смотрел и 'hello world' ускорился с preload в 2 раза.
На видео выигрыш в 15% в случайном чтении. В остальном разницы существенной нет.
Но и эти 15% могут быть объяснятся архитектурой конкретного чипа в конкретном месте или настройками чего-нибудь. Т.е. измени контроллер и может и этих 15% не будет.
Ceph по ethernet работает. Дисковые ресурсы он тоже только по ethernet умеет отдавать.
Ceph выбирают за отказоустойчивость, выход из строя любого диска или любого (при правильной архитектуре) сервера не приводит к падению работающих на Ceph виртуалок.
В случае выхода из строя диска, который на сервере подключен как DAS (например по nvme), все что на этом диске работает - отвалится.
При использовании сети с nvme ничего принципиально не меняется, тот же FC, только другой -) Соответственно, для отказоустойчивости нужны кластерные файловые системы типа vmfs.
С другой стороны такое же сплошь и рядом, что надо сделать выбор и для этого делаются бенчмарки. Увы, тестировать приходится не всегда то, что знаешь достаточно глубоко.
Если результаты опубликовать, то можно получить критику, которая будет полезна, узнаешь что-то новое.
Добавлю еще плюсов:
4. Высокая скорость разработки сложных интерфейсов на реактивных фреймворках типа React, Vue, для которых также есть большое количество готовых компонент.
5. Как следствие: экономия на создании и поддержке, да и программиста найти проще на JS.
Есть богатый выбор из нативной разработки под каждую платформу отдельно, кроссплатформенной на фреймворках, React Native, Electron и куча другого ПО.
Исходя из требований проекта и надо выбирать, что будет использоваться.
Preload использовался?
При виртуализации ни зачем. Вернее их иногда виртуалкам пробрасывают, но обычно не нужны.
А зачем эти порты вообще? Что вы в них пихать будете?
Обычно пихают RAID-контроллеры, сетевые карты 10G, адаптеры FC.
RAID-контроллеры не нужны в данном случае, если решили диски локально иметь, FC скорее всего тоже не нужен. Даже в отказоустойчивой конфигурации на пару сетевух 10G много каналов не нужно.
Видеокарты здесь приведены просто как что-то, что способно много полос занять, только и всего.
Сейчас повсюду виртуализация и на сервере не одна задача гоняется, а 100500. Данные множества виртуальных машин надо где-то хранить и это либо покупка выносной очень дорогой хранилки, либо хранить прямо на сервере, но тогда на сервер надо много дисков.
У кого хранилка выносная, надо побольше процессоров да поплотнее, 2U-сервера на 24 диска покупать и не будут.
Вижу, не донес мысль.
У вас есть 2U сервер с 24 отсеками под диски и 4 слотами под PCIe-карты, в которые влезет 2 видеокарты по 16 линий.
Вопрос: зачем ставить какие-то хабы к дискам, чтобы "линий сэкономить" поди еще с какими-нибудь кешами, которые будут заканчиваться и правилами "ну из 24 отсеков в ЭТОМ СЕРВЕРЕ ssd пихайте в первые 12, а в остальные 12 пихайте HDD, потому-что мы решили линий сэкономить и хаб на вторые 12 отсеков поставили и там на самом деле 4 линии.
Две видеокарты по 16 линий, это 128 - 32 = 96. Т.е. нехватка линий 2U-серверу ну никак не грозит.
Тогда зачем иметь какие-то ограничения, когда никаких ограничений можно не иметь и в КАЖДЫЙ дисковый отсек привести по линии и забыть, что в какие-то отсеки SSD лучше не подключать?
Чтоб не думать, сколько и каких портов SATA/SAS на мамке разводить. Сколько дисков NVMe в серваке будет и сколько SATA/SAS и выпускать несколько конфигураций серверов с разным соотношением и т.д. и запаривать всем мозг по пропускной способности контроллера.
Унификация, короче, интерфейса подключения, да еще и без тормозов на контроллере, с которой в сервак втыкаются HDD/SSD в любом соотношении и без необходимости кукуху включать.
Ага, даже в самом дешманском EPYC на Zen3 этих линий 128 штук, так что 24 линии выделить на жесткие диски в 2U - не проблема.
Ну я бы по другому акценты расставил. Приказать удалить ресурс спецорганы сервису и сейчас могут. Для этого слушать трафик пользователя не обязательно.
А вот если сервис игнорирует требования государства, оштрафовать его не получается, то тогда начинают давить отключением пользователей.
Если ресурсу без разницы до пользователей, на этом все и завершается, государство удовлетворено, информация заблокирована.
Это не побочный эффект, а цель использования шифрованного канала: чтобы никто в него не лез, даже с целью обезопасить от вредного контента.
А блокировка домена провайдерами - это такой простой способ объяснить сервис-провайдеру, что он либо законодательство РФ выполняет, либо как-нибудь без пользователей из России обойдется.
Если плагинов нужно много, то легче оказывается нативно писать.
С использованием чужих готовых есть риск получить несовместимости на новых версиях ОС и автор оригинальных плагинов может не торопиться их исправлять.
Ну а так как фича для плагина обычно требуется на всех платформах, получается, что экспертизу надо иметь на всех платформах + Flutter.
Кхе, думаю доживем и до temp.scopus.com и до temp.webofscience.com.
Особенно когда поймут, что пропаганда нетрадиционных ценностей может и в научных статьях сидеть в виде оправдания -)
Ну типа библиотека не должна деньги департаменту отдавать и так-то должна сама их тратить как внебюджетные доходы.
Ну еще все налоги в этой цепочке заплатят.
В библиотеках типа сами проверять должны списки запрещенки и изымать из фонда запрещенное.
За выдачу запрещенки, если поймают, могут быть проблемы.
Adobe AIR уже был (аналог Flutter), при этом на весьма популярном в былые времена AS3. И что, и где он? Это про "Flutter лучше RN". Adobe AIR постоянно ставили в укор не использование нативных компонентов и у RN и было преимущество именно нативные компоненты. В случае с Flutter порицаемый подход AIR почему-то преимуществом оказался.
Почему-то примеры приложений на RN какие-то скупые вышли, а как-же Facebook, Instagram, Skype и множество других?