Никто не встречал?

1) Кто что думает по поводу идеи попытаться написать JNI обертку над

https://software.intel.com/en-us/articles/igzip-a-high-performance-deflate-compressor-with-optimizations-for-genomic-data

правда, что там с copyright мне не очень понятно.

2) Или над

https://software.intel.com/en-us/node/503447

Будет ли выигрыш для Oracle VM или там и так уже оптимизированный IPP-библиотека лицензирована ? Кто что знает ?

Явно в продакшене на GZIP приходится > 50% времени

Есть подозрение, что из остальных 50% еще процентов 10-15% приходится на тупое DecimalFormat для преобразования double в Json

И, соответственно, только 30-40% времени тратится собственно на бизнес задачи поиска в PostgreSQL, обработки данных и так далее ))))

В общем, если Intel Performance Primitives из коробки в Oracle JVM не входит - задача крайне осмысленная. Даже пары месяцев IMHO не жалко. Вопрос, как проверить, что сейчас используется в Oracle JVM ))) С одной стороны, Oracle вроде код из IPP уже давно использует (например компрессия/декомпрессия Jpeg), с другой стороны, конкретно по Gzip на это не очень похоже

Ну и еще вопрос по Gzip.

GzipOutputStream не поддерживает выбора степени сжатия, как Deflate ( BEST_COMPRESSION, BEST_SPEED, DEFAULT )

Почему так (((

Это связано со стандартами или историческая не доработка ? Вроде, везде пишут, что Gzip и Deflate фактически одно и то же, отличающиеся заголовками. Можно ли BEST_SPEED поток от Deflate завернуть в Gzip. Будет ли это корректно ?

Basil A. Sidorov...то ловля блох потеряет смысл.

желание ловить блох, появляется от того, что из-за них чесаться хочется ))) Возможно выяснится, что дело не в блохах, а в каких нибудь других, мало приятных существах, пусть даже и более крупного размера ))). Но не ловить блох, это не повод imho, особенно если в логе я вижу строчки:

выборка из БД и обработка - 70 ms, кодирование (в Json) и компрессия - 300 ms (((

ну и performance, вроде, достаточно критичен (его не хватает)

Предложения отказаться от gzip уже звучали, но есть опасение, что "цена" трафика и ресурсов сетевой карты, значительно дороже цены процессоров

Basil A. SidorovДизайн дебильный: Deflater - защищённое поле класса, от которого наследуется GZIPOutputStream , поэтому надо унаследоваться ещё раз и грязными ручонками всунуть настроенный нужным образом Deflater. "Как-то так".

P.S. Если задача всё та же, то паковать десятки байт - бессмысленное и вредное занятие.
Могу даже объяснить почему, хотя это и так должно быть очевидно.
Спасибо. Я так и подозревал.

Тем не десятки байт, а скажем десяток мегабайт ))) для наиболее плохого случая (не типовой, но вполне может прилететь от коллег). Средний размер в продакшене не знаю, подозреваю в районе 20 Kb - 200 Kb это типовые запросы.

Задача та же (перейти на nio), но сервис другой.

p.s.
А вообще идея хорошая, смотреть результирующий размер и делать компрессию только для пакетов больше нескольких Kb.
p.p.s.
Завтра поинтересуюсь, есть ли статистика по размеру пакетов на реальном проде.

scfЕсли что-то своё, то можно поискать другие компрессоры, менее требовательные к цпу.
Другие компрессоры отпадают, т.к. тут полный зоопарк софта Erlang, Go, Java и т.д.

Варианта два. Или отключить нафиг, если трафик в пределах площадки ходит или мучать Gzip, если он действительно через сеть гуляет. Вообще, подозреваю, что проблема более архитектурная и админская. IMHO Просто никто об этом не думал, а в ТЗ прописано, что encoding gzip ))))

scfА что именно вы гзипуете? Если HTTP, то лучше завернуть траффик через nginx, он точно справится лучше.
Перед клиентом и так прокси стоит, смысл паковать тогда действительно теряется. Если сервер и клиент на одной площадки. Но это нужно у админов выяснять. И как это скажется на загруженность роутеров/свитчей.

Basil A. SidorovДополнительно: оптимальный коэффициент сжатия - восьмёрка. Почти не проигрывает максимальному (может даже выиграть), но работает заметно быстрее на плохо сжимаемых данных.
У нас сейчас вроде 7.

Basil A. SidorovТеоретически, можно делать "покусочную" паковку, но это не только геморрой, но ещё и требует поддержки со стороны клиента.

Что такое "покусочная паковка" ?
Ты имеешь в виду просто упаковывать в нескольких потоках ?

======

Нашел проект:

https://github.com/nh13/pbgzip

Утилита командной строки, где можно включить igzip и IPP.

igzip у меня на компьютере не взлетел ((( IPP еще не смотрел

Intel - уроды.

Года два назад скачивал Intel VTune - на сайте была полностью неработоспособная версия, в support'е страничках было написано "известная бага, ищите старую версию, но с сайта мы ее уже удалили", как-то так )))

Сейчас скачал Intel IPP инсталятор. Б@#$ 1.2 Гигабайта !!!! Просто библиотека!!! Ну ладно... запустил: 1) при наличие интернет, инсталятор сказал интернета нет, ключ лицензии проверить не могу 2) привязка идет к сетевой карте eth0, б#$% у меня на Ubuntu совершенно другое именование карт, т.ч. даже как сделать файл для offline регистрации не понятно 3) ну и самое главное!!! Он умудрился сломать Mozilla Firefox!!! Linux, мать его!!! Как они в Intel так сумели? Профессионализм не пропьешь.

Basil A. SidorovЯ использовал такую эвристику:
Спасибо. Сам примерно над таким и думал, но немного по другой причине.

На длинных запросов нужно отдавать в режиме стриминга в realtime, т.к. иначе клиент может не дождаться и отвалится по таймауту (клиент например curl). Пришлось написать свой producer, т.к. стандартного имитирующего Input/OutputStream в Apache NIO Core вроде нет
(или плохо смотрел).

Но там есть проблема, когда его создавать. Т.к. если создавать при начале вывода, то с большой вероятностью данных еще не будет и сразу же встанем на IOControl.suspendOutput, что вроде не есть хорошо (лишний вызов suspend/requestOutput). Т.ч. желание выполнять "отложенное" создание producer'а уже есть ))) Т.ч. вполне можно дополнить его Вашей "эвристикой".

p.s. Для producer'а использовал "single producer single consumer" очередь из JCTools + класс/деглюкатор который по таймеру дергает IOControl.requestOutput

Нашел старый thread, человек предлагал делать возможность выбора в Java библиотеки: встроенной в OpenJDK и системной.


Поставил IPP, пытаюсь понять, где же zlib или примеры. Нету их! Уроды.

Пишут:

ZLIB and Intel® IPP Implementation

The distribution model of Intel® IPP for ZLIB is as follows:

Intel® IPP library package provides files for source code patching for all ZLIB major versions – from 1.2.5.3 to 1.2.8. This patches should be applied to ZLIB source code files downloaded from ZLIB repositories at zlib.net (latest ZLIB version), or zlib.net/fossils for previous versions of ZLIB...

Но где брать данные патчи и как патчить - не понятно.


The process of preparation of Intel® IPP boosted Zlib library is described in readme.html file provided with Intel® IPP “components” package. It is explained how to download Zlib source code files from its site, how to un-archive, patch source code files and how to build Intel® IPP-enabled Zlib for different needs (static or dynamic Zlib libraries, statically or dynamically linked to Intel® IPP).

Что это за "componets" package и почему его нет в более чем ГИГАбайтном исталяторе, пока не понятно (((

В доке пути, где должны быть примеры - у меня даже таких путей не создалось (((

Оказывается не только Intel изгаляется ))) Еще и coudflare, при этом даже, по результатам местами круче Intel'а )))

https://www.snellman.net/blog/archive/2014-08-04-comparison-of-intel-and-cloudflare-zlib-patches.html

У меня на компьютере (стандартные настройки компрессии) стандартный системный gzip vs minigzip из zlib_ng :

lib-ng $ time ./minigzip ../../res1

real 0m5.476s
user 0m5.396s
sys 0m0.068s

lkudryavcev@e74nix ~/IdeaProjects/zlib-ng $ time ./minigzip64 ../../res1

real 0m5.493s
user 0m5.428s
sys 0m0.060s

$ time gzip ../../res2

real 0m7.266s
user 0m7.164s
sys 0m0.096s

Файлы одинаковые. JSON с цифрами размером в 86 Mb ужался в 19 Mb. Размер после сжатия примерно одинаковый (разница в 200 K). 7.25 сек vs 5.5 сек.

Basil A. SidorovLeonid KudryavtsevJSON с цифрами размером в 86 Mb ужался в 19 Mb. Размер после сжатия примерно одинаковый (разница в 200 K). 7.25 сек vs 5.5 сек.
16 / 8 ~= 15 МБит/сек (оценка снизу).

Вы реально думаете, что сжатие в потоке сильно затормозит ваших клиентов?
Проблема не с клиентами, сколько с сервером. Когда от коллег приходит пачка больших запросов и все может умереть.

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

Сергей АрсеньевА не сжимать не пробовали? :)

Вопрос обсуждался, мне аргументированно объяснили, почему от варианта "не сжимать" отказались.
В штатном режиме все ходит в рамках одного кластера/площадки, но:
1) перенос сжатия на прокси / балансировщик - увеличит загрузку прокси, а прокся более критична, чем наш сервис (к тому же наш сервер проще масштабировать добавлением узлов).
2) при авариях / сбоях, трафик автоматически перенаправляется на другую площадку - пойдет через И-нет, а это уже живые деньги. При этом, при авариях, он может пройти "мимо" прокси, т.е. сжимать будет некому.
В общем - все сложно )))

Subj не такая уж большая проблема, занимаюсь в фоновом режиме. Просто вопрос самому интересен ))) даже чисто теоретически.

Честно говоря, от Intel IPP я ожидал большего выигрыша, сталкивался с ним, когда обрабатывал изображения, там разница стандартный jpeg декомпрессор vs IIP jpeg декомпрессор была в десятки раз.

Ну и софт у Intel совсем в бардак превратился. Инсталятор кривой, дока не соответствует тому, что поставил инсталятор и так далее. На сайте ничего "в разнобой" не найдешь и не скачаешь. Сайт сделали "для домохозяек" - одна реклама и глупые FAQ. Что либо найти осмысленное просто не реально.... В общем, прогресс за последние 15 лет налицо ((( IMHO