Автор | Сообщение |
|
| постоянный участник
|
Пост N: 1362
Зарегистрирован: 27.01.07
|
|
Отправлено: 21.01.18 10:31. Заголовок: LetoDb fork
|
|
|
Ответов - 125
, стр:
1
2
3
4
5
6
7
All
[только новые]
|
|
|
| постоянный участник
|
Пост N: 1374
Зарегистрирован: 27.01.07
|
|
Отправлено: 16.02.18 12:04. Заголовок: SergKis пишет: Судя..
SergKis пишет: цитата: | Судя по Changelog.txt сборки пекутся как пирожки, т.е. сыровато еще состояние |
| Согласен. Поэтому и не спешу искать)
|
|
|
|
| |
Пост N: 602
Зарегистрирован: 08.07.06
|
|
Отправлено: 16.02.18 13:10. Заголовок: SergKis пишет: Судя..
SergKis пишет: цитата: | Судя по Changelog.txt сборки пекутся как пирожки, т.е. сыровато еще состояние |
| Не собираюсь никого защищать, но с лета-осени 2017г никаких существенных для программиста изменений не было. Насколько мой английский мне позволяет понять ситуацию - Рольф закусился с Linux/SMB сервером: там обнаружился странный косяк: два приложения (сервер Leto и обычная программа на DBFCDX/DBFNTX) пытаются в монопольном режиме получить доступ к файлу и оба... успешно его получают. Судя по переписке в форуме - похоже что решил.
|
|
|
|
| постоянный участник
|
Пост N: 1749
Зарегистрирован: 17.02.12
|
|
Отправлено: 16.02.18 14:00. Заголовок: Sergy пишет Не собир..
Sergy пишет цитата: | Не собираюсь никого защищать, но с лета-осени 2017г никаких существенных для программиста изменений не было. |
| Так я и не нападаю, надо пробовать в тестовом режиме, если видны плюсы перехода. Для себя, пока, не вижу необходимости переходить, хотя режим No_Save_WA = 1 интересует в letoDB, но руки не доходят.
|
|
|
|
| постоянный участник
|
Пост N: 1750
Зарегистрирован: 17.02.12
|
|
Отправлено: 16.02.18 14:04. Заголовок: Sergy пишет там обна..
Sergy пишет цитата: | там обнаружился странный косяк: два приложения (сервер Leto и обычная программа на DBFCDX/DBFNTX) пытаются в монопольном режиме получить доступ к файлу и оба... успешно его получают |
| Share_Tables = 1 для меня основной, т.к. letodb+httpserver+hb приложение работают на одну базу
|
|
|
|
| |
Пост N: 603
Зарегистрирован: 08.07.06
|
|
Отправлено: 16.02.18 17:27. Заголовок: SergKis пишет: Shar..
SergKis пишет: цитата: | Share_Tables = 1 для меня основной, т.к. letodb+httpserver+hb приложение работают на одну базу |
| Для меня тоже, но для одного кекса потребовалось одновременно запустить на одну базу две разных программы, время от времени требующим монопольный доступ. И если Leto+Leto работает, DBFxxx+DBFxxx работает, а вот Leto+DBFxxx - именно под Линуксом - не выходило. Это я к тому, что дело вовсе не в сырости версии форка как таковой: возникла специфическая задача, походу её решили и весьма нетривиальным способом.
|
|
|
|
| Администратор
|
Пост N: 3686
Зарегистрирован: 23.05.05
|
|
Отправлено: 17.02.18 11:51. Заголовок: SergKis пишет: Shar..
SergKis пишет: цитата: | Share_Tables = 1 для меня основной, т.к. letodb+httpserver+hb приложение работают на одну базу |
| Производительность без Share_Tables = 1 намного выше, чем с ним. Теряются преимущества работы с dbf в монопольном режиме, а они существенные. Если стороннему non-harbour приложению также надо иметь доступ к базам letodb, то это возможно организовать посредством ole-сервера, см. utils\olesrv Но это только для win-платформы
|
|
|
|
| |
Пост N: 605
Зарегистрирован: 08.07.06
|
|
Отправлено: 17.02.18 13:12. Заголовок: Pasha пишет: Я даже..
Pasha пишет: цитата: | Я даже несколько обескуражен результатом. Конечно, может быть новшества LetoDBf сыграют в каких-то других условиях, тест то больно простой. |
| Интересно. Я тоже в одном месте был "обескуражен". Хотелось-бы понять: это особенность форка или в принципе, LetoDB. Рольф обиделся и в молчанку стал играть... Суть теста такова: открывается таблица без индекса и по ней делается большое количество GO INT(RAND(RECCOUNT())) Скрытый текст
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...
| Компилировал вот так: letodb.hbc -W3 -es0 -n -mt hbct.hbc Будет несколько минут времени - прогони плиз его у себя на обоих вариантах: основном и форковском. Интересно сравнить. Может это LetoDB(f), а может у меня настройки какие-то кривые - все в общем летает, а тут - скорость в 40! раз ниже, чем у DBFNTX по сети.
|
|
|
|
| Администратор
|
Пост N: 3687
Зарегистрирован: 23.05.05
|
|
Отправлено: 17.02.18 13:32. Заголовок: Я правильно понял, ч..
Я правильно понял, что этот тест LetoDBf прогоняет в 40 раз медленнее, чем LetoDB ? В любом случае, сразу можно сказать, что для GO INT(RAND(RECCOUNT())) skip buffer не помогает, а мешает. Вместо одной записи сервер передает клиенту 10, или что там в настройках. А они не нужны. Поэтому лучше перед такими goto задать leto_SetSkipBuffer(1). Ну а потом вернуть прежнее значение, потому что для обычных выборок эта настройка очень важна.
|
|
|
|
| |
Пост N: 606
Зарегистрирован: 08.07.06
|
|
Отправлено: 17.02.18 15:07. Заголовок: Сорри, не в 40, а в ..
Сорри, не в 40, а в 24 раза LetoDBf получается медленнее, чем DBFNTX по сети: 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 SkipBuffer можно задать из командной строки, можно поправить в тексте программы. Менял и так и эдак - без особого прироста производительности.
|
|
|
|
| |
Пост N: 6729
Зарегистрирован: 17.05.05
|
|
Отправлено: 17.02.18 15:35. Заголовок: Sergy пишет: DBFNTX..
Sergy пишет: А ежели не лень , сделай тест с CDX.
|
|
|
|
| |
Пост N: 607
Зарегистрирован: 08.07.06
|
|
Отправлено: 17.02.18 15:48. Заголовок: Dima пишет: А ежел..
Dima пишет: цитата: | А ежели не лень , сделай тест с CDX. |
| Индексов CDX у меня нет, от слова "совсем". Но делал без индексов, просто USE table EXCLUSIVE NEW - пофиг: в обоих случаях процентов на 10 быстрее, но в итоге: 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)
|
|
|
|
|
| постоянный участник
|
Пост N: 1753
Зарегистрирован: 17.02.12
|
|
Отправлено: 17.02.18 16:04. Заголовок: Sergy Что покажет у..
Sergy Что покажет установка BM фильтра на массив RecNo() и обработка в цикле всех записей ?
|
|
|
|
| |
Пост N: 608
Зарегистрирован: 08.07.06
|
|
Отправлено: 17.02.18 16:25. Заголовок: SergKis пишет: Что ..
SergKis пишет: цитата: | Что покажет установка BM фильтра на массив RecNo() и обработка в цикле всех записей ? |
| Честно говоря, не знаю. У меня вопрос возник в одном, не слишком типичном месте: сначала идет выборка, собираются по некому сложному условию куча записей в массив RECNO(), а потом по ним идет DBEDIT(). После переключения данного фрагмента кода на LetoDBf юзеры (неожиданно), все как один, стали жаловаться на "тормоза": курсор переходил от записи к записи с задержкой около секунды. После того, как вернул работу на "стандартный" DBFNTX - тормоза исчезли, а я пытаюсь понять: что-же это такое могло быть. Перекомпилировать сервер под BMDBFNTX нет особого смысла: я уже изменил логику в этом месте программы полностью, отказавшись от массива RECNO() в пользу локальной таблицы с выбранными данными. Работает и с LetoDBf и DBFNTX без тормозов вообще. Просто остался чисто спортивный интерес: что это было - ошибка в форке или у меня что-то не так настроено.
|
|
|
|
| постоянный участник
|
Пост N: 1754
Зарегистрирован: 17.02.12
|
|
Отправлено: 17.02.18 17:11. Заголовок: Sergy пишет я уже из..
Sergy пишет цитата: | я уже изменил логику в этом месте программы полностью, отказавшись от массива RECNO() в пользу локальной таблицы с выбранными данными. |
| с изменением алгоритма все понятно, а с массивом recno(), BM filtra на сервере, ясности нет цитата: | Перекомпилировать сервер под BMDBFNTX нет особого смысла |
| Так и сборка с __BM = Yes, как говорится, "есть не просит", а без нее не попробуешь
|
|
|
|
| постоянный участник
|
Пост N: 1377
Зарегистрирован: 27.01.07
|
|
Отправлено: 17.02.18 19:36. Заголовок: Вот хоть стреляйте м..
Вот хоть стреляйте меня, но я утверждаю, что Letodb показывает свои примущества только в случае обработки запросов с помощью udf-функций (эдакий псевдо sql-сервер с произвольно-самопальным синктасисом)))). В остальных случаях всё зависит от сетевого оборудования/соединения и дисковой системы сервера. На гигабитной сетке или, если на серваке raid-10, может случиться так, что обычный файловый режим будет быстрее.
|
|
|
|
| постоянный участник
|
Пост N: 1755
Зарегистрирован: 17.02.12
|
|
Отправлено: 17.02.18 21:07. Заголовок: PSP пишет свои приму..
PSP пишет цитата: | свои примущества только в случае обработки запросов с помощью udf-функций |
| Так и не спорим об этом. Перенос деиствий на сторону сервера требует опр. затрат., написания кода ... На первом этапе, мин. телодвижениями, надо встроить летодб в старый код, не проиграв сильно в скорости. Если был массив recno(), наверно надо применить BM фильтр, был SET FILTER TO ... сделать его оптимистическим, ... В "нашей" версии есть простой механизм для работы на сервере, заменяя SET FILTER TO ... leto_ParseRecords( leto_Udf('UDF_dbEval', <xScope>, <xScopeBottom>, <xOrder>, <cFilter>, <lDeleted> ) ) while ! eof() ... skip enddo dbInfo( DBI_CLEARBUFFER ) Для меня, к примеру, 180 сек или 120 сек без разницы (клиенту в большинстве тоже, он так и так не успеет кофе попить), 15 минут и 5 мин. есть разница.
|
|
|
|
| |
Пост N: 609
Зарегистрирован: 08.07.06
|
|
Отправлено: 17.02.18 22:26. Заголовок: PSP пишет: Вот хоть..
PSP пишет: цитата: | Вот хоть стреляйте меня, но я утверждаю, что Letodb показывает свои примущества только в случае обработки запросов с помощью udf-функций (эдакий псевдо sql-сервер с произвольно-самопальным синктасисом)))). В остальных случаях всё зависит от сетевого оборудования/соединения и дисковой системы сервера. На гигабитной сетке или, если на серваке raid-10, может случиться так, что обычный файловый режим будет быстрее. |
| Не очень понятно, какая разница - как именно будут выбраны записи: при помощи UDF функции или при помощи server-side простейшего фильтра. Самое главное, что во время этой выборки - на клиент попадет то и только то, что требуется, ничего лишнего: ни неподходящих по условию записей, ни страниц из индексных файлов, необходимых, чтобы выбрать эти самые записи. Ничего. Только запрошенные данные. И совершенно понятно, что в определенных условиях, например, при наличии 2х1Gb сетки, быстрого диска и тп можно в теории получить аналогичный результат. Но что будет с этой сеткой, если будет хотя-бы десяток юзеров, гоняющих туда-сюда гигабайтные таблицы? А если юзеров больше? А если канал - не локальная сеть, а интернет? А конкретно LetoDB(f) тут вообще ни причем. Просто удобный движок для ленивых талантливых программистов, написавших много (ооочень много?) лет назад удачный код, который оказался актуален до сих пор. И второй момент: безопасность/целостность данных. Пофиг даже на скорость. Гораздо правильнее, когда в данные не лезет 10-50-100 разных машин с вирусами/шифровальщиками/битой_памятью/плохо_обжатыми_коннекторами/высохшими_аккумуляторами_ИБП/итп (тьфу*3). Есть сервер и на нем локальный диск. Один процесс оперирует всеми локальными данными, высылая по сети только РЕЗУЛЬТАТ. А уж будет это Oracle или MongoDB - тоже пофиг. Кому милее арбуз, а кому - свиной хрящик.
|
|
|
|
| постоянный участник
|
Пост N: 1378
Зарегистрирован: 27.01.07
|
|
Отправлено: 18.02.18 08:16. Заголовок: Sergy пишет: какая ..
Sergy пишет: цитата: | какая разница - как именно будут выбраны записи: при помощи UDF функции или при помощи server-side простейшего фильтра |
| В таком случае, наверное, минимальная. Если фильтр возможно построить на стороне сервера. Если структура таблиц такова, что оптимизированный фильтр невозможно построить, то при использовании udf - это не проблема. Функции работатют с данными на стороне сервера полностью. Я имел в виду, что простая замена rdd вряд ли решит проблему скорости. Вы убедились на своем же примере. цитата: | И второй момент: безопасность/целостность данных. Пофиг даже на скорость. Гораздо правильнее, когда в данные не лезет 10-50-100 разных машин с вирусами/шифровальщиками/битой_памятью/плохо_обжатыми_коннекторами/высохшими_аккумуляторами_ИБП/итп (тьфу*3). Есть сервер и на нем локальный диск. Один процесс оперирует всеми локальными данными, высылая по сети только РЕЗУЛЬТАТ. |
| И чем тут udf не вписывается?)) зы. А так-то спорить тут не о чем. Каждый делает, как привык)
|
|
|
|
| Администратор
|
Пост N: 3689
Зарегистрирован: 23.05.05
|
|
Отправлено: 19.02.18 09:33. Заголовок: Sergy пишет: Сорри,..
Sergy пишет: цитата: | Сорри, не в 40, а в 24 раза LetoDBf получается медленнее, чем DBFNTX по сети: |
| Да, так и есть. Правда, я проверил с не с ntx, а с cdx, и не с letodbf, а с letodb, но разница получилась такого порядка. Причем локально разница меньше, в 8-9 раз. Думаю, что причину здесь уже разжевали, повторяться не буду.
|
|
|
|
| |
Пост N: 611
Зарегистрирован: 08.07.06
|
|
Отправлено: 19.02.18 13:36. Заголовок: Спасибо за тест, всё..
Спасибо за тест, значит дело не в форке и не кривых настройках у меня. Всё понятно, кроме этой фразы: Pasha пишет: цитата: | Причем локально разница меньше, в 8-9 раз. |
| Как это "локально разница меньше" ?
|
|
|
Ответов - 125
, стр:
1
2
3
4
5
6
7
All
[только новые]
|
|