to post messages and comments.

Давай уже, username, доставай свою флэшечку — будемь меряться

-----------------------------------------------------------------------
CrystalDiskMark 5.2.1 x64 (C) 2007-2017 hiyohiyo
Crystal Dew World : crystalmark.info
-----------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

Sequential Read (Q= 32,T= 1) : 4631.226 MB/s
Sequential Write (Q= 32,T= 1) : 9133.748 MB/s
Random Read 4KiB (Q= 32,T= 1) : 239.655 MB/s [ 58509.5 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 236.796 MB/s [ 57811.5 IOPS]
Sequential Read (T= 1) : 5240.586 MB/s
Sequential Write (T= 1) : 8393.448 MB/s
Random Read 4KiB (Q= 1,T= 1) : 246.145 MB/s [ 60094.0 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 237.814 MB/s [ 58060.1 IOPS]

Test : 1024 MiB [G: 0.0% (0.0/8180.0 MiB)] (x5) [Interval=5 sec]
Date : 2017/03/30 12:17:39
OS : Windows 7 Ultimate SP1 [6.1 Build 7601] (x64)

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

Решил я побаловаться с большими объемами данных в sbcl. Взял лог, откусил от него 1 250 000 строк и попарсил их.

Парсер cl-ppcre
Код читает файл, выкуривает оттуда дату/время, процесс, пид, хост и сообщение, записывает в один массив хосты (он у меня один) в один — название процесса ( у меня вышло около 25), в один массив дату, сообщение, индекс хоста, индекс процесса, pid. Потом все это пишется в лиспофайл (with-standard-io-syntax).

Итоги:
размер лога — 158602612 (1250000 записей)
размер итогово лиспофайла — 219861450
Время парсинга — 45 секунд.
Время записи лиспофайла — 45 секунд.
Потребление памяти (RES) — ~1050 mb.

Потом этот файл загружается в sbcl:
Время загрузки — около 55 секунд,
Время сортировки по сообщениям:
(sort a #'string< :key #'(lambda (record) (getf record :message))) — 22 секунды.
Время сортировки по процессу (типа int foreign key): — около 1 секунды.
Время фильтрации: мгновенно (явно меньше секунды).

Железо — core 2 duo t7250 2gHz. Иксы и всякая хрень запущена, единственное что не давал свопить, закрывая всякие браузеры (рамы мало, всего 2gb).
Gentoo amd64-3.2.12.

Теперь вопрос — как бы побороть ограничение в лице памяти? Есть ли какие-то подобные штуки со сбросом данных на диск? Есть интересные статьи о подобных вещах?

В тред кастуются @archimag и @lovesan.

Что никогда не понимал и не пойму — почему и зачем делают 10 замеров, и считают СРЕДНЕЕ при выполнении статического теста?!
Ладно если на входе рандомные данные, там понятно.
Но если на входе константа, выход константа, и вы хотите избавиться от разброса случайых помех от левых приложений в системе...
!!! НАДО ВЫЧИСЛЯТЬ МИНИМУМ !!!

Все-таки думаю провести scalability бенчмарки FreeBSD, NetBSD, DragonflyBSD, Linux 2.6 (может даже 2.4)

Что еще потестить?

Тесты буду делать на web-serverе gatling ( fefe.de ):

* socket
* bind
* fork
* mmap
* touch after mmap
* http request latency

Какие тесты еще могут быть интересны?

Содержание тестов описано тут:
bulk.fefe.de

Маленький бенчмарк и его результаты:
lisp:
(defun simple(max)
  "Search for simple numbers up to max"
  (setq current-numbers (list 2))
  (do ((num 3 (incf num 2)))
    ((> num max))
    (setf found T)
    (dolist (prev current-numbers)
      (if (= 0 (mod num prev)) (PROGN (setf found NIL) (return)))
      (if (> prev (/ num 2)) (return)))
    (if found (PROGN (nconc current-numbers (list num)) 
                     (print num)))
    )
  )


(simple 100000)

python:
numbers = [2]
maxNum = 100000
new = 1

for i in xrange(3,maxNum):
    for j in numbers:
        if j>i/2:
            break
        if i%j == 0:
            new = 0
            break
    if new == 1:
        print i
        numbers.append(i)
    new = 1

print "\nTotal numbers: ",len(numbers)

*Итоги*:

*clisp:*
real	1m28.242s
user	1m27.110s
sys	0m1.266s

*sbcl:*
real	0m6.794s
user	0m6.615s
sys	0m0.114s

*python:*
real	0m10.486s
user	0m10.446s
sys	0m0.017s

за лиспокод не пинать - поиск простых чисел это мой hello world за последние 15 лет.

написал парсер логов на golang, всё в одном треде, просто читается лог, композятся структурки, периодически обсчитываются, сбрасываются в мусор, результат обсчитывания выводится на stdout. скомпилил стандартным компилятором (6g) и gccgo. бинарник, скомпиленный gccgo работает примерно в 4 раза медленнее. такие дела.

сравнил бтр со сжатием и рейзер3 на пустых разделах по 10Г.
копирование исходников ядра извне:
reiser — 2:33
btrfs — 2:44
сборка ядра:
reiser — 8:52
btrfs — 9:05
занятое место после сборки:
reiser — 641М
btrfs — 270М

правда, тут есть некоторое жульничество: исходники ядра ведь чудесно сжимаются, потому и такая разница в занятом месте.

замеры за 5 дней, средние значения за сутки: 650 строк полезного кода, 9 чайных ложек растворимого кофе, 16 сигарет, 400 грамм еды мужской, 2 абаки (по 20-25 мин партия), 3 паззла (по 25-30 мин), 9 постов (зависит от кофе? :)), 250 новостей прочитано (рсс), 5.5 писем прочитано/отвечено