Ну собственно creker правильно написал: корпоративные хранилки могут гарантировать запись кеша при обесточивании, поэтому хранилки могут не скидывать все из кеша на диск и сразу отвечать на fsync что типа записали.
В некоторых SSD есть аккумуляторы из конденсаторов, такие точно также могут работать.
По поводу производительности, было дело, наобещал заказчику, что будет 98 баллов, открываем, измеряем и тут оказывается, что оно в районе 73 и в желтой зоне.
Тут-то я и узнал, что производительность не нормализуется и измеряется в браузере на конкретном железе и если у тебя 98 баллов, это не значит, что у всех 98 баллов.
Я погуглил и ничего такого не нашел, что бы можно было в браузере открыть и оно бы типичные (самые популярные) сайты протестило с нагрузкой и по JS и по DOM и какие-то баллы написало.
Вроде припоминаю, что некоторе бенчмарки компьютеров такое внутри себя тестируют, но видимо встроенным движком и просто так в браузере это все не узнать.
Оно печально, что бенчи в основном на JS сосредоточены или webgl, но уж как есть.
Не вопрос, предложите другой, который бенчить будет не только JS, но и DOM, причем так, чтобы нагрузка отражала типичное использование браузера.
Надо только учитывать, что без аппаратной поддержки GPU бенчи webgl и т.п. могут совсем грустные результаты выдавать.
Один из аргументов за этот тест: многие веб-страницы сейчас по 1МБ JS-кода в минифицированном виде содержат, поэтому производительнось JS-движка важна. Но согласен, реальные страницы содержать гораздо более сложный DOM чем в Speedometer2.0.
Покликал на Odroid N2+ разные сайты и некоторые (где страницы большие) загружают в 100% по htop все ядра, а некоторые не могут и одно ядро (опять же по htop) загрузить.
Ну дак нет отличий с моим скриншотом. Да, процессор в полку не грузится, но и не так, что загружено только одно ядро. Что, в общем, говорит о том, что в процессор тест не упирается. Напомню на всякий случай, что JavaScript однопоточный движок и больше ядер он будет грузить если воркеры создавать, которые в простейшем todo-list очевидно не нужны. Но браузеры не одно ядро грузят, так как на скачивание у них отдельные потоки порождаются, композиция и рендеринг тоже могут быть по потокам разнесены и выполняться как на GPU, так и на CPU с естественно разной нагрузкой на ядра.
Что касается 1000 комментов - да, у меня тоже в потолок нагрузка при этом, но это другой тест. 1000 комментов - это большой DOM и нагрузка идет на работу с DOM. В данном тесте DOM маленький и можно считать, что нагружается в первую очередь JS-движок.
Создается впечатление, что взяли монитор, оторвали заднюю крышку и на клей приклеили плату с пластиковым чехлом. Ну в принципе и ладно, специализированных под моноблок плат все равно нет, пусть будет так.
А вот что подключение монитора к плате идет "снаружи" - да это же гениально! Выдергиваешь Байкал, подключаешь Windows и нормально работаешь. А будет проверка - перетыкаешь кабель и готово.
З.Ы. дарю производителю идею: сделать моноблок 2in1: разместить в одном моноблоке две платы, одну на Байкале и одну с виндой на x86 и переключаться одной кнопкой -)
Этот тест прогоняет множество простых веб-страниц, написанных на разных JS-фреймворках (jQuery, React, Vue и т.д.). Большая нагрузка на JavaScript-движок (нет сложной композиции слоев, как это бывает на сложных страницах, но JS надо распарсить и исполнить).
У меня тест все ядра нагружает. Если у вас нагружает одно, то при реальном серфинге браузер тоже преимущественно одно ядро нагружает?
Есть важный момент: современный Firefox для композиции использует GPU при наличии дров и соответствующей активации WebRender. Полагаю, что на ARM композиция осуществляетс не на GPU, а на процессоре (у меня на Odroid N2+ именно так и оффлоад композиции на GPU там только когда-нибудь будет).
Товарищ майор уже имеет весь трафик по закону яровой с СОРМами и ключи для дешифровки от наиболее чувствительных сервисов в РФ, поэтому делать закладки ему и не нужно особо. Ну а коли нужно будет, пришлют маски-шоу.
1) Не смущает, что на рисунке latency примерно 2/3 t? Причем что t=1сек - это сущий произвол и вообще-то t может быть 1 мс и вообще сколько угодно.
2) Я привел реальные измерения с помощью fio и в них latency больше в разы указанной формулы.
3) Вот еще рисунок в котором допустим два разных SSD с разной latency.
Можно, конечно, сказать, что IOPSы здесь неправильно нарисованы и надо все заштриховать, но когда вы все заштрихуете (упретесь в возможности контроллера, забив его длинной очередью), у вас скорее всего из-за неспособности больше операций прожевать latency начнет сильно расти, возможно экспоненциально. С огромной дисперсией. Причем рост начнется не по забиванию контроллера, а даже раньше, когда забьете очередью каналы в контроллере, кеши и какие-нибудь другие ресурсы, которые внутрях есть. Ну и на графики StorageReview выше посмотрите. Вы видите на них ту зависимость latency ~ 1/IOPS? Я вот не вижу.
WAL получается по-сути последовательной однопоточной записью и не COW ФС его должны тоже быстро писать. А вот случайная запись должна быть очень быстрой. Правда последовательное чтение может оказаться непоследовательным по понятным причинам. Поэтому здесь правильно бенчмарк провести и посмотреть лучше COW ZFS под базу или хуже под различные нагрузки. Ну или может уже кто-то такие провел.
А вот со снапшотами на локальной ZFS я бенчмарк проводил на Proxmox и влияния снапшота не увидел на производительность.
А можете уточнить объем дисков (чтобы их ТТХ посмотреть) и что за модель контроллера была.
Пока из того, что я вижу: 1) у ZFS на 4k медленная запись. 2) при подключении по NFS разницы между NVMe и SATA не очень видно (сопутствующие расходы на сеть и реализацию NFS дороже). 3) разница между 10G и 100G при работе по NFS не слишком заметна.
Также при тестах из ВМ есть риск, что чтение будет из ОЗУ хоста.
Здесь совет такой, что отдельно измерить скорость чтения и записи и сравнить. Если скорости отличаются в 10 раз и скорость чтения близка к скорости чтения ОЗУ, очевидно чтение из ОЗУ и происходит.
Ну собственно creker правильно написал: корпоративные хранилки могут гарантировать запись кеша при обесточивании, поэтому хранилки могут не скидывать все из кеша на диск и сразу отвечать на fsync что типа записали.
В некоторых SSD есть аккумуляторы из конденсаторов, такие точно также могут работать.
По поводу производительности, было дело, наобещал заказчику, что будет 98 баллов, открываем, измеряем и тут оказывается, что оно в районе 73 и в желтой зоне.
Тут-то я и узнал, что производительность не нормализуется и измеряется в браузере на конкретном железе и если у тебя 98 баллов, это не значит, что у всех 98 баллов.
Пример сайта цифровой библиотеки на Nuxt.js 2 на двух разных ПК.
Соответственно, надо не только мерить Lighthouse, но и смотреть на измеренные показатели по пользователям конкретного сервиса.
Догадывались.
Но "деньги не пахнут".
@JerleShannara раз пошла история про бенчмарки, а есть возмжоность еще через GeekBench прогнать и ссылку на результаты опубликовать?
Вот бинарник: https://cdn.geekbench.com/Geekbench-5.4.0-LinuxARMPreview.tar.gz
Похоже 8-ядерный Байкал там уже есть, но всегда лучше 2 измерения, чем одно.
И даже есть 48-ядерный.
Я погуглил и ничего такого не нашел, что бы можно было в браузере открыть и оно бы типичные (самые популярные) сайты протестило с нагрузкой и по JS и по DOM и какие-то баллы написало.
Вроде припоминаю, что некоторе бенчмарки компьютеров такое внутри себя тестируют, но видимо встроенным движком и просто так в браузере это все не узнать.
Оно печально, что бенчи в основном на JS сосредоточены или webgl, но уж как есть.
Не вопрос, предложите другой, который бенчить будет не только JS, но и DOM, причем так, чтобы нагрузка отражала типичное использование браузера.
Надо только учитывать, что без аппаратной поддержки GPU бенчи webgl и т.п. могут совсем грустные результаты выдавать.
Один из аргументов за этот тест: многие веб-страницы сейчас по 1МБ JS-кода в минифицированном виде содержат, поэтому производительнось JS-движка важна. Но согласен, реальные страницы содержать гораздо более сложный DOM чем в Speedometer2.0.
З.Ы. Odroid N2+ (4 Cortex A73 2.4 ГГц + 2 Cortex A53) FF96 - 20 баллов, Chromium95 - 30 баллов.
Покликал на Odroid N2+ разные сайты и некоторые (где страницы большие) загружают в 100% по htop все ядра, а некоторые не могут и одно ядро (опять же по htop) загрузить.
Ну дак нет отличий с моим скриншотом. Да, процессор в полку не грузится, но и не так, что загружено только одно ядро. Что, в общем, говорит о том, что в процессор тест не упирается.
Напомню на всякий случай, что JavaScript однопоточный движок и больше ядер он будет грузить если воркеры создавать, которые в простейшем todo-list очевидно не нужны. Но браузеры не одно ядро грузят, так как на скачивание у них отдельные потоки порождаются, композиция и рендеринг тоже могут быть по потокам разнесены и выполняться как на GPU, так и на CPU с естественно разной нагрузкой на ядра.
Что касается 1000 комментов - да, у меня тоже в потолок нагрузка при этом, но это другой тест. 1000 комментов - это большой DOM и нагрузка идет на работу с DOM. В данном тесте DOM маленький и можно считать, что нагружается в первую очередь JS-движок.
Создается впечатление, что взяли монитор, оторвали заднюю крышку и на клей приклеили плату с пластиковым чехлом. Ну в принципе и ладно, специализированных под моноблок плат все равно нет, пусть будет так.
А вот что подключение монитора к плате идет "снаружи" - да это же гениально! Выдергиваешь Байкал, подключаешь Windows и нормально работаешь. А будет проверка - перетыкаешь кабель и готово.
З.Ы. дарю производителю идею: сделать моноблок 2in1: разместить в одном моноблоке две платы, одну на Байкале и одну с виндой на x86 и переключаться одной кнопкой -)
Если офисный пакет на смартфоне среднего уровня 2016-2018 гг. переварит, то и этот переварит.
Этот тест прогоняет множество простых веб-страниц, написанных на разных JS-фреймворках (jQuery, React, Vue и т.д.). Большая нагрузка на JavaScript-движок (нет сложной композиции слоев, как это бывает на сложных страницах, но JS надо распарсить и исполнить).
У меня тест все ядра нагружает. Если у вас нагружает одно, то при реальном серфинге браузер тоже преимущественно одно ядро нагружает?
Есть важный момент: современный Firefox для композиции использует GPU при наличии дров и соответствующей активации WebRender. Полагаю, что на ARM композиция осуществляетс не на GPU, а на процессоре (у меня на Odroid N2+ именно так и оффлоад композиции на GPU там только когда-нибудь будет).
Для сравнения Google Pixel XL, Snapdragon 821 c процессором 2016 года (4 ядра а-ля Cortex A57 с частотой 2.4) в FF 96 дает 14 баллов.
Chrome на этом же процессоре 21 балл.
При такой производительности оно не сильно быстро работать будет. Ну с другой стороны чуда же не могло произойти?
Товарищ майор уже имеет весь трафик по закону яровой с СОРМами и ключи для дешифровки от наиболее чувствительных сервисов в РФ, поэтому делать закладки ему и не нужно особо. Ну а коли нужно будет, пришлют маски-шоу.
Раз это офисный ПК, наверное чаще всего на нем будет запущен браузер.
В связи с этим можно на нем https://browserbench.org/Speedometer2.0/ запустить и поделиться результатами?
Интересует как Firefox, так и Chromium, если последний удастся завести.
С записью логов можно, но позже.
1) Не смущает, что на рисунке latency примерно 2/3 t? Причем что t=1сек - это сущий произвол и вообще-то t может быть 1 мс и вообще сколько угодно.
2) Я привел реальные измерения с помощью fio и в них latency больше в разы указанной формулы.
3) Вот еще рисунок в котором допустим два разных SSD с разной latency.
Можно, конечно, сказать, что IOPSы здесь неправильно нарисованы и надо все заштриховать, но когда вы все заштрихуете (упретесь в возможности контроллера, забив его длинной очередью), у вас скорее всего из-за неспособности больше операций прожевать latency начнет сильно расти, возможно экспоненциально. С огромной дисперсией. Причем рост начнется не по забиванию контроллера, а даже раньше, когда забьете очередью каналы в контроллере, кеши и какие-нибудь другие ресурсы, которые внутрях есть.
Ну и на графики StorageReview выше посмотрите. Вы видите на них ту зависимость latency ~ 1/IOPS? Я вот не вижу.
Поэтому вот, надо измерять.
WAL получается по-сути последовательной однопоточной записью и не COW ФС его должны тоже быстро писать. А вот случайная запись должна быть очень быстрой. Правда последовательное чтение может оказаться непоследовательным по понятным причинам. Поэтому здесь правильно бенчмарк провести и посмотреть лучше COW ZFS под базу или хуже под различные нагрузки. Ну или может уже кто-то такие провел.
А вот со снапшотами на локальной ZFS я бенчмарк проводил на Proxmox и влияния снапшота не увидел на производительность.
На графиках ZFS local чтение наверняка из ОЗУ идет.
А можете уточнить объем дисков (чтобы их ТТХ посмотреть) и что за модель контроллера была.
Пока из того, что я вижу:
1) у ZFS на 4k медленная запись.
2) при подключении по NFS разницы между NVMe и SATA не очень видно (сопутствующие расходы на сеть и реализацию NFS дороже).
3) разница между 10G и 100G при работе по NFS не слишком заметна.
Также при тестах из ВМ есть риск, что чтение будет из ОЗУ хоста.
Здесь совет такой, что отдельно измерить скорость чтения и записи и сравнить. Если скорости отличаются в 10 раз и скорость чтения близка к скорости чтения ОЗУ, очевидно чтение из ОЗУ и происходит.
Это можно и наглядно показать, что просто так задержку не стоит из IOPS вычислять.