Форум » LetoDB, HbNetio. » Leto DB Server (продолжение) » Ответить
Leto DB Server (продолжение)
alkresin: Только что открыл на Sourceforge новый проект - Leto DB Server - https://sourceforge.net/projects/letodb Это мультиплатформенный ( Windows, Unix/Linux ) сервер баз данных, предоставляющий клиентским программам доступ к dbf/cdx файлам, находящимся на удаленном сервере ( можно и на локальном компьютере запускать - в отладочных целях ). В общем, как ADS :). Проект - на стадии разработки, не все даже базовые функции еще реализованы, до оптимизации дело еще не дошло. Но работает :). Крутится у меня на сервере несколько дней, подключал до 15 клиентов, пока не падает. Мои программы работают с ним нормально. Преимущества по сравнению с обычным файл-сервером: 1) Безопасность - базы могут быть в каталоге, недоступном для клиентских компьютеров - никто их случайно не удалит и не повредит. 2) Поскольку базы открываются серверной программой, а не клиентской, ее целостности ничего не грозит при случайном отключении клиентского компьютера. 3) значительное уменьшение сетевого траффика. 4) Должен быть, по идее, выигрыш в скорости. 5) Возможность контроля за пользователями с помощью утилиты manage ( можно придумать и другие формы контроля ). 6) Можно будет сделать транзакции, stored procedures на Харборе, ... и вообще все в наших руках :). Кто хочет участвовать в разработке, тестировании - пишите.
alkresin: Александр, наверное еще в srvleto.h - USERSTRU надо добавить: USHORT uiVarsOwnCurr; Точно, забыл этот файл переписать.
alx_on: Вчера опять падало, 3 раза (сервер вин2008) Все три раза так: (gdb) Starting program: D:\letodb.exe [New Thread 912.0x864] [New Thread 912.0x96c] warning: Invalid parameter passed to C runtime function. warning: Invalid parameter passed to C runtime function. В двух случаях в логах ничего нет, только выходит предупреждение винды На третий в логе странная запись: 06/04/10 15:49:17: Error BASE/1081 Argument error: + Arguments: ( [ 1] = Type: C Val: +6707;0;23;ACCNAME;C;100;0;ACC;C;9;0;CTYPE;N;1;0;GROUP;N;2;0;DOCDEB;C;250;0;DOCKRED;C;250;0;TSALDO;N;1;0;KEYF1;C;6;0;KEYF2;C;6;0;KEYF3;C;6;0;STYPE;N;1;0;INDEPEND;L;1;0;PRICE;N;1;0;ATYPE;L;1;0;KGU;L;1;0;PREDOK;C;12;0;RECCODE;C;12;0;TYPE;L;1;0;KGUDEBET;C;6;0;KGUKREDIT;C;6;0;GRKBK;N;2;0;ACCKF;C;6;0;LDOG;L;1;0;6;accnt;ACCNT;FIELD->ACC;;C;9;accnt;GRP;IF(TYPE,"1","0")+STRZERO( FIELD->GROUP, 2 );;C;3;accnt;GRPACC;IF(TYPE,"1","0")+STRZERO( FIELD->GROUP, 2 ) + FIELD->ACC;;C;12;accnt;SELECT;IF(TYPE,"1","0");;C;1;accnt;PREDOK;FIELD->PREDOK;;C;12;accnt;ACCKF;FIELD->ACCKF;;C;6;, [ 2] = Type: N Val: 0) Похоже только на одно место - server.prg (функция hs_opentable) cReply += leto_rec( nId, nUserStru ) Бред какой то...
Pasha: Александр, а как сделать, чтобы для выполнения функции leto_sum() создавался отдельный поток, и чтобы это работало в обеих харборах ? Выполнение в отдельном потоке может понадобиться и для других потенциально тяжелых операций.
alx_on: На досуге посмотрел почему по времени локально лето и CDX отличаются в 2 раза (не в пользу лето) Половину времени занимает выполнение leto_SendAnswer() Александр, как думаете с чем это связано? Почему так медленно? Все локально, т.е. аппаратная часть не влияет, дрова аналогично Может перейти на асинхронный способ передачи? (плюс непонятные падения сервера - стоит использовать thread safe? Полностью перейти на последний harbour с его MT? Я понимаю, что Вы используете старую версию и вряд ли захотите влезать в проблемы перехода на новую версию, но может стоит попробовать? У данного перехода есть плюс - можно, например, запускать несколько потоков для обслуживания либо разных подключений либо таблиц. Т.е. равномерно распределять открываемые таблицы между потоками при большой загрузке)
Pasha: Добавил для leto_sum возможность суммирования нескольких полей: leto_sum("Sum1,Sum2", cFilter, cScopeTop, cScopeBottom) вернет массив значений {nSum1, nSum2} Если в качестве имеени поля задать символ "#", будет расчитано количество записей в выборке Для одного поля функция, как и раньше, возвращает числове значение - сумму.
alkresin: Александр, а как сделать, чтобы для выполнения функции leto_sum() создавался отдельный поток, и чтобы это работало в обеих харборах ? Полностью перейти на последний harbour с его MT? Реализация дополнительных потоков Harbour-уровня мне не кажется реальной. Для этого потребуется переписывать ядро letodb целиком с тем, чтобы сделать многопоточность на базе Harbour - реализации, а не на тех методах, что используются сейчас. Возможно ли при этом обеспечить совместимость с xHarbour на С уровне - большой вопрос. Я не знакомился с особенностями реализации mt ни в Harbour, ни в xHarbour, но из общих соображений мне это представляется более чем проблематичным. Есть еще одна ( да не одна, наверное :) ) проблема. Я внимательно читал Харборовский мэйллист периода внедрения mt - Przemek особенно подчеркивал, нельзя в параллельных потоках работать с одной таблицей. Если с тех пор ничего не изменилось, то реализация, например, leto_sum() в отдельном потоке возможна лишь при открытии файла в exclusive режиме, что, в общем случае, неприемлемо. Я изначально предполагал для "потенциально тяжелых операций" использовать отдельные процессы, именно поэтому в letodb включен механизм "shared memory", но тут тоже не все просто, я пока не собрался приступить к этому поближе.
alkresin: Вчера опять падало, 3 раза (сервер вин2008) Вот зараза! warning: Invalid parameter passed to C runtime function. Может опять поставить ту проверку в hb_ip_rfd_set() ? Я ее убрал, решив что она уже не нужна ... Похоже только на одно место - server.prg (функция hs_opentable) cReply += leto_rec( nId, nUserStru ) Бред какой то... Думаю, это случайность. Скорее всего, ошибка произошла во время выполнения параллельного потока.
Pasha: alkresin пишет: Есть еще одна ( да не одна, наверное :) ) проблема. Я внимательно читал Харборовский мэйллист периода внедрения mt - Przemek особенно подчеркивал, нельзя в параллельных потоках работать с одной таблицей. Если с тех пор ничего не изменилось, то реализация, например, leto_sum() в отдельном потоке возможна лишь при открытии файла в exclusive режиме, что, в общем случае, неприемлемо. Я тоже учитывал этот момент, когда прокручивал алгоритм "в голове". Такой конфликт можно разрешить блокировкой отдельных таблиц на уровне leto. То есть, пока leto_sum не отработает, другой клиент "висит" на skip по этой же таблице, и наоборот. Это намного лучше, чем сейчас, когда все клиенты ждут, пока не завершится leto_sum.
alkresin: На досуге посмотрел почему по времени локально лето и CDX отличаются в 2 раза (не в пользу лето) Половину времени занимает выполнение leto_SendAnswer() На локальной машине letodb в принципе должно быть медленнее dbfcdx - для выполнения каждой операции сервером выполняются те же методы dbfcdx плюс затраты на прием команды и передачу ответа, а время выполнения tcp/ip приема/передачи ( на сервере + на клиенте ) вполне может быть сравнимо со временем выполнения некоторых RDD методов. Может перейти на асинхронный способ передачи? Я не вижу, как это ускорит реакцию. Сервер и так, когда он не занят выполнением команды, ждет прихода новой и сразу берется за ее исполнение. А на посылку ответа ( leto_SendAnswer() ) это вообще никак не повлияет. Может, стоит поиграть настройками TCP/IP - как в hbip.c, так и на компьютере ...
Pasha: К слову. По сети leto может превосходить dbfcdx по производительности в разы. К примеру, я взял отчет, в котором выполнятся выборка из 3-х таблиц за большой промежуток времени. С dbfcdx он рассчитывался 75 сек, с letodb - 13 сек. Причем никакой отимизации для leto не делал, обьем данных, которые выбираются из таблиц - один к одному. А если еще применить клиент-серверные средства, ограничив обьем данных, передаваемых по сети, разница еще увеличится. Это конечно не общий случай, но все-таки маленький факт.
alx_on: alkresin пишет: нельзя в параллельных потоках работать с одной таблицей. Не знаю как в xHarbour. В Harbour это сделано прозрачно на основе эмуляции XBase++. Передача таблицы между потоками: HB_DBDETACH() и HB_DBREQUEST() Можно без этого - просто распределять открываемые таблицы между потоками, быстрее отклик, лучше отзывчивость, например, в TbBrowse А на посылку ответа ( leto_SendAnswer() ) это вообще никак не повлияет Это повлияет на скорость исполения команд, т.к. поток не будет ждать завершения отсылки ответа, он сразу примется за обработку следующей команды. На локальной машине letodb в принципе должно быть медленнее dbfcdx Локальную машину я привел в пример для исключения влияния железа. Я знаю, что CDX медленнее по сети работает, но у меня есть результаты сравнения с ADS на тех же операциях (она по сети быстрее в 1.5-2 раза) Вообще я не критикую лето, это для меня единственная альтернатива платной ADS Я хочу ее развить (или, по крайней мере приблизить) до уровня ADS
alkresin: Такой конфликт можно разрешить блокировкой отдельных таблиц на уровне leto. То есть, пока leto_sum не отработает, другой клиент "висит" на skip по этой же таблице, и наоборот. Не знаю как в xHarbour. В Harbour это сделано прозрачно на основе эмуляции XBase++. Передача таблицы между потоками: HB_DBDETACH() и HB_DBREQUEST() Можно без этого - просто распределять открываемые таблицы между потоками Да, этот вопрос, наверное, можно решить. Но остается главный - переписать реализацию mt, да так, чтобы обеспечить совместимость Harbour с xHarbour на C уровне. На prg уровне это, наверное, сделать легче, но тогда придется и ядро letodb переводить на prg уровень, что приведет к общему снижению производительности. Я бы предпочел лучше попробовать с процессами.
alkresin: Локальную машину я привел в пример для исключения влияния железа. Я знаю, что CDX медленнее по сети работает, но у меня есть результаты сравнения с ADS на тех же операциях (она по сети быстрее в 1.5-2 раза) Вообще я не критикую лето, это для меня единственная альтернатива платной ADS Да почему бы и не покритиковать ? :) Что касается сравнения с ADS - я делал тесты года два назад, такой разницы не было, результаты были очень близки. В некоторых тестах ( на добавление записи ) letodb был даже заметно быстрее. Надо будет проверить еще раз.
alx_on: alkresin пишет: результаты были очень близки. В некоторых тестах ( на добавление записи ) letodb был даже заметно быстрее В тестах все красиво :) В реальном приложении не очень. Например: частые открытия таблиц очень замедляют работу лето ожидание завершения leto_SendAnswer() тормозит поток обработки команд, что и выливается в такое преимущество ADS. На самом деле поток уже все сделал, только ждет отдачу ответа, хотя мог бы заняться чем то полезным :)
alkresin: частые открытия таблиц очень замедляют работу лето Тут мы вряд ли что-то можем сделать. Хотя... Можно попробовать закрывать таблицы не сразу, а через сколько-то минут, если за истекшее время их никто не откроет опять. ожидание завершения leto_SendAnswer() тормозит поток обработки команд Вы уверены, что hb_ipSend() действительно занимает много времени ? Как вы это проверяли ? Если время выполнения hb_ipSend() настолько критично, можно было бы отдать его другому потоку ( а то и нескольким ) C-уровня.
Pasha: alkresin пишет: Но остается главный - переписать реализацию mt, да так, чтобы обеспечить совместимость Harbour с xHarbour на C уровне. Можно резко упростить задачу, оставив поддержку letodb сервер только для Harbour и обрубив ее для xHarbour. А клиентскую часть оставить и для Harbour, и для xHarbour. Я думаю, для пользователей xHarbour не составит большого труда собрать сервер с помощью Harbour, если станет известно, что сервер под Harbour работает лучше.
alx_on: alkresin пишет: Тут мы вряд ли что-то можем сделать. Хотя... Можно попробовать закрывать таблицы не сразу, а через сколько-то минут, если за истекшее время их никто не откроет опять. Насколько влияет открытие таблицы в PRG от аналогичного на С-уровне? Время запуска VM-машины? Вы уверены, что hb_ipSend() действительно занимает много времени ? Как вы это проверяли ? Замерял время (очень тупо - в начале функции и в конце) Pasha пишет: оставив поддержку letodb сервер только для Harbour Очень хороший вариант!
alkresin: Можно резко упростить задачу, оставив поддержку letodb сервер только для Harbour и обрубив ее для xHarbour. А клиентскую часть оставить и для Harbour, и для xHarbour. В принципе, можно. А в Harbour есть API для mt на C уровне ?
alx_on: alkresin пишет: А в Harbour есть API для mt на C уровне ? Скорее всего есть Судя по наличию hbthread.h должен быть
Andrey: Pasha пишет: Можно резко упростить задачу, оставив поддержку letodb сервер только для Harbour и обрубив ее для xHarbour. А клиентскую часть оставить и для Harbour, и для xHarbour. Я думаю, для пользователей xHarbour не составит большого труда собрать сервер с помощью Harbour, если станет известно, что сервер под Harbour работает лучше. А как тогда добавлять свои функции на хХарборе в СЕРВЕР leto_db ? Переписывать на Харборе ?
полная версия страницы