Форум » LetoDB, HbNetio. » LetoDb fork » Ответить
LetoDb fork
PSP: https://github.com/elchs/LetoDBf https://github.com/elchs/LetoDBf/blob/master/README.md Кто-нибудь пробовал или использует в продакшене?
PSP: SergKis пишет: Судя по Changelog.txt сборки пекутся как пирожки, т.е. сыровато еще состояние Согласен. Поэтому и не спешу искать)
Sergy: SergKis пишет: Судя по Changelog.txt сборки пекутся как пирожки, т.е. сыровато еще состояние Не собираюсь никого защищать, но с лета-осени 2017г никаких существенных для программиста изменений не было. Насколько мой английский мне позволяет понять ситуацию - Рольф закусился с Linux/SMB сервером: там обнаружился странный косяк: два приложения (сервер Leto и обычная программа на DBFCDX/DBFNTX) пытаются в монопольном режиме получить доступ к файлу и оба... успешно его получают. Судя по переписке в форуме - похоже что решил.
SergKis: Sergy пишет Не собираюсь никого защищать, но с лета-осени 2017г никаких существенных для программиста изменений не было. Так я и не нападаю, надо пробовать в тестовом режиме, если видны плюсы перехода. Для себя, пока, не вижу необходимости переходить, хотя режим No_Save_WA = 1 интересует в letoDB, но руки не доходят.
SergKis: Sergy пишет там обнаружился странный косяк: два приложения (сервер Leto и обычная программа на DBFCDX/DBFNTX) пытаются в монопольном режиме получить доступ к файлу и оба... успешно его получают Share_Tables = 1 для меня основной, т.к. letodb+httpserver+hb приложение работают на одну базу
Sergy: SergKis пишет: Share_Tables = 1 для меня основной, т.к. letodb+httpserver+hb приложение работают на одну базу Для меня тоже, но для одного кекса потребовалось одновременно запустить на одну базу две разных программы, время от времени требующим монопольный доступ. И если Leto+Leto работает, DBFxxx+DBFxxx работает, а вот Leto+DBFxxx - именно под Линуксом - не выходило. Это я к тому, что дело вовсе не в сырости версии форка как таковой: возникла специфическая задача, походу её решили и весьма нетривиальным способом.
Pasha: SergKis пишет: Share_Tables = 1 для меня основной, т.к. letodb+httpserver+hb приложение работают на одну базу Производительность без Share_Tables = 1 намного выше, чем с ним. Теряются преимущества работы с dbf в монопольном режиме, а они существенные. Если стороннему non-harbour приложению также надо иметь доступ к базам letodb, то это возможно организовать посредством ole-сервера, см. utils\olesrv Но это только для win-платформы
Sergy: Pasha пишет: Я даже несколько обескуражен результатом. Конечно, может быть новшества LetoDBf сыграют в каких-то других условиях, тест то больно простой. Интересно. Я тоже в одном месте был "обескуражен". Хотелось-бы понять: это особенность форка или в принципе, LetoDB. Рольф обиделся и в молчанку стал играть... Суть теста такова: открывается таблица без индекса и по ней делается большое количество GO INT(RAND(RECCOUNT())) [pre2]FUNC Main(cConnect, cDir, cFileName,nSkipBuffer) // IF Empty( cConnect ) .OR. (cConnect == ".") cConnect := "192.168.1.120:2812" ENDIF // IF Empty( cDir ) .OR. (cDir == ".") cDir := "w:\hb\data\" ENDIF // IF LEN(DIRECTORY(cDir+"*.*")) == 0 ? "Directory "+cDir+" is wrong" QUIT ENDIF // IF EMPTY(cFileName) .OR. (cFileName == ".") cFileName := "invcheck" ENDIF // IF EMPTY(nSkipBuffer) nSkipBuffer := 21 // by default ELSE nSkipBuffer := VAL(nSkipBuffer) IF EMPTY(nSkipBuffer) nSkipBuffer := 21 ENDIF ENDIF // ? "1) cConnect = ",cConnect ? "2) cDir = ",cDir ? "3) cFileName = ",cFileName ? "4) nSkipBuffer = ",hb_NTOS(nSkipBuffer) // IF FILE(cDir+cFileName+".dbf") ? "Table "+cDir+cFileName+".dbf is reachable locally. OK" ELSE ? "Table "+cDir+cFileName+".dbf is not reachable locally. QUIT" QUIT ENDIF // IF Leto_Connect(cConnect) >= 0 ? "LetoDBf - connect ok." Leto_ToggleZip(1) LETO_SETSKIPBUFFER( nSkipBuffer ) ELSE ? "LetoDbf - failed to connect. QUIT" QUIT ENDIF // IF Leto_File(cFileName+".dbf") LetoSpeedTest(cDir,cFileName,10000) ELSE ? "Leto_File('"+cFileName+".dbf') = FALSE" ENDIF ? ? "Press any key to exit" INKEY(0) // RETURN 0 * ---------------------------------------- * FUNC LetoSpeedTest(cWorkDir,cFileName,nSize) LOCAL nStart,nStop,i,aRecords // USE (cWorkDir+cFileName) INDEX (cWorkDir+cFileName) EXCLUSIVE NEW VIA "DBFNTX" IF NETERR() ? "DBFNTX - open error." RETURN .F. ELSE ? "Table "+cFileName+".dbf is opened, it has "+hb_NTOS(RECCOUNT())+" records,",; hb_NTOS(FileSize(cWorkDir+cFileName+".dbf") / (1024 * 1024))," MB" ? ENDIF // aRecords := ARRAY(nSize) FOR i:=1 TO nSize aRecords[ i ] := INT(RAND()*nSize) NEXT i // ? "Testing "+hb_NTOS(nSize)+" jumps via DBFNTX: " nStart := hb_Milliseconds() FOR i:=1 TO nSize GO aRecords[ i ] DoSomething() NEXT i nStop := hb_Milliseconds() // ?? STR(nStop-nStart,10),"ms, "+STR(nSize/(nStop-nStart)*1000,10,1)+" jumps/sec" CLOSE // USE (cFileName) INDEX (cFileName) EXCLUSIVE NEW VIA "LETO" IF NETERR() ? "LETO - open error." RETURN .F. ELSE ? "Testing "+hb_NTOS(nSize)+" jumps via LETO: " ENDIF nStart := hb_Milliseconds() FOR i:=1 TO nSize GO aRecords[ i ] DoSomething() NEXT i nStop := hb_Milliseconds() // ?? STR(nStop-nStart,10),"ms, "+STR(nSize/(nStop-nStart)*1000,10,1)+" jumps/sec" CLOSE // RETURN "done" * ----------------------------- * STATIC FUNC DoSomething() LOCAL x := FIELDGET(1),; y := FIELDGET(2) RETURN hb_ValToExp(x)+hb_ValToExp(y) * * * EOF is here...[/pre2] Компилировал вот так: letodb.hbc -W3 -es0 -n -mt hbct.hbc Будет несколько минут времени - прогони плиз его у себя на обоих вариантах: основном и форковском. Интересно сравнить. Может это LetoDB(f), а может у меня настройки какие-то кривые - все в общем летает, а тут - скорость в 40! раз ниже, чем у DBFNTX по сети.
Pasha: Я правильно понял, что этот тест LetoDBf прогоняет в 40 раз медленнее, чем LetoDB ? В любом случае, сразу можно сказать, что для GO INT(RAND(RECCOUNT())) skip buffer не помогает, а мешает. Вместо одной записи сервер передает клиенту 10, или что там в настройках. А они не нужны. Поэтому лучше перед такими goto задать leto_SetSkipBuffer(1). Ну а потом вернуть прежнее значение, потому что для обычных выборок эта настройка очень важна.
Sergy: Сорри, не в 40, а в 24 раза LetoDBf получается медленнее, чем DBFNTX по сети: [pre2] 1) cConnect = 192.168.1.120:2812 2) cDir = w:\hb\data\ 3) cFileName = invcheck 4) nSkipBuffer = 21 Table w:\hb\data\invcheck.dbf is reachable locally. OK LetoDBf - connect ok. Table invcheck.dbf is opened, it has 957046 records, 66.63 MB Testing 10000 jumps via DBFNTX: 221 ms, 45248.9 jumps/sec Testing 10000 jumps via LETO: 5347 ms, 1870.2 jumps/sec Press any key to exit[/pre2] SkipBuffer можно задать из командной строки, можно поправить в тексте программы. Менял и так и эдак - без особого прироста производительности.
Dima: Sergy пишет: DBFNTX по сети: А ежели не лень , сделай тест с CDX.
Sergy: Dima пишет: А ежели не лень , сделай тест с CDX. Индексов CDX у меня нет, от слова "совсем". Но делал без индексов, просто USE table EXCLUSIVE NEW - пофиг: в обоих случаях процентов на 10 быстрее, но в итоге: [pre2] Testing 10000 jumps via DBFNTX: 198 ms, 50505.1 jumps/sec (no index) Testing 10000 jumps via LETO: 5212 ms, 1918.6 jumps/sec (no index)[/pre2]
SergKis: Sergy Что покажет установка BM фильтра на массив RecNo() и обработка в цикле всех записей ?
Sergy: SergKis пишет: Что покажет установка BM фильтра на массив RecNo() и обработка в цикле всех записей ? Честно говоря, не знаю. У меня вопрос возник в одном, не слишком типичном месте: сначала идет выборка, собираются по некому сложному условию куча записей в массив RECNO(), а потом по ним идет DBEDIT(). После переключения данного фрагмента кода на LetoDBf юзеры (неожиданно), все как один, стали жаловаться на "тормоза": курсор переходил от записи к записи с задержкой около секунды. После того, как вернул работу на "стандартный" DBFNTX - тормоза исчезли, а я пытаюсь понять: что-же это такое могло быть. Перекомпилировать сервер под BMDBFNTX нет особого смысла: я уже изменил логику в этом месте программы полностью, отказавшись от массива RECNO() в пользу локальной таблицы с выбранными данными. Работает и с LetoDBf и DBFNTX без тормозов вообще. Просто остался чисто спортивный интерес: что это было - ошибка в форке или у меня что-то не так настроено.
SergKis: Sergy пишет я уже изменил логику в этом месте программы полностью, отказавшись от массива RECNO() в пользу локальной таблицы с выбранными данными. с изменением алгоритма все понятно, а с массивом recno(), BM filtra на сервере, ясности нет Перекомпилировать сервер под BMDBFNTX нет особого смысла Так и сборка с __BM = Yes, как говорится, "есть не просит", а без нее не попробуешь
PSP: Вот хоть стреляйте меня, но я утверждаю, что Letodb показывает свои примущества только в случае обработки запросов с помощью udf-функций (эдакий псевдо sql-сервер с произвольно-самопальным синктасисом)))). В остальных случаях всё зависит от сетевого оборудования/соединения и дисковой системы сервера. На гигабитной сетке или, если на серваке raid-10, может случиться так, что обычный файловый режим будет быстрее.
SergKis: PSP пишет свои примущества только в случае обработки запросов с помощью udf-функций Так и не спорим об этом. Перенос деиствий на сторону сервера требует опр. затрат., написания кода ... На первом этапе, мин. телодвижениями, надо встроить летодб в старый код, не проиграв сильно в скорости. Если был массив recno(), наверно надо применить BM фильтр, был SET FILTER TO ... сделать его оптимистическим, ... В "нашей" версии есть простой механизм для работы на сервере, заменяя SET FILTER TO ...[pre2] leto_ParseRecords( leto_Udf('UDF_dbEval', <xScope>, <xScopeBottom>, <xOrder>, <cFilter>, <lDeleted> ) ) while ! eof() ... skip enddo dbInfo( DBI_CLEARBUFFER ) [/pre2] Для меня, к примеру, 180 сек или 120 сек без разницы (клиенту в большинстве тоже, он так и так не успеет кофе попить), 15 минут и 5 мин. есть разница.
Sergy: PSP пишет: Вот хоть стреляйте меня, но я утверждаю, что Letodb показывает свои примущества только в случае обработки запросов с помощью udf-функций (эдакий псевдо sql-сервер с произвольно-самопальным синктасисом)))). В остальных случаях всё зависит от сетевого оборудования/соединения и дисковой системы сервера. На гигабитной сетке или, если на серваке raid-10, может случиться так, что обычный файловый режим будет быстрее. Не очень понятно, какая разница - как именно будут выбраны записи: при помощи UDF функции или при помощи server-side простейшего фильтра. Самое главное, что во время этой выборки - на клиент попадет то и только то, что требуется, ничего лишнего: ни неподходящих по условию записей, ни страниц из индексных файлов, необходимых, чтобы выбрать эти самые записи. Ничего. Только запрошенные данные. И совершенно понятно, что в определенных условиях, например, при наличии 2х1Gb сетки, быстрого диска и тп можно в теории получить аналогичный результат. Но что будет с этой сеткой, если будет хотя-бы десяток юзеров, гоняющих туда-сюда гигабайтные таблицы? А если юзеров больше? А если канал - не локальная сеть, а интернет? А конкретно LetoDB(f) тут вообще ни причем. Просто удобный движок для ленивых талантливых программистов, написавших много (ооочень много?) лет назад удачный код, который оказался актуален до сих пор. И второй момент: безопасность/целостность данных. Пофиг даже на скорость. Гораздо правильнее, когда в данные не лезет 10-50-100 разных машин с вирусами/шифровальщиками/битой_памятью/плохо_обжатыми_коннекторами/высохшими_аккумуляторами_ИБП/итп (тьфу*3). Есть сервер и на нем локальный диск. Один процесс оперирует всеми локальными данными, высылая по сети только РЕЗУЛЬТАТ. А уж будет это Oracle или MongoDB - тоже пофиг. Кому милее арбуз, а кому - свиной хрящик.
PSP: Sergy пишет: какая разница - как именно будут выбраны записи: при помощи UDF функции или при помощи server-side простейшего фильтра В таком случае, наверное, минимальная. Если фильтр возможно построить на стороне сервера. Если структура таблиц такова, что оптимизированный фильтр невозможно построить, то при использовании udf - это не проблема. Функции работатют с данными на стороне сервера полностью. Я имел в виду, что простая замена rdd вряд ли решит проблему скорости. Вы убедились на своем же примере. И второй момент: безопасность/целостность данных. Пофиг даже на скорость. Гораздо правильнее, когда в данные не лезет 10-50-100 разных машин с вирусами/шифровальщиками/битой_памятью/плохо_обжатыми_коннекторами/высохшими_аккумуляторами_ИБП/итп (тьфу*3). Есть сервер и на нем локальный диск. Один процесс оперирует всеми локальными данными, высылая по сети только РЕЗУЛЬТАТ. И чем тут udf не вписывается?)) зы. А так-то спорить тут не о чем. Каждый делает, как привык)
Pasha: Sergy пишет: Сорри, не в 40, а в 24 раза LetoDBf получается медленнее, чем DBFNTX по сети: Да, так и есть. Правда, я проверил с не с ntx, а с cdx, и не с letodbf, а с letodb, но разница получилась такого порядка. Причем локально разница меньше, в 8-9 раз. Думаю, что причину здесь уже разжевали, повторяться не буду.
Sergy: Спасибо за тест, значит дело не в форке и не кривых настройках у меня. Всё понятно, кроме этой фразы: Pasha пишет: Причем локально разница меньше, в 8-9 раз. Как это "локально разница меньше" ?
полная версия страницы