Чтобы добавлять сообщения и комментарии, .

@mismatch:
mismatch

youtu.be — полезно послушать, если вы пишите свой фронтэнд на react.js

@Balancer:
Balancer

Вчера писал, что интересно было бы посмотреть в «Объектом Фибоначчи» на Rust. Сегодня слепил такое вот: github.com Сильно не пинайте, это было написано через 15 минут после начала изучения языка (засекал). Я даже не знаю до сих пор, как дело в Rust со сборкой мусора и это эквивалент Java/C-хипового или C-стекового.

Получилось 0.603 сек., что почти вдвое хуже стекового Си (0.350) и немного лучше Java (0.685) со сборкой мусора.

Обновлённая таблица: github.com

@Balancer:
Balancer

Перевёл на пробу один тестовый контейнер на PHP7. На php-5.5.9 медианное время отклика типовой среднего веса динамической страницы было 75мс, минимальное — 65мс. На php-7.0.4 стало 59мс и 28мс, соответственно. Это в один поток.

В 5 потоков — с 173/73 мс до 65/37мс.

В общем, разница очень заметная :) Надо будет всё оттестировать и переводить боевые сервера...

@Balancer:
Balancer

Фигня какая-то. Делаю тут для изучения несложную задачку (взять html, подсунуть параметр из GET-запроса) на Golang. В результате, запросов в секунду:

* PHP (голый) — до 12000
* Golang/Revel — до 8700
* Golang/Gin-gonic — до 4800

Удивительно, во-первых, что Revel быстрее Gin'а, обычно считается наоборот. Но это ладно.

Вот каким макаром PHP получается быстрее — не понимаю. Т.е. цифра вообще какая-то нереальная в моём привычном мировоззрении... При чём не 7.0 какой-нибудь или hhvm, а обычный 5.4.45, fpm.

Может, фишка в том, что PHP используется классически, html-код со вставкой, который один раз компилируется и потом берётся из кеша, а golang-фреймворки так не умеют и производят чтение/парсинг на каждом запросе? Или вопрос в оптимизации многоядерности, т.к. у php-fpm уйма инстансов, грузящих все ядра, а у Revel/Gin собственный менеджер и фиг знает, как он там распределяет загрузку?

@mismatch:
mismatch

youtube.com Меньше — лучше. Ваши объекты, методы должны быть небольшими и соответствовать принципу единственной ответственности. Меньше абстракций, меньше ветвлений. Знайте структуры данных, которые вы используете. Только так можно добиться хорошей производительности вашего приложения.

@Balancer:
Balancer

Прошло почти два года — #2229209. Кеши давно устаканились, файловая система устарела... Сегодня понадобилось измерить объём каталогов. Один на «новом» (том, которому уже два года) разделе с reisrefs, другой — на старой ext4. Время подсчёта по du -h было примерно равное. При том, что под reiserfs 15Гб файлов, а под ext4 — 265Мб. Решил измерить точно, но, понятно, уже из кеша. Результат:
— reiserfs: 3.7 сек.
— ext4: 14.4 сек.

Опаньки... Решил подсчитать число файлов. time (sudo find . | wc -l)
— reiserfs: 194371 файл, 2.3 сек
— ext4: 36564 файла, 11.0 сек

@Balancer:
Balancer

Наткнулся на утилитку, которая измеряет average seek жёсткого диска, что является куда более важной составляющей производительности, чем привычно измеряемый через hdparm линейный трансфер. Увы, надо компилировать, но она крошечная :)

linuxinsight.com

На SSD домашнем не тестировал, сижу сейчас под виндой, на серверах скорость колеблется от 0.17 ms для виртуального диска DigitalOcean до 35мс на домашнем WD30EFRX под нагрузкой. SAS без нагрузки показывает 6мс, что хорошо согласуется с паспортными данными, разные SATA без нагрузки 12..13мс.

@erthad:
erthad

а напомните картинку/статью с графиками производительности, типа если работать 8 дней в неделю, то производительность очень быстро упадет

@mrtron:
mrtron

Пишу я тут вебсервис. он работает с базой данных. хранит там свои всякие шняжки. и у меня есть эээ... назовём их jobs_result. это приблизительно 2-3 тысячи очень простых записей для каждого джоба. типа таймстамп и пара значений. и эти данные активно читаются и пишутся. и джобов я планирую порядка 1000 в сутки. и того за сутки 2-3 миллиона таких записей. и хранить их стоит месяц. тоесть 60 миллионов записей. и вот я думаю: стоит ли их разделить по отдельным таблицам? типа job_result_$id или job_result_$day или обойтись просто добавлением в таблицу поля job_id и фильтровать по нему?
и как удалять старые записи тогда?
Профиль чтения-записи: на одну запись в среднем около 20 чтений. 99% записи идёт в джобы последних двух часов. 100% чтения в джобы последних двух часов. Чисто теоритически по этому старые результаты можно переность в архивную таблицу, но в текущей таблице будет множиться мусор от такого. А остановку базы на обслуживание и переупаковку лишний раз делать не хочется. Чисто теоретически можно попробовать постгресс, там есть vacuum.
Может попрбовать nosql, какой-нить, но их стопицот видов а мне не очень хочется разбираться.

@nox:
nox

А мы вчера решили замерить производительность 3 языков программирования.

Задача была такая:

Есть массив из 1 000 000 объектов.
Надо посчитать сколько объектов имеют свойство X > 50
Тупо линейно пробежаться по массиву и посчитать.

Результаты:

С++ — 7мс
C# — 8мс
Node — 9мс

То есть Node даже на порядок не отличается по скоросте от C++ и С#.

@klapaucius:
klapaucius

leafpetersen.com

@Balancer:
Balancer

В продолжение недавней темы #2225516

Первые практические оценки. Загрузка системы, процессор и io за неделю:
balancer.ru
Вертикальный раздел — перезагрузка (я сперва надеялся избавиться от kworker обновлением ядра). Потом перенос данных на новый раздел, потом заполнение кеша — следующие два дня. И, вот, сегодня день после «выхода на режим». В принципе, не так наглядно, как на соответствующем по времени графике времени генерации файлов самого munin:
balancer.ru
Хорошо видно, как было, как начал заполняться кеш, снижая нагрузку, как стало. А особенно контрастно на нагрузке за месяц:
balancer.ru

Хотя, повторюсь, не знаю, насколько именно reisrefs характерна, может быть вынос на новый раздел со свежей ext4 себя также бы повёл. По тестам, «приближённым к боевым» (многопоточность, фрагментация), ext4 у меня была заметно быстрее reisrefs. Но практика может быть иной. Не исключено, что ext4 подвержена со временем деградации, как и reiser4 (та тоже поначалу очень быстрая, а через пол-года активной работы на десктопе превратилась в ад). Вот про именно reiserfs — она, вроде, не деградирует. Старый сервер на ней проработал в жёстком режиме лет шесть и проблемы затыкания системы на дисковой активности у меня не вылезали.

Если же без картинок, то форумы перестали тормозить и при первом входе в каталог с кешем mc не вешается на десяток секунд, вход в любой момент мгновенный.

@Balancer:
Balancer

А неплохой web-сервер для разработки засунули в PHP 5.4. Сейчас прогнал ab, 500 запросов в 20 потоков на Q6600, вышло 611 запросов (phpinfo) в секунду для встроенного сервера при медианном времени отдачи 32мс, а lighttpd+fastcgi на этой же машине — 1521 запрос в секунду при медианном времени 13 мс. Максимальное время — 39мс и 30мс, соответственно. Статика отдаётся 11700 простых файлов в секунду для встроенного в PHP и 15400 в секунду для lighttpd.

@Balancer:
Balancer

Нифига себе, сейчас перекопировал около 6Гб толстых файлов с одного компа на другой по NFS на пиковой скорости 73Мбайт/с. Я как-то привык к скоростям 30-40Мбайт/с.

@kamenev:
kamenev

Внутри виртуальной машины производительность диска составила 57% от производительности диста у хост-системы.
А именно 127 мб/с против 222.5 мб/с у хост-системы. При этом вполне возможно, что считывание данных в виртуальной машине производилось с неразмещённых секторов, так как образ составляет 25 Гб при его номинальной вместимости 200 гб, что очевидно, может существенно завышать результат.

@Revertron:
Revertron

Народ, а давайте примерную сводку сделаем, у каких моделей с какими прошивками какой результат Quadrant Standart, например?

У меня на Acer Liquid с CyanogenMod7 на базе 2.3.4 — 1114 очков (на третьем запуске, разгоняем JIT)

@Balancer:
Balancer

Когда-то у меня для просмотра неконвертированных DVD Rip'ов хватало Loox'а C550 и TCPMP. 520МГц, 64Мб памяти, 640x480 экран. Хватало с заметным запасом. Встроенный бенчмарк в TCPMP показывал 120-140%, то есть от 20 до 40% запаса по производительности, в зависимости от типа RIP'а. Даже до 150%, порой. Поэтому я как-то даже не задумывался об этом вопросе в отношении нового коммуникатора с 1000МГц процессором нового поколения, 768Мб оперативки и всё такое. Даже подозревал, что смогу неконвертированные 720p смотреть, экстраполяция по производительности позволяла надеяться. А вчера — грубая реальность. Рипы «The IT Crowd» от LostFilm. 640x352. Их мой старенький P3470 с его 198МГц(!) на пределе и неровно, но тянет (90% бенчмарк). Два из трёх опробованных проигрывателей на Андроиде (vPlayer и RockPlayer) показывали его... С тормозами, рассинхронизацией, артефактами быстрой распаковки. Только QQPlayer справился. Боже. 198МГц и TCPMP под WM показывает лучше, чем 1000МГц и популярные(!) плееры на Андроиде. Какой уж тут 720p...

@PoZitron:
PoZitron

Кто точно знает, два SATA-винта, работают быстрее чем один или медленнее?
У меня есть два физических жёстких диска, на первом стоит система, второй /home. Первый медленнее второго. Я вот думаю отцепить первый диск, поставить его на сервер, и остаться только с одним. Думаете будет прирост производительности? Или наоборот?

@vbooh:
vbooh

На Хабре mail.ru анонсировали видео с конференции Highload, но видео мерзкого качества и еще переводчик мешает слушать, короче так себе. Но вот слайды по поиску узких мест софта в linux от Joe Damato очень интересные:
timetobleed.com

@Balancer:
Balancer

Забавно (в продолжение к linux.org.ru ). nginx + php-fpm работает процентов на 5 медленнее, чем lighttpd + php-fastcgi. Но статику nginx отдаёт по-прежнему вдвое быстрее. Правда, на несложном конфиге с минимумом условий.

@PoZitron:
PoZitron

Кто-нибудь в состоянии воспроизвести это youtube.com видео в оригинальном разрешении? :)
Интересно узнать конфигурацию компьютера/ОС/софта, где это не тормозит.

@fm:
fm

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

@Kreol:
Kreol

Охренеть, RC1 Opera 10,51 выдал в тесте вот столько — service.futuremark.com Для сравнения предыдущий билд показывал столько — service.futuremark.com Еще раньше значения колебались от 4100 до 4200.