Рубрика «benchmark» - 2

в 10:00, , рубрики: benchmark, kernel, linux, postgresql, Настройка Linux

Сравнительное тестирование работы PostgreSQL с большими страницами Linux - 1 Ядро Linux предоставляет широкий спектр параметров конфигурации, которые могут повлиять на производительность. Это все о получении правильной конфигурации для вашего приложения и рабочей нагрузки. Как и любая другая база данных, PostgreSQL использует ядро ​​Linux для оптимальной конфигурации. Плохо настроенные параметры могут привести к снижению производительности. Поэтому важно, чтобы вы измеряли производительность базы данных после каждого сеанса настройки, чтобы избежать снижения производительности. В одной из моих предыдущих публикаций, «Настройка параметров ядра Linux для оптимизации PostgreSQL», я описал некоторые наиболее полезные параметры ядра Linux и то, как они могут помочь вам повысить производительность базы данных. Теперь я собираюсь поделиться своими результатами тестов после настройки больших страниц Linux с другой рабочей нагрузкой PostgreSQL. Я выполнил исчерпывающий набор тестов для разных размеров загрузки PostgreSQL и одновременного количества клиентов.

Машина для тестирования

  • Supermicro server:
    • Intel® Xeon® CPU E5-2683 v3 @ 2.00GHz
    • 2 sockets / 28 cores / 56 threads
    • Memory: 256GB of RAM
    • Storage: SAMSUNG SM863 1.9TB Enterprise SSD
    • Filesystem: ext4/xfs
  • OS: Ubuntu 16.04.4, kernel 4.13.0-36-generic
  • PostgreSQL: version 11

Читать полностью »

в 11:16, , рубрики: benchmark, highload, postgresql, перевод с английского

Данная статья является переводом оригинальной статьи Martin Kováčik «PostgreSQL benchmark on FreeBSD, CentOS, Ubuntu Debian and openSUSE» https://redbyte.eu/en/blog/postgresql-benchmark-freebsd-centos-ubuntu-debian-opensuse/ В ней рассматриваются тесты СУБД PostgreSQL 10.1 в приближенных к реальным условиям средах на различных unix-системах

Перевод

В этом посте я собираюсь показать результаты тестов недавно выпущенного PostgreSQL 10.1. Я проверил БД на этих ОС (все 64-битные):

  • Ubuntu 16.04, ядро 4.10.0-38-generic
  • openSUSE 42.3, ядро 4.4.87-25-default
  • CentOS 7.4, ядро 3.10.0-693.2.2.el7.x86_64
  • Debian 9.2, ядро 4.9.0-4-amd64
  • FreeBSD 11.1

Читать полностью »

в 14:12, , рубрики: benchmark, devops, Istio, linkerd, service mesh, Блог компании Southbridge, Серверное администрирование, системное администрирование

Бенчмарк потребления ЦП для Istio и Linkerd - 1

Введение

Мы в Shopify занялись развертыванием Istio в качестве service mesh. В принципе все устраивает, кроме одной вещи: это дорого.

В опубликованных бенчмарках для Istio говорится:

С Istio 1.1 прокси потребляет примерно 0,6 vCPU (виртуальных ядер) на 1000 запросов в секунду.

Для первого региона в service mesh (по 2 прокси с каждой стороны соединения) у нас будет 1200 ядер только для прокси, из расчета один миллион запросов в секунду. Согласно калькулятору стоимости от Google получается примерно $40/месяц/ядро для конфигурации n1-standard-64, то есть один этот регион будет стоить нам больше 50 тыс. долларов в месяц за 1 млн запросов в секунду.

Айвен Сим (Ivan Sim) наглядно сравнил задержки service mesh в прошлом году и обещал то же самое для памяти и процессора, но не получилось:

Судя по всему, values-istio-test.yaml серьезно увеличит запросы к процессору. Если я все правильно посчитал, нужно примерно 24 процессорных ядра для панели управления и 0,5 ЦП для каждого прокси. У меня столько нету. Я повторю тесты, когда мне выделят больше ресурсов.

Я хотел сам убедиться, насколько показатели Istio схожи с другой service mesh с открытым кодом: Linkerd.

Читать полностью »

в 7:01, , рубрики: .net, assembly, benchmark, C#, высокая производительность, индексатор, производительность

Доброго времени суток. В данной статье я предлагаю ознакомиться с индексаторами в различных типах. Посмотрим код языка ассемблера для данных индексаторов и характеристики каждой инструкций по ее скорости. Также я предложу несколько очевидных выводов. Но что именно использовать в конкретно вашей ситуации решать вам — стоит ли жертвовать удобством ради скорости или наоборот.

image

Читать полностью »

в 10:34, , рубрики: benchmark, CNI, devops, kubernetes, networking, Блог компании Southbridge, Серверное администрирование, системное администрирование

Результаты бенчмарка сетевых плагинов Kubernetes (CNI) по сети 10 Гбит-с (обновлено: апрель 2019) - 1

Это обновление моего предыдущего бенчмарка, который теперь работает на Kubernetes 1.14 с актуальной версией CNI на апрель 2019 года.

Во-первых, хочу поблагодарить команду Cilium: ребята помогли мне проверить и исправить скрипты мониторинга метрик.

Что изменилось с ноября 2018

Вот что изменилось с тех пор (если интересно):

Flannel остается самым быстрым и простым интерфейсом CNI, но все еще не поддерживает сетевые политики и шифрование.

Romana больше не поддерживается, так что мы удалили ее из бенчмарка.

WeaveNet теперь поддерживает сетевые политики для Ingress и Egress! Но производительность снизилась.

В Calico все еще нужно вручную настраивать максимальный размер пакета (MTU) для лучшей производительности. Calico предлагает два варианта установки CNI, так что можно обойтись без отдельного хранилища ETCD:

Читать полностью »

в 10:51, , рубрики: benchmark, Go, tutorial

Билл Кеннеди в одной из лекций своего замечательного курса Ultimate Go programming сказал:

Многие разработчики стремятся оптимизировать свой код. Они берут строчку и переписывают ее, говоря, что так станет быстрее. Нужно остановиться. Говорить, что тот или иной код быстрее, можно только после того, как он отпрофилирован и сделаны бенчмарки. Гадание не является правильным подходом к написанию кода.

Мне давно хотелось на практическом примере продемонстрировать, как это может работать. И на днях мое внимание привлек следующий код, который как раз можно было бы использовать в качестве такого примера:
Читать полностью »

в 23:19, , рубрики: arbitrary-precision, benchmark, double-double, float expansion, javascript, Алгоритмы, Видеокарты, высокая производительность

В процессе реализации одной «считалки» возникла проблема с повышенной точностью вычислений. Расчетный алгоритм работал быстро на стандартных числах с плавающей запятой, но когда подключались библиотеки для точных вычислений, все начинало дико тормозить. В этой статье будут рассмотрены алгоритмы расширения чисел с плавающей запятой с помощью мультикомпонентного подхода, благодаря которому удалось достичь ускорения, так как float арифметика реализована на кристалле цп. Данный подход будет полезен для более точного вычисления численной производной, обращение матриц, обрезке полигонов или других геометрических задач. Так возможна эмуляции 64bit float на видеокартах, которые их не поддерживают.

double.js benchmark

Читать полностью »

в 19:04, , рубрики: benchmark, Go

В Go нет синтаксиса для определения необязательных аргументов в функциях, поэтому приходится использовать обходные пути. Я знаю 2:

  1. Передавать структуру, содержащую все необязательные аргументы в полях: 
    funcStructOpts(Opts{p1: 1, p2: 2, p8: 8, p9: 9, p10: 10})

  2. Способ предложенный Робом Пайком с использованием функциональных аргументов: 
    funcWithOpts(WithP1(1), WithP2(2), WithP8(8), WithP9(9), WithP10(10))

Второй способ в принципе делает тоже самое, но с синтаксическим сахаром. Мне не давала покоя мысль, а сколько же стоит этот сахар, кому ещё интересно прошу под кат.
Читать полностью »

в 20:11, , рубрики: benchmark, Go, Rust, rust is faster than go, высокая производительность, Программирование, Тестирование веб-сервисов

С такой фразой мне кинули ссылку на статью компании Mail.Ru Group от 2015 «Как выбрать язык программирования?». Если кратко, они сравнили производительность Go, Rust, Scala и Node.js. За первое место боролись Go и Rust, но Go победил.

Как написал автор статьи gobwas (здесь и далее орфография сохранена):

Эти тесты показывают, как ведут себя голые серверы, без «прочих нюансов» которые зависят от рук программистов.

К моему большому сожалению, тесты не были эквивалентными, ошибка всего лишь в 1 строчке кода поставила под сомнение объективность и вывод статьи.
Читать полностью »

в 8:26, , рубрики: benchmark, gradle, immutable, java, jmh, kotlin, scala, Блог компании ИНФОРИОН, больше тегов богу тегов, графики, иммутабельность, коллекции

Бывает так, что когда человек начинает писать на Kotlin, Scala или %language_name%, он делает манипуляции с коллекциями так, как привык, как “удобно”, как “понятнее” или даже “как быстрее”. При этом, разумеется, используются циклы и изменяемые коллекции вместо функций высшего порядка (таких как filter, map, fold и др.) и неизменяемых коллекций.

Эта статья — попытка убедить ортодоксов, что использование “этой вашей функциональщины” не влияет существенно на производительность. В качестве примеров использованы куски кода на Java, Scala и Kotlin, а для измерения скорости был выбран фреймворк для микробенчмаркинга JMH.
Читать полностью »

123...5
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js