Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
Сообщение от opennews (??) on 13-Авг-17, 22:21
Вышла (https://github.com/leo-yuriev/ReOpenLDAP/releases/tag/v1.1.6) новая версия ReOpenLDAP (https://github.com/leo-yuriev/ReOpenLDAP) — форка  проекта OpenLDAP (http://www.openldap.org/), с устранением массы ошибок и ряда доработок для стабильной работы репликации. С выпуском 1.1.6 проект ReOpenLDAP отметил три года с момента своего основания (публичный форк появился чуть позже). Всё это время ReOpenLDAP работает 24x7 в инфраструктуре ПАО МегаФон, обеспечивая высоконагруженную обработку запросов в multi-master кластере с full-mesh репликацией. Версия 1.1.6 аккумулирует работу 8 месяцев этого года и включает: более сотни коммитов (https://github.com/leo-yuriev/ReOpenLDAP/compare/v1.1.5...v1...), в том числе более 50 исправлений ошибок; поддержку musl-libc (https://www.musl-libc.org), а также ряд доработок для совместимости и упрощения сборки; Continuous Integration на инфраструктуре Travis-CI (https://travis-ci.org/leo-yuriev/ReOpenLDAP) и Circle-CI (https://circleci.com/gh/leo-yuriev/ReOpenLDAP). С этим релизом ветка 1.1 получает статус архивно-стабильной. В ней будут исправляться ошибки, но какая-либо разработка будет прекращена. В свою очередь, работы в ветке 1.2 начнутся с переработки API в сопутствующих ldap-библиотеках с утратой совместимости с предыдущим версиями. Это позволит, с одной стороны, получить более прозрачное и удобное API, которое будет провоцировать меньше ошибок. С другой стороны, переработка API необходима для устранения неоднозначностей и адекватной работы статических анализаторов кода (Coverity, PVS-Studio и др.). Вторым изменением в ветке 1.2 будет переход на актуальную версию (https://github.com/leo-yuriev/libmdbx/blob/master/README.md) движка хранения libmdbx. Которая, среди прочего, поддерживает управление геометрией и бесплатную авто-компактификацию с освобождением места на диске. С точки зрения пользователя, это позволит автоматически и безболезненно как увеличивать, так и уменьшать размер БД, в том числе без остановки сервера или деградации услуг. К сожалению, новые возможности не даются бесплатно. Для возможности их реализации в libmdbx (https://github.com/leo-yuriev/libmdbx) был существенно переработан (и ещё не зафиксирован) внутренний формат БД, с потерей совместимости с предыдущими версиями. Пользуюсь случаем хочется ответить на частый вопрос "Почему нет пакетов?": ReOpenLDAP ориентирован на достаточно специализированные сценарии применения, для которых не представляется возможным создать универсальную конфигурацию и собрать соответствующий пакет. Во всех известных (авторам) случаях используются адаптированны под собственные нужды конфигурации (опции configure, включая подключаемые модули и оверлеи), в частности используются монолитные сборки с LTO (https://en.wikipedia.org/wiki/Interprocedural_optimization). Планируемые (и большей частью уже реализованные) доработки libmdbx также приведут к утрате совместимости по формату БД. Всё это вместе давало повод не формировать пакеты, так как последующие обновления нарушили бы совместимость и только огорчили пользователей. Авторы не владеют информацией (не имеют полноценного видения) о том, в какой именно конфигурации должен быть собран ReOpenLDAP для пакетирования. Поэтому мы (прежде всего) ждем встречной активности от тех, кто уже использует проект или планирует это сделать (состав компонентов и библиотек принципиально не изменится, поэтому всячески приветствуются pull-request-ы с пакетированием). URL: https://github.com/leo-yuriev/ReOpenLDAP/releases/tag/v1.1.6 Новость: https://www.opennet.ru/opennews/art.shtml?num=47015
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–1 +/–
Сообщение от Аноним (??) on 13-Авг-17, 22:21
Чем оно отличается от OpenLDAP? С апстримом синхронизируется или нет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+3 +/–
	Сообщение от Леонид Юрьев on 13-Авг-17, 22:37
	Да, "синхронизируется". Хотя "апстрим" кошмарен, если разобраться ) Рекомендую глянуть wiki, там более-менее всё рассказано = https://github.com/leo-yuriev/ReOpenLDAP/wiki Более подробный вариант = http://0x1.tv/ReOpenLDAP_%E2%80%94_%D1&#...(%D0%9B%D0%B5%D0%BE%D0%BD%D0%B8%D0%B4_%D0%AE%D1%80%D1%8C%D0%B5%D0%B2,_OSSDEVCONF-2016)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
	Сообщение от Леонид Юрьев on 13-Авг-17, 22:39
	Упс, безопасный вариант второй ссылки = http://bit.ly/2fD7sCL
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	33. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от Michael Shigorin (ok) on 14-Авг-17, 16:25
	>> OSSDEVCONF-2016 > Упс, безопасный вариант второй ссылки = http://bit.ly/2fD7sCL Кстати, приезжайте в этом году :) И ещё кстати: заметил сборку reopenldap-2.4.44 для эльбруса, не расскажете? (начиная с того, что нынче с версионированием)
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	35. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
	Сообщение от erthink (ok) on 14-Авг-17, 17:03
	>>> OSSDEVCONF-2016 >> Упс, безопасный вариант второй ссылки = http://bit.ly/2fD7sCL > Кстати, приезжайте в этом году :) Постараюсь :) Но увы обещать не могу ( Тут вот надо-бы в Брюссель ехать на https://ldapcon.org/2017/reopenldap/, а некогда ( > И ещё кстати: заметил сборку reopenldap-2.4.44 для эльбруса, не расскажете? (начиная с > того, что нынче с версионированием) Если кратко, то это не я, а ребята из РедСофт. Версионирование было изменено больше года назад, начиная с https://github.com/leo-yuriev/ReOpenLDAP/releases/tag/ReOpen... А ближайшее к 2.4.44 - это внутренняя версия = https://github.com/leo-yuriev/ReOpenLDAP/releases/tag/PS... Причем сейчас эту версию точно уже не стоит использовать, тем более чтобы портировать и т.д. Возможно они взяли именно эту или чуть более позднюю версию как drop-in replacement OpenLDAP, чтобы не заморачиваться с объединением liblber.so+libldap.so=>libreldap.so
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	52. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
	Сообщение от Shtirlitsus (??) on 16-Авг-17, 15:05
	> Если кратко, то это не я, а ребята из РедСофт. клевета. мы под Эльбрус ReOpenLdap не собирали.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	55. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от erthink (ok) on 16-Авг-17, 17:12
	>> Если кратко, то это не я, а ребята из РедСофт. > клевета. мы под Эльбрус ReOpenLdap не собирали. Пардон, у меня "под подозрением" были только вы ;) Точнее я был уверен... Больше идей нет, пакетов не видел, и патчей тоже. Причем там были мелкие гадости, которые поправил кажется весной. Чел собирал с libc-muls, кажется для ARM и там что-то повылазило (git log --oneline | grep musl). Поэтому для Эльбруса оно в лоб не собралось-бы. Но если будут вести - маякните pls.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	89. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–1 +/–
	Сообщение от Michael Shigorin (ok) on 22-Авг-17, 19:33
	> Поэтому для Эльбруса оно в лоб не собралось-бы. > Но если будут вести - маякните pls. Записал в тудушку спросить при встрече.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

5. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+6 +/–
Сообщение от Аноним (??) on 14-Авг-17, 00:08
> В свою очередь, работы в ветке 1.2 начнутся с переработки API в сопутствующих ldap-библиотеках с утратой совместимости с предыдущим версиями. Речь вот об этой наркомании? :        int ldap_search_ext(               LDAP *ld,               char *base,               int scope,               char *filter,               char *attrs[],               int attrsonly,               LDAPControl **serverctrls,               LDAPControl **clientctrls,               struct timeval *timeout,               int sizelimit,               int *msgidp );
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
	Сообщение от erthink (ok) on 14-Авг-17, 07:41
	>[оверквотинг удален] >   char *base, >   int scope, >   char *filter, >   char *attrs[], >   int attrsonly, >   LDAPControl **serverctrls, >   LDAPControl **clientctrls, >   struct timeval *timeout, >   int sizelimit, >   int *msgidp ); Нет. В этом API просто много параметров и пугающие LDAPControl**, но он логичен и корректен. Есть другие, где опциональным параметром передается указатель на уже выделенную память, которая будет использована повторно. Если же этот параметр NULL, то память выделяется внутри. Такая семантика сильно заморачивает Coverity, из-за чего идет лавина false-positives. Кроме этого, такое API часто провоцирует ошибки приводящие к утечкам памяти, либо к использованию уже освобожденных участков. Есть еще достаточно нелогичностей и костылей.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	28. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+2 +/–
	Сообщение от Аноним (??) on 14-Авг-17, 14:08
	Вы видели первую версию API ldap_search(), без _ext* ? Вот это называется "логично и корректно", а то что я привел - уже писали долбаные наркоманы, попытавшиеся запихнуть множество из того, что раньше настраивалось через десяток вызовов ldap_set_option() opaque-хэндла в параметры одного вызова поиска. Вся сокетная подсистема на этом стиле живёт, весь ioctl, netlink, и много кто ещё (sqlite, mysql, ...). И только авторы openldap-а Дартаньяны, и знают как надо библиотечное api проектировать для Си. А то что там в коде можно найти ещё более лютый ппц - я ни минуты не сомневаюсь.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	37. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+3 +/–
	Сообщение от erthink (ok) on 14-Авг-17, 17:38
	> Вы видели первую версию API ldap_search(), без _ext* ? Вот это называется > "логично и корректно", а то что я привел - уже писали > долбаные наркоманы, попытавшиеся запихнуть множество из того, что раньше настраивалось > через десяток вызовов ldap_set_option() opaque-хэндла в параметры одного вызова поиска. > Вся сокетная подсистема на этом стиле живёт, весь ioctl, netlink, и много > кто ещё (sqlite, mysql, ...). И только авторы openldap-а Дартаньяны, и > знают как надо библиотечное api проектировать для Си. > А то что там в коде можно найти ещё более лютый ппц > - я ни минуты не сомневаюсь. ldap_search() просто вызывает ldap_search_ex() подставляя кучу NULL. Использовать отдельные функции для установки каких-то unusual опций или параметров не всегда удобно. Точнее говоря, это требует создание, поддержки и удаления некоторого контекста. Тогда ldap_search() превратиться минимум в три вызова: ldap_search_request_create(), ldap_search_request_execute(), ldap_search_request_destroy(). Плюс еще десяток функций на установку всяческих опций и контроллов. В результате функция с несколькими параметрами превратиться в десяток-два функций и прочих конструкций. Притом что "на самом деле" ldap_search() формирует и выполняет один запрос, и примерно никакие лишние/дополнительные стейты ему не нужны. Сравнение с API уровня ioctl() и т.д. совершенно не корректно. Во-первых, тут важнее совместимость, т.е. к уже существующему простейшему API добавляют какие-то опции. Во-вторых, в этих API уже есть естественно существующий и необходимый контекст/стейт. В-третьих, тем не менее, такое управление опциями через несколько ioctl() создает огромный оверхед на системных вызовах, с которым как-то пытаются бороться (например в glibc). С другой стороны, ldap_search_ex() легко оборачивается в кружева на С++. Которые позволяют легко, удобно, безопасно, bla-bla-bla пользоваться API. Итого, как ни странно, но ldap_search_ex() - один из самых разумных методов обсуждаемого API.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

8. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–1 +/–
Сообщение от Ph0zzy (ok) on 14-Авг-17, 06:15
Если OpenLDAP не подошел может быть было лучше эти посмотреть: * http://directory.apache.org/ * http://directory.fedoraproject.org/ ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
	Сообщение от Аноним (??) on 14-Авг-17, 06:25
	FDS вряд ли им подойдет, т.к. неторопливый на их нагрузках (сказывается использование bdb)
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+3 +/–
	Сообщение от erthink (ok) on 14-Авг-17, 07:16
	> FDS вряд ли им подойдет, т.к. неторопливый на их нагрузках (сказывается использование > bdb) Да, примерно так, но хуже. На пробах нагрузку держал только OpenLDAP, все остальные на один-два порядка меньше. Один из "неподконтрольных хипстеров" пробовал AD (и из 2008, из 2012, и еще каких-то форточек), но результат был стабильно жуткий.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	29. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от PnDx (ok) on 14-Авг-17, 14:21
	Поставить OpenLDAP+HDB|MDB репликой к 389DS|FDS мульти-мастеру? 1. Управляемость. 2. Нагрузочная способность. 3. Профит. (4. Нюансы: не поддерживает навороченных хэшей (в 389DS всё на плагинах) и иных плюшек.)
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	30. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
	Сообщение от erthink (ok) on 14-Авг-17, 15:35
	> Поставить OpenLDAP+HDB|MDB репликой к 389DS|FDS мульти-мастеру? Увы, это все нереально. 389DS не справляется с требуемой нагрузкой. Если было-бы справлялся, то никакой реплики на OpenLDAP не надо. В этом случае и ReOpenLDAP не случился-бы. Это первое. Далее, после починки репликации в ReOpenLDAP, у меня есть сомнения что multi-master репликация в 389DS (и где-либо еще) работает на 100%. Там очень-очень не просто, особенно с учетом всех плагинов и схем (к слову, в AD у M$ тоже масса проблем и залежи костылей - думаю, не более 10 человек в MS полностью знают как оно "на самом деле" работает). Но это еще не все. https://pro-ldap.ru/tr/rfc/rfc4533.html - очень талантливый документ, можно легко сделать десяток реализаций в полном соответствии с ним, так что ни одна пара не сможет взаимодействовать. Поэтому примерно у всех LDAP-ов репликация/синхронизация работает только с сама-с-собой.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	41. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от PnDx (ok) on 14-Авг-17, 20:09
	> 389DS не справляется с требуемой нагрузкой. Да, и в моём случае корень проблемы даже не столько в BDB как таковой (на чтении она всё равно в памяти, а массивная запись в LDAP — ???), сколько в механизме репликации (плагины changelog5, retro-changelog). Которые пишут в журнал т.ч. kerberos-аттрибуты типа "время последней авторизации этого аккаунта". В *OpenLDAP такой проблемы нет, по очевидной причине. > Далее, после починки репликации в ReOpenLDAP, у меня есть сомнения что multi-master > репликация в 389DS (и где-либо еще) работает на 100%. Там очень-очень Да. Принимая соглашение multi-master, мы соглашаемся: 1. С (окончательной) потерей атомарности. 2. С возможностью навернуть репликацию, испортив журнал (и ещё 100500 увёрток мелким текстом). Прямо как у юристов. Но (иногда) с ней таки лучше. Если не делать, как M$-коллеги "а можно 50 m-m? можно! (утрирую, но не сильно)". > Но это еще не все. > https://pro-ldap.ru/tr/rfc/rfc4533.html - очень талантливый документ, можно легко сделать > десяток реализаций в полном соответствии с ним, так что ни одна > пара не сможет взаимодействовать. Поэтому примерно у всех LDAP-ов репликация/синхронизация > работает только с сама-с-собой.   Вот для этого как раз и поставляются 100500 плагинов для 389. Включая (уродский) retro-changelog, на который (я) ругаюсь как раз по причине неадекватной нагрузки на запись. Но: позволяющий создавать/поддерживать всякие интерфейсы к чужим системам. См. реализацию ёж&уж (bind9-ldap).   * В OpenLDAP система плагинов — вообще кошмар полный. Ошибка в (любом) плагине рушит демона. By design. Зато в пустом OpenLDAP никто не путается под ногами, что (в моём окружении) даёт x2…x3 даже на BDB.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	34. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от Michael Shigorin (ok) on 14-Авг-17, 16:28
	> Один из "неподконтрольных хипстеров" пробовал AD (и из 2008, из 2012, > и еще каких-то форточек), но результат был стабильно жуткий. В одном федеральном органе такой AD держался на сильно специальном контракте по поддержке -- интересно, что там сейчас...
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	63. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от arkan on 17-Авг-17, 13:22
	>> Один из "неподконтрольных хипстеров" пробовал AD (и из 2008, из 2012, >> и еще каких-то форточек), но результат был стабильно жуткий. > В одном федеральном органе такой AD держался на сильно специальном контракте по > поддержке -- интересно, что там сейчас... Не знаю про какой Вы там федеральный орган, но я лично участвовал во внедрении OpenLdap как полноценная замена виндовой AD в крупной компании Результаты были вполне хорошие но вот с управляемостью все на самописных скриптах кастылях и тому подобном оставляла желать лучшего Да и специалистов как то особо и не нашлось кто отвечал бы чисто за это направление. На сколько я знаю сейчас там этот OpenLdap стоит как дополнительный под какие то там задачи
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	90. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–1 +/–
	Сообщение от Michael Shigorin (ok) on 22-Авг-17, 19:36
	> Не знаю про какой Вы там федеральный орган, но я лично участвовал > во внедрении OpenLdap как полноценная замена виндовой AD в крупной компании Вообще LDAP -- не замена AD (который надмножество покорёженного LDAP), это самбу смотреть надо; например, http://altlinux.org/SambaDC (кстати, у нас недавно завелось и на эльбрусе).
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	12. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от erthink (ok) on 14-Авг-17, 08:15
	> Если OpenLDAP не подошел может быть было лучше эти посмотреть: > * http://directory.apache.org/ > * http://directory.fedoraproject.org/ > ? У OpenDJ или 389DS будет шанс обогнать ReOpenLDAP по скорости только при замене движка хранения на libmdbx. Но OpenDJ -- это ява и тамошние ценители седеют просто глядя на код LMDB/libmdbx, даже через JNI. А 389DS очень сильно заражен Berkeley DB. Дрянная днк BDB там прослеживается в половине проекта и для возможности подключения другого backend-а нужно проделать большую работу = вычистить хвосты BDB и сформировать достаточный внутренний API для plugable подсистемы хранения.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	14. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–1 +/–
	Сообщение от Ph0zzy (ok) on 14-Авг-17, 08:50
	т.е. проблема именно в неприятии java? а значит ApacheDS пролетает из-за этого же?
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	17. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+2 +/–
	Сообщение от erthink (ok) on 14-Авг-17, 09:17
	> т.е. проблема именно в неприятии java? > а значит ApacheDS пролетает из-за этого же? Что значит "неприятие Java"? Неприятие кем? Пролетает где? Безотносительно ApacheDS/OpenDJ и ReOpenLDAP, я могу повторить свою позицию = то что можно сделать в Java быстро, то в C/C++ (и даже в Rust) можно сделать еще быстрее (и часто намного быстрее, он и трудозатратнее). Однако, к выбору OpenLDAP (что было давным-давно) это мое "мнение" никак не относится, вообще совсем. OpenLDAP был выбран примерно по двум причинам: 1) На пробах только OpenLDAP показал приемлемую производительность, все остальные безнадежно отставали. 2) OpenLDAP представлялся заслуживающим доверия (много пользователей, много версий, много установок). Одно интервью Ховарда чего стоит = https://www.opennet.ru/opennews/art.shtml?num=14723
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	23. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+4 +/–
	Сообщение от andy (??) on 14-Авг-17, 10:29
	Это не проблема, это реалии жизни. Потому, что большая часть того, что пишется на java, являет собой кучу гуано.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	16. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от Ph0zzy (ok) on 14-Авг-17, 09:09
	а на счет этого http://directory.apache.org/mavibot/ движка что скажете?
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	26. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
	Сообщение от erthink (ok) on 14-Авг-17, 11:40
	С Mavibot в работе я не сталкивался. Судя по описанию его устройство очень близко к libmdbx и LMDB. Очень похоже что это "inspired by LMDB" также как BoltDB и т.д. Однако, комбинация B-tree, MVCC и COW не обязана дать гарантированный результат (производительность). Там очень много подводных камней и "фишек". Например реклайминг в LIFO-порядке и авто-компактификация. Поэтому я не удивлюсь если Mavibot показывает на порядок более низкие результаты чем LMDB, не говоря о libmdbx (есть есть LIFO, авто-компактификация и другие фичи). Банчмарков самого Mavibot я не нашел = https://www.google.ru/search?q=apache+mavibot+benchmark Свежих бенчмарков Apache Directory Service тоже, по-прежнему есть только https://www.slideshare.net/ldapcon/benchmarks-on-ldap-direct... Причем в этих текстах OpenLDAP выглядит несколько хуже чем в наших, а на слайдах есть странности: 1) В тесте скорости загрузки OpenLDAP идет аж четвертым, а потом уделывает всех в остальных тестах, включая write (обновления) - такого быть не может, и я не разу не видел. 2) Непонятная разница между 32-битной и 64-битной версиями (подозреваю что собрано с разными опциями, assert-ы, отладочное логирование и т.п). 3) Иногда hdb-бакенд обгоняет mdb - никогда такого не видел.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	27. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от Ph0zzy (ok) on 14-Авг-17, 12:37
	Последние несколько лет сильно за темой не слежу, так что эта новость первая, которую вижу по данной тематике. Складывается впечатление, что по теме застой. Так что отсутствие свежих бенчмарков показательно.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	31. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+3 +/–
	Сообщение от erthink (ok) on 14-Авг-17, 15:56
	> Последние несколько лет сильно за темой не слежу, так что эта новость > первая, которую вижу по данной тематике. Складывается впечатление, что по теме > застой. Так что отсутствие свежих бенчмарков показательно. Я бы не сказал что застой, точнее он только в OpenLDAP (причины в моем понимании уже озвучивал). Остальные проекты более-менее двигаются. А вот с бенчмарками история интересная. Пруф-ссылок не накидаю (не копил), но несколько раз повторялась примерно такая история: - какой-нибудь "условный Sun" делает бенчмарк и публикует результаты "Мы спереди планеты всей..., покупайте у нас..."; - Ховард из Symas повторяет бенч с участием OpenLDAP (иногда что-нибудь подкручивая) и наглядно всех делает; - на выходе "условный Sun" теряет лицо, а OpenLDAP получает use-case, а иногда и несколько патчей. В ответ на это, часть "условных Sun-ы" постепенно добавило в лицензии добавили пункт запрещающий публиковать результаты тестов, особенно сравнительных. Гениальное решение. Другая часть "условных Sun-ов" поступила мудрее - они стали просто немного допиливать и ребрендить OpenLDAP, как с помощью Symas, так и без.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

13. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–2 +/–
Сообщение от Аноним (??) on 14-Авг-17, 08:44
>хочется ответить на частый вопрос "Почему нет пакетов?" хорошо, а почему нет ебилдов?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	20. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+2 +/–
	Сообщение от erthink (ok) on 14-Авг-17, 09:31
	Потому-что нам они не нужны, а вы их не сделали. Welcome = https://github.com/leo-yuriev/ReOpenLDAP/issues/35 :)
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
Сообщение от Аноним (??) on 14-Авг-17, 09:06
В чем преимущества по сравнению с 389 Directtory Server (RedHat Directory Server)?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
	Сообщение от erthink (ok) on 14-Авг-17, 09:23
	> В чем преимущества по сравнению с 389 Directtory Server (RedHat Directory Server)? Повторю еще раз = скорость. Чтобы у 389DS были шансы сравниться с OpenLDAP или ReOpenLDAP нужно вместо Berkeley DB использовать https://github.com/leo-yuriev/libmdbx или хотя-бы какой-нибудь WiredTiger. Причем я полностью согласен, что 389DS сейчас имеет гораздо более красивый и надежный код. Но вот backend хранения - из прошлого века.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	22. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от Аноним (??) on 14-Авг-17, 10:28
	А вы пробовали с Red Hat на эту тему поговорить (разумеется с бенчмарками и прочими пруфами)?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	25. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+2 +/–
	Сообщение от erthink (ok) on 14-Авг-17, 11:00
	> А вы пробовали с Red Hat на эту тему поговорить (разумеется с > бенчмарками и прочими пруфами)? Говорить по-сути не о чем. Проблема в другом, и уже давно как бревно в глазу. У RedHat в 389DS нет какой-либо инфраструктуры (даже зачатков) для подключения движков/бакендов хранения. Все гвоздями прибито к BDB (Berkeley DB), точнее даже не прибито, а приварено. Думаю, что они рады-бы поменять устаревшее BDB-гobнo (уже извините) на что угодно, хоть на LevelDB. Одни проблемы с лицензией чего стоят... Однако, для этого нужно на полгода-год остановить всю разработку и заниматься только этим, т.е. делать инфраструктуру подключения storage backend. Соответственно, до появления этой инфраструктуры и API нет смыслы обсуждать подключение новых подсистем хранения, тем более замену. Более того, если был-бы подобный API, то (наверное) я бы не удержался и сделал вариант 389DS на https://github.com/leo-yuriev/libmdbx ;)
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

19. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+4 +/–
Сообщение от Аноним (??) on 14-Авг-17, 09:26
Бурханыч еще и в сторону LDAP развивает Интернет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	88. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
	Сообщение от erthink (ok) on 21-Авг-17, 00:23
	> Бурханыч еще и в сторону LDAP развивает Интернет? Слоупок я, дошло о чем спрашивали ;) Может и развивает, но мне об этом ничего не известно. Если говорить о ReOpenLDAP, то эта работа была сделана исключительно для решения проблем возникших (достаточно неожиданно) при внедрении одного из решений Петер-Сервис внутри МегаФона. С сентября 2016 проект не аффинирован с какой-либо коммерческой структурой (не считая публичных сервисов: github, travis-ci и т.п.).
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

21. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–1 +/–
Сообщение от Ph0zzy (ok) on 14-Авг-17, 10:25
может быть, если бы вы в своих репозиториях в гитхабе использовали другой язык, удалось привлечь внимание большего количества разарботчиков?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от erthink (ok) on 14-Авг-17, 10:40
	Да, конечно, это очевидно. Но "не все так однозначно". Собственно главная проблема унаследована от OpenLDAP. Исходный код кошмарен с точки зрения читаемости и подводных камней. Эффективно с ним работать может только авторы, точнее сам Ховард и может-быть кто-то еще. Всем остальным приходиться тратить массу времени на понимание написанного, особенно всех взаимосвязей и side effects. Поэтому, на самом деле, вне зависимости от языка и прочих ритуалов привлечения внимания, в ReOpenLDAP не будет много больше разработчиков чем в исходном OpenLDAP.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

32. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
Сообщение от ALex_hha (ok) on 14-Авг-17, 16:13
А почему не LibreLDAP/LibreOpenLDAP? Зачем ломать стереотпы
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	36. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от erthink (ok) on 14-Авг-17, 17:16
	Исходная цель ReOpenLDAP была попроще = навести минимальный порядок и поправить баги мешающие (мягко говоря) эксплуатации. Ну и Libre тогда только у офиса была, стереотипов еще не было )
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

38. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–1 +/–
Сообщение от лютый жабист__ on 14-Авг-17, 18:22
Если такие прямо несусветные запросы к производительности, почему не взяли просто in memory rdbms?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	39. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–1 +/–
	Сообщение от лютый жабист__ on 14-Авг-17, 18:23
	fix: не rdbms конечно, а dbms
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	40. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от erthink (ok) on 14-Авг-17, 19:01
	> fix: не rdbms конечно, а dbms Начиналось с другого, совсем. Просматривался вариант реализовать одну из подсистем с участием LDAP-сервера. Кроме этого, в "принципе не помешал-бы" некий работающий LDAP-blackbox. Протестировали производительнось, прошел только OpenLDAP. Проблемы всплыли много позже, и тогда меня позвали починить... Собственно, что я перессказываю - там выше есть ссылка на запись доклада. А где-то там у Стаса рядом есть запись и доклада с 2015. Но если абстрагироваться от истории, то inmemory+wal конечно подходит. Но тогда Костин tarantool был ещё не так крут/готов, а главное - OpenLDAP работал в тестах и никто не ожидал "напильника" в два года.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	42. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–3 +/–
	Сообщение от лютый жабист__ on 15-Авг-17, 11:52
	Есть полно промышленных решений особенно на почитаемой вами жабе которые не надо было ждать :D итого архитектора на мыло, трудозатраты не оценили путём, два года ваяли велосипед
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	43. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
	Сообщение от erthink (ok) on 15-Авг-17, 12:47
	> Есть полно промышленных решений особенно на почитаемой вами жабе которые не надо > было ждать :D итого архитектора на мыло, трудозатраты не оценили путём, > два года ваяли велосипед У вас есть неточность - на java НЕТ промышленных (и не промышленных) решений которые могут заменить или как-то конкурировать с ReOpenLDAP. Даже без репликации они уступают в 5-10 раз (точнее сказать сложно: разное железо, схемы, характер запросов и т.д.) при условии работы in-memory. А как только требуется фиксация на диске, то java неожиданно заносит и все тонет в IOPS. Далее, если разобраться, то все "промышленные решения на яве", на деле оказываются чуть менее чем XY-ней, примерно везде где нужна производительность (а не "кони в вакууме" или "фабрики фабрик для фабрик молотков"). А все исключения из этого наблюдения устойчиво попадают в шаблон: сверху на яве рисуются кнопочки и "IB-розочки", а снизу через JNI все делает C/C++. Причем на 20% в этом виновата сама Java, с "парой чемоданов батареек" в виде виртуальной машины, сборки мусора и т.п. И на 80% - экосистема, где здравый смысл принесен в жертву религии шарообразных абстракций, паттернов и некого стиля. Вот только уточню: в огромной массе других случаев java - отличный язык и технология, в том числе более дешевый.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	44. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+2 +/–
	Сообщение от erthink (ok) on 15-Авг-17, 13:51
	Чуть наброшу по теме Java. Все ошибаются, и нисколько я не исключение. Поэтому, если (вдруг) все-таки есть какие-то java-решения на замену ReOpenLDAP, то я вам советую/прошу предложить их в billing.ru. Может даже поучаствовать во внедрении. Жабу там беззаветно любят, если не ошибаюсь - уже лет 15. Однако, все-же есть риски что не примут (пошлют). Ибо уже года 3 (могу ошибаться) срывают сроки релизов из-за того, что "промышленные решения на java" работают чуть медленнее чем надо (а чертовы мегагерцы перестали расти). Причем, там же можно будет выяснить (лицом к лицу) актуальность общеизвестных и как-бы основных причин (руки из попы, люди-снежинки, танцорам что-то мешает) плохих java-показателей. Ну и показать "как надо". Короче, всячески рекомендую.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	45. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–4 +/–
	Сообщение от лютый жабист__ on 16-Авг-17, 09:04
	"Ибо уже года 3 (могу ошибаться) срывают сроки релизов из-за того" По личному опыту - в телекомах ЗП ровно вдвое ниже, чем у нормального бизнеса. Соответственно, то что кто-то там сидит и три года за еду срывает сроки, ничего не доказывает. "фабрики фабрик для фабрик молотков" На плюсах никто не мешает такую же ахинею городить. А вот о твоей компетенции выводы уже можно делать. Ещё напиши про сборщик мусора, как он часами ужасный stop the world делает 8))) По "прошу предложить" Где ТЗ? Чтобы было о чём говорить. В целом по теме. Известно что однопоточная прожка на анси си, на 30-50 % быстрее однопоточной на жабе. На плюсах практически одинаково. А вот полная утилизация хотя бы 12ядерного проца на сишечках это уже приключение. Хотя на жабе это под силу и весьма среднему прогеру.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	48. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от erthink (ok) on 16-Авг-17, 12:12
	> По личному опыту... [...] Я там ответил, но получилось в новой ветке (видимо промазал по ссылке).
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	59. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+4 +/–
	Сообщение от Аноним (??) on 17-Авг-17, 10:31
	В способности тру-жабистов нагрузить в полку все 100500 ядер системы даже обычным "Hello world!" никто и не сомневается.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

46. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
Сообщение от erthink (ok) on 16-Авг-17, 11:56
> По личному опыту - в телекомах ЗП ровно вдвое ниже, чем у нормального бизнеса. Не заметил. > Соответственно, то что кто-то там сидит и три года за еду срывает сроки, ничего не доказывает. На самом деле платят и ищут профи. Просто предложите свои услуги, если не слабо: - https://hh.ru/vacancy/20985959 - https://hh.ru/vacancy/20965714 Мои компетенции можно по-обсуждать публично: - http://www.highload.ru/2017/abstracts/2837.html - http://www.highload.ru/2017/abstracts/2838.html - В Калуге на http://bit.ly/2w9xWTq - В Брюсселе на https://ldapcon.org/2017/ Приходите. Welcome. На всякий, еще раз замечу: - Java отличный язык, особенно когда C/C++ не подходит (non reasonable) или их не осилили/загoвнoкодили. - разработка на Java всегда будет менее трудозатратной (дешевле) чем аналогичное C/C++. - правильно сделанная программа на Java всегда будет медленнее и прожорливее аналога на C/C++.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	47. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+2 +/–
	Сообщение от erthink (ok) on 16-Авг-17, 12:09
	Ох, судя по описанию java-вакансии в Петер-Сервисе еще не все пальцы отгорели от засовывания highload в розетки типа ElasticSearch и Cassandra :) И причины появления http://www.scylladb.com не вразумили, жаль.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	49. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–3 +/–
	Сообщение от лютый жабист__ on 16-Авг-17, 12:26
	> На самом деле платят и ищут профи. По вакансии не скажешь, что ищут профи. "Ожидания" уровня простого жабакодера. з/п не указана. Ещё и Питер. "правильно сделанная программа на Java всегда будет медленнее и прожорливее аналога на C/C++." Ты опять неправ. Про утилизацию железа уже писал. Из личных наблюдений сишные Постгрес, Монго, Оракле на например 12-ядернике дальше 1-2 ядер НИКОГДА не вылазят. Мои жабные поделки - легко, иногда даже без доп телодвижений (те же Collections из core многопоточны из коробки). Кстати, из общения с продуктами Positive Technologies. SIEM полный шлак по сравнению со ВСЕМИ рассмотренными конкурентами. Сканер сети шлак, а цена космос. Только менеджеры говорливые, обещают что "вот-вот всё станет круто". Так что предлагаю авторитетом не давить ;)
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	50. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
	Сообщение от erthink (ok) on 16-Авг-17, 13:10
	>> На самом деле платят и ищут профи. > По вакансии не скажешь, что ищут профи. "Ожидания" уровня простого жабакодера. з/п > не указана. Ещё и Питер. Ну я уже понял что вы у нас коренной уникум из defaultcity и "за еду" в Питер не поедете. Может покажите что-нибудь для острастки, на github например? >> "правильно сделанная программа на Java всегда будет медленнее и прожорливее аналога на >> C/C++." > Ты опять неправ. Про утилизацию железа уже писал. Из личных наблюдений сишные > Постгрес, Монго, Оракле на например 12-ядернике дальше 1-2 ядер НИКОГДА не > вылазят. Мои жабные поделки - легко, иногда даже без доп телодвижений > (те же Collections из core многопоточны из коробки). Я не хочу спорить с вами о вещах, которые вы не понимаете. Точнее, видимо, не понимаете до конца как они работают. Говоря пафосно, пытаться обогнать C/C++ на Java - это примерно как превысить скорость света :) С одной стороны, в яве не ничего, чего нельзя-было бы сделать на С/C++ (но на Java может быть _дешевле_). С другой стороны, в ява неизбежны накладные расходы при организации структур данных. Конечно можно все сделать на массивах из primitive types или в unsafe (который "внезапно" до-сих пор не выкинули), но тогда зачем вообще тут Java? > Кстати, из общения с продуктами Positive Technologies. SIEM полный шлак по сравнению > со ВСЕМИ рассмотренными конкурентами. Сканер сети шлак, а цена космос. Только > менеджеры говорливые, обещают что "вот-вот всё станет круто". Так что предлагаю > авторитетом не давить ;) Это как-раз "не кстати" и не имеет отношения к теме, а просто показывает отсутствие у вас экспертизы и других аргументов. Рекомендую начать с изучения причин попадания Positive Technologies в "магический квадрант". Тем не менее - я вам не скажу за "всю Одессу", особенно за продукты с ложкой такого java-кошмара как ElasticSearch... Но если же есть что-то сказать, то приходите на https://www.phdays.ru и/или http://www.securitylab.ru А вот с моими "поделиями" все просто = берете линейку и меряете. Давайте начнем с этих мелочей и до "Позитива" доберемся чуть позже (и для релевантности после релизов с каким-нибудь моим участием).
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	51. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–5 +/–
	Сообщение от лютый жабист__ on 16-Авг-17, 14:42
	Какие кадры на hl встречаются, ржу не могу... Увы, си днище, потому что нормальные прогеры пишут сразу в машинных кодах. И субд и распределенные системы. А си ваше тормозит и глючит, особенно с -O3, знаем, плавали.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	54. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от erthink (ok) on 16-Авг-17, 17:05
	> Какие кадры на hl встречаются, ржу не могу... Увы, си днище, потому > что нормальные прогеры пишут сразу в машинных кодах. И субд и > распределенные системы. А си ваше тормозит и глючит, особенно с -O3, > знаем, плавали. Да, понимаю. Но вы держитесь, нас всех когда-нибудь вылечат ;) Короче, шанс еще есть, держитесь!
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	58. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от bOOster (ok) on 17-Авг-17, 06:23
	Гражданин, в твоем кривом мозгу не созрело что JAVA изначально тоже писана на C? И собирается с теми-же -O ключами? "де$илы, $ля" (с)
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	61. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–2 +/–
	Сообщение от лютый жабист__ on 17-Авг-17, 11:48
	>JAVA изначально тоже писана на C И посмотри сколько ДЫРИЩ в каждой версии. Жду не дождусь когда жабку перепишут на rust-е, а си и на этой задаче пойдёт в помойку ;)
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	69. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от bOOster (ok) on 17-Авг-17, 21:09
	Ну а rust видимо из "святым духом" программировался из сферического вакуума простанства и времени… (facepalm)
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	87. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–5 +/–
	Сообщение от лютый жабист__ on 19-Авг-17, 16:36
	> Ну а rust видимо из "святым духом" программировался из сферического вакуума простанства > и времени… (facepalm) Такой сверхироничный ламер, просто диву даюсь. Раст это компилятор, пусть его хоть на брейнфаке пишут, глюки сишечки в него никак не переползут. В отличие от виртуальной машины JVM (это даже если раст на сях пишут, в чём не уверен).
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	56. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–4 +/–
	Сообщение от Лис on 16-Авг-17, 21:48
	Я жабу не люблю, но насколько я знаю, за счёт вирт. машины можно делать runtime-оптимизации недоступные сишке и отчего жаба будет быстрее в определённых случаях. Так что про скорость света это может быть несколько ошибочно.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	57. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
	Сообщение от erthink (ok) on 16-Авг-17, 23:32
	> Я жабу не люблю, но насколько я знаю, за счёт вирт. машины > можно делать runtime-оптимизации недоступные сишке и отчего жаба будет быстрее в > определённых случаях. > Так что про скорость света это может быть несколько ошибочно. JIT и интроспекция действительно позволяют делать некоторую оптимизацию, но вот кол-во случаев когда это получается и дает результат не так много: 1. Всяческое "совсем" позднее связывание (включая подгрузку каких-то классов на ходу), что в случае java перетекает в следующий подпункт; 2. Генерация кода самой программой; 3. Если выясняется что какой-то метод вызывается очень часто, в том числе когда часть или все параметры зафиксированы; В C/C++ штатного JIT конечно нет, но при необходимости есть несколько вариантов (NativeJIT, LLVM, даже jithabr). Подпункты же 1 и 3 примерно не актуальны, т.е. дают выигрыш в экосистем java, а в C/C++ и без них нормально. Поэтому, в качестве итога = за счет упомянутых оптимизаций java может обогнать только плохой (плохо спроектированный или бездумный) код C/C++. Но в этом может быть и прелесть явы: можно упopото вить веревки из паттернов и абстракций, потом вжух и в продакшин, и оно будет работать (только медленнее C/C++).
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	64. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–3 +/–
	Сообщение от лютый жабист__ on 17-Авг-17, 17:21
	>скорость света, скорость света, скорость света Гуру из Positive Technologies видимо не знает, что в теоретической физике уже лет 100 как вполне допускается передвижение быстрее С. ;) wormhole называется. Что самое смешное, аналогия вполне в тему - движение тушки в пространстве это цепочка си - ассемблер - машинные инструкции. Си тут ДАЛЕКО не "скорость света". А на мейнфреймах с Z/OS некоторые операции жабы исполняются сразу процом. Вполне себе такой wormhole. Си в пролёте... ;)
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	65. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+2 +/–
	Сообщение от Аноним (??) on 17-Авг-17, 17:55
	Тоже слышал про сжатие пространства и отрицательную энергию. Но трицательный IQ вижу впервые, это прохая реклама для жабы.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	66. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–3 +/–
	Сообщение от лютый жабист__ on 17-Авг-17, 18:04
	Кстати, ещё очевидный тезис, не раз его озвучивал. JVM проектируют и программят зубры, навроде Шипилева. А прожки пишут простые Васи-погромисты. Половина из них чуть лучше среднего, а половина так и хуже среднего. Только не надо блабла, что сишнике все сплошь с IQ 150++ Поэтому равнять оптимизации Васи-погромиста и оптимизации Шипилёва - признак небольшого ума. Итого прога на жабе из под обычного прогера-жабиста может легко обогнать прогу на си обычного прогера-сишника. Шах и мат, братишки! Надоело очевидное рассказывать...
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	68. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+3 +/–
	Сообщение от erthink (ok) on 17-Авг-17, 20:36
	Оставьте вы Леху в покое, его уже и так допекли разные грамотеи. Знаете яву - отлично, знаете как процы работают - еще лучше. Так продемонстрируйте сами что-нибудь, своё и не бесполезное. Нет готового - сделайте, а не страдайте тут маразмом. К примеру, вот возьмите и реализуйте на java это = https://github.com/leo-yuriev/t1ha Некоторые "идиоты" (включая меня) утверждают, что это толком не возможно (будет в 4-6 раз медленнее) - покажите обратное. Если (вдруг) не получится, то можно сделать пользу = пробросить вызовы через "Critial Natives" = https://bugs.openjdk.java.net/browse/JDK-7013347 Попробуйте сделать bench, посмотрите в v-tune и т.д. Море возможностей...
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	70. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
	Сообщение от bOOster (ok) on 17-Авг-17, 21:19
	> К примеру, вот возьмите и реализуйте на java это = https://github.com/leo-yuriev/t1ha > Некоторые "идиоты" (включая меня) утверждают, что это толком не возможно (будет в > 4-6 раз медленнее) - покажите обратное. Знатно потролилил убогого ) Хотя это и реализуется, и почти без падения производительности, но через JNI и опять с выходом на C :)
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	72. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от erthink (ok) on 17-Авг-17, 21:27
	> Знатно потролилил убогого ) Хотя это и реализуется, и почти без падения > производительности, но через JNI и опять с выходом на C :) Не, это было лишнее. Удалил.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	75. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от erthink (ok) on 17-Авг-17, 22:43
	> Знатно потролилил убогого ) Хотя это и реализуется, и почти без падения > производительности, но через JNI и опять с выходом на C :) В java нет uint64_t, поэтому умножение u64xu64->u128 придется делать через %$#, например так = https://github.com/leo-yuriev/t1ha/blob/25f790b6723fa0035f2b... В результате вместо одного (но "широкого") умножения будет аж 4, плюс сдвиги и сложения. java.math.BigInteger - да можно, но оверхед достаточно показательный.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	80. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–5 +/–
	Сообщение от лютый жабист__ on 18-Авг-17, 05:17
	>его уже и так допекли разные грамотеи. The Future will Positive which are not uses specific hardware tricks это ты про себя? :) хау мач вотч, мгимо финишд? По хэш функции. Опять сишники сваливаются в микробенчмарки. Не интересно абсолютно.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	81. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+4 +/–
	Сообщение от Аноним (??) on 18-Авг-17, 12:32
	>The Future will Positive >which are not uses specific hardware tricks Ну так предложите автору исправления. Посмейтесь вместе с носителем языка и покажите как должно быть. Ткните носом, с аргументацией (правила из учебника). >это ты про себя? :) хау мач вотч, мгимо финишд? По делу есть-что аргументировать, кроме продолжения "сам дурак"? >По хэш функции. Опять сишники сваливаются в микробенчмарки. Не интересно абсолютно. Возьмите линейку, измерьте и покажите: вот такая-то задача, вот её код, вот код "линейки", вот и тут Java быстрее C++ на столько-то. Либо отыщите готовые результаты. Ведь их же должно быть валом? PS: Вас культурно и многократно выпороли, а вы продолжаете что-то изображать.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	82. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–3 +/–
	Сообщение от лютый жабист__ on 18-Авг-17, 16:53
	Если не заниматься тактодрчерством, а брать практические задачи, например FTSдвижок, графовую субд с мощным движком (где можно за небольшое время написать свой траверсер или выбрать из кучи стандартных) то могучих сишников как ветром сдувает. Покажите аналог jboss-а под си. Мне и мерять ничего не надо, кровавый ынтырпрайз лепится на жабе и точка.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	84. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от erthink (ok) on 18-Авг-17, 21:50
	> Если не заниматься тактодрчерством, а брать практические задачи, например FTSдвижок, графовую субд с мощным движком (где можно за небольшое время написать свой траверсер или выбрать из кучи стандартных) то могучих сишников как ветром сдувает. Покажите аналог jboss-а под си. Мне и мерять ничего не надо, кровавый ынтырпрайз лепится на жабе и точка. Все практические задачи состоят из простых действий, каждое из которых корректнее измерять в тактах. А вся оптимизация заключается в экономии этих тактов, чем собственно и занимается упомянутый вами Шипилев в рабочее время. Полнотекстовый поиск (FTS), семантический анализ, графовые БД, RDF и все прочие практические задачи (с "нелинейными" манипуляциями структурами данных "на указателях") в C/C++ всегда будут быстрее. Поэтому Sphinx от Андрюхи рвет какой-нибудь ElasticSearch почти также как ScyllaDb унижает Cassandra. Однако, на Java делать подобные аппликухи-залипухи в 42 раза проще/дешевле, включая всякие POCи,  плагинчики и прочие XY-инчики. К сожалению, это и более выгодно - рынок пока еще ведется на "безопасность и надежность" Java в обработке данных. Поэтому генерируется очень много "мега-проектов", которые индустрия не успевает вовремя переварить и слить (по-сути ими забита канализация). Короче, попробуйте загрузить в ElasticSearch пару десятков миллионов чего-нибудь больше "Hello Word"... Увидите как яву укачивает и тошнит везде где нетривиальные задачи сочетаются с нагрузкой. Иногда может показаться что оно работает быстро - пока не будет повторено на C/C++ (как ScyllaDB); и как-бы надежно - но до нехватки памяти, места на диске и т.п., а потом абсракции сталкиваются с реалиями; и как-бы безопаснее чем C/C++... А вот со всяческой оркестрацией и "архитектурной гибкостью" у Java наоборот очень хорошо. Чуть менее чем все паттерны там очень хорошо/обильно и давно смазаны вазелином. Адаптеры, фасады и всяческие другие виды прокладок позволяют решать месячные проблемы бизнес-архитекторов и прочих "аналитегов". Поэтому "кровавый ынтерпрайз" неотделим от java, и  от обоих инженеров тошнит примерно одинаково. Вот поэтому "кровавый ынтерпрайз", когда дело доходит до нагрузки и производительности - либо загибается и умирает, либо эволюционирует и прозревает в отношении jboss и прочей явоты. Тем не менее, я еще раз повторю: Java прекрасна и очень-очень к месту, там где требуемая производительность позволяет транжирить такты CPU и мегабайты RAM.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	85. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	–3 +/–
	Сообщение от лютый жабист__ on 19-Авг-17, 06:02
	>Sphinx рвет ElasticSearch >ScyllaDb унижает Cassandra Ты наверное из далекого будущего пишешь, ScyllaDb появилось на 10 лет позже Каси и до сих пор не реализован весь функционал этого drop-in (хыхы) replacement. Инсталляций 3.5 на всю планету. Sphynx через 50 лет, видимо, тоже будет рулить. Тебе лучше знать. Лучше расскажи, почему в вашем Positive Technology SIEM слепили на богомерзком ElasticSearch? При этом имея storage в виде mongo которое сишное и имеет встроенный FTS (по моему опыту более тормозной upto 1000x и убогий) У них же такие эксперты-сишники работают :)
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	91. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от Michael Shigorin (ok) on 22-Авг-17, 19:44
	> Если не заниматься тактодрчерством, а брать практические задачи ...то мне на той неделе одни люди говорили о том, как собираются жабу менять на сишечку примерно в масштабах ЦОДа. Вас и впрямь выпороли.  Причины [смутного] беспокойства тоже отчасти понятны, я бы тоже беспокоился при таком поведении оракла в стеклянном доме...
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	78. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
	Сообщение от Led (ok) on 18-Авг-17, 00:01
	> JVM проектируют и программят зубры, Зубры, мкаки, хомячки и прочие насекомые - много вас таких.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	86. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+3 +/–
	Сообщение от Павленскй on 19-Авг-17, 10:39
	Хм, ява вместо брусчатки. Коллега что-ли?
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

67. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+1 +/–
Сообщение от erthink (ok) on 17-Авг-17, 18:40
RTFM. Запросы поиска/чтения в ReOpenLDAP и libmdbx масштабируются линейно по ядрам CPU.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	74. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от Лис on 17-Авг-17, 22:20
	Спасибо за интересный проект. Такой вопрос. Хочу использовать libmdbx как хранилище в golang, я нашёл биндинг к LMDB https://github.com/bmatsuo/lmdb-go но наверное для libmdbx его нужно адаптировать, если да то насколько сильно? До этого думал использовать boltdb (для реалтайм хранилища/горячего кэша), но судя по описанию в биндинге даже стандартный LMDB в сочетании с го дают большую скорость чем родной болт.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	76. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+2 +/–
	Сообщение от erthink (ok) on 17-Авг-17, 23:12
	> Спасибо за интересный проект. > Такой вопрос. > Хочу использовать libmdbx как хранилище в golang, я нашёл биндинг к LMDB > https://github.com/bmatsuo/lmdb-go но наверное для libmdbx его нужно адаптировать, если > да то насколько сильно? > До этого думал использовать boltdb (для реалтайм хранилища/горячего кэша), но судя по > описанию в биндинге даже стандартный LMDB в сочетании с го дают > большую скорость чем родной болт. Да, нужно адаптировать. Но думаю изменения будут небольшие и в основном механические. Однако, вынужден предупредить - формат БД и API в master и devel еще не зафиксированы. Революций в API не будет, но какие-то доработки в байндингах точно потребуются. А формат БД и внутренности будут меняться достаточно серьезно. Старую стабильную версию из stable/0.0 использовать не рекомендую. В свое время (для МегаФона) одним из требований была совместимость по формату БД. Поэтому многие принципиальные фичи были невозможны. Дополню: Совместимость текстового формата dump/restore будет поддерживаться, в том числе с LMDB (если вдруг это не так - то это баг).
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	79. "Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP"	+/–
	Сообщение от Лис on 18-Авг-17, 00:30
	Спасибо за ответ.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема