Отправлено: 31.01.08 11:36. Заголовок: Leto DB Server (продолжение)

Только что открыл на 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 на Харборе, ... и вообще все в наших руках :).

Кто хочет участвовать в разработке, тестировании - пишите.

 Отправлено: 04.06.10 07:55. Заголовок: Александр, наверное ..

цитата:

Александр, наверное еще в srvleto.h - USERSTRU надо добавить: USHORT uiVarsOwnCurr;

Точно, забыл этот файл переписать.

 Отправлено: 05.06.10 10:54. Заголовок: Вчера опять падало, ..

Вчера опять падало, 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 )
Бред какой то...

 Отправлено: 05.06.10 12:07. Заголовок: Александр, а как сде..

Александр, а как сделать, чтобы для выполнения функции leto_sum() создавался отдельный поток, и чтобы это работало в обеих харборах ?
Выполнение в отдельном потоке может понадобиться и для других потенциально тяжелых операций.

 Отправлено: 05.06.10 13:49. Заголовок: На досуге посмотрел ..

На досуге посмотрел почему по времени локально лето и CDX отличаются в 2 раза (не в пользу лето)
Половину времени занимает выполнение leto_SendAnswer()
Александр, как думаете с чем это связано? Почему так медленно? Все локально, т.е. аппаратная часть не влияет, дрова аналогично
Может перейти на асинхронный способ передачи?
(плюс непонятные падения сервера - стоит использовать thread safe? Полностью перейти на последний harbour с его MT? Я понимаю,
что Вы используете старую версию и вряд ли захотите влезать в проблемы перехода на новую версию, но может стоит попробовать?
У данного перехода есть плюс - можно, например, запускать несколько потоков для обслуживания либо разных подключений
либо таблиц. Т.е. равномерно распределять открываемые таблицы между потоками при большой загрузке)

 Отправлено: 05.06.10 14:14. Заголовок: Добавил для leto_sum..

Добавил для leto_sum возможность суммирования нескольких полей:

leto_sum("Sum1,Sum2", cFilter, cScopeTop, cScopeBottom) вернет массив значений {nSum1, nSum2}

Если в качестве имеени поля задать символ "#", будет расчитано количество записей в выборке
Для одного поля функция, как и раньше, возвращает числове значение - сумму.

 Отправлено: 07.06.10 09:13. Заголовок: Александр, а как сде..

цитата:

Александр, а как сделать, чтобы для выполнения функции leto_sum() создавался отдельный поток, и чтобы это работало в обеих харборах ?

цитата:

Полностью перейти на последний harbour с его MT?

Реализация дополнительных потоков Harbour-уровня мне не кажется реальной. Для этого потребуется переписывать ядро letodb целиком с тем,
чтобы сделать многопоточность на базе Harbour - реализации, а не на тех методах, что используются сейчас. Возможно ли при этом обеспечить
совместимость с xHarbour на С уровне - большой вопрос. Я не знакомился с особенностями реализации mt ни в Harbour, ни в xHarbour, но из общих
соображений мне это представляется более чем проблематичным.
Есть еще одна ( да не одна, наверное :) ) проблема. Я внимательно читал Харборовский мэйллист периода внедрения mt - Przemek особенно подчеркивал,
нельзя в параллельных потоках работать с одной таблицей. Если с тех пор ничего не изменилось, то реализация, например, leto_sum() в отдельном потоке
возможна лишь при открытии файла в exclusive режиме, что, в общем случае, неприемлемо.
Я изначально предполагал для "потенциально тяжелых операций" использовать отдельные процессы, именно поэтому в letodb включен механизм "shared memory",
но тут тоже не все просто, я пока не собрался приступить к этому поближе.

 Отправлено: 07.06.10 09:19. Заголовок: Вчера опять падало, ..

цитата:

Вчера опять падало, 3 раза (сервер вин2008)

Вот зараза!

цитата:

warning: Invalid parameter passed to C runtime function.

Может опять поставить ту проверку в hb_ip_rfd_set() ? Я ее убрал, решив что она уже не нужна ...

цитата:

Похоже только на одно место - server.prg (функция hs_opentable) cReply += leto_rec( nId, nUserStru ) Бред какой то...

Думаю, это случайность. Скорее всего, ошибка произошла во время выполнения параллельного потока.

 Отправлено: 07.06.10 09:36. Заголовок: alkresin пишет: Ест..

alkresin пишет:

цитата:

Есть еще одна ( да не одна, наверное :) ) проблема. Я внимательно читал Харборовский мэйллист периода внедрения mt - Przemek особенно подчеркивал, нельзя в параллельных потоках работать с одной таблицей. Если с тех пор ничего не изменилось, то реализация, например, leto_sum() в отдельном потоке возможна лишь при открытии файла в exclusive режиме, что, в общем случае, неприемлемо.

Я тоже учитывал этот момент, когда прокручивал алгоритм "в голове". Такой конфликт можно разрешить блокировкой отдельных таблиц на уровне leto. То есть, пока leto_sum не отработает, другой клиент "висит" на skip по этой же таблице, и наоборот. Это намного лучше, чем сейчас, когда все клиенты ждут, пока не завершится leto_sum.

 Отправлено: 07.06.10 09:37. Заголовок: На досуге посмотрел ..

цитата:

На досуге посмотрел почему по времени локально лето и CDX отличаются в 2 раза (не в пользу лето) Половину времени занимает выполнение leto_SendAnswer()

На локальной машине letodb в принципе должно быть медленнее dbfcdx - для выполнения каждой операции сервером выполняются те же
методы dbfcdx плюс затраты на прием команды и передачу ответа, а время выполнения tcp/ip приема/передачи ( на сервере + на клиенте )
вполне может быть сравнимо со временем выполнения некоторых RDD методов.

цитата:

Может перейти на асинхронный способ передачи?

Я не вижу, как это ускорит реакцию. Сервер и так, когда он не занят выполнением команды, ждет прихода новой и сразу берется за ее исполнение.
А на посылку ответа ( leto_SendAnswer() ) это вообще никак не повлияет.

Может, стоит поиграть настройками TCP/IP - как в hbip.c, так и на компьютере ...

 Отправлено: 07.06.10 10:02. Заголовок: К слову. По сети let..

К слову. По сети leto может превосходить dbfcdx по производительности в разы.
К примеру, я взял отчет, в котором выполнятся выборка из 3-х таблиц за большой промежуток времени. С dbfcdx он рассчитывался 75 сек, с letodb - 13 сек. Причем никакой отимизации для leto не делал, обьем данных, которые выбираются из таблиц - один к одному. А если еще применить клиент-серверные средства, ограничив обьем данных, передаваемых по сети, разница еще увеличится.
Это конечно не общий случай, но все-таки маленький факт.

 Отправлено: 07.06.10 10:34. Заголовок: alkresin пишет: нел..

alkresin пишет:

цитата:

нельзя в параллельных потоках работать с одной таблицей.

Не знаю как в xHarbour. В Harbour это сделано прозрачно на основе эмуляции XBase++. Передача таблицы между потоками:
HB_DBDETACH() и HB_DBREQUEST()
Можно без этого - просто распределять открываемые таблицы между потоками, быстрее отклик, лучше отзывчивость, например, в TbBrowse

цитата:

А на посылку ответа ( leto_SendAnswer() ) это вообще никак не повлияет

Это повлияет на скорость исполения команд, т.к. поток не будет ждать завершения отсылки ответа, он сразу примется за обработку следующей команды.

цитата:

На локальной машине letodb в принципе должно быть медленнее dbfcdx

Локальную машину я привел в пример для исключения влияния железа. Я знаю, что CDX медленнее по сети работает, но у меня есть результаты сравнения с ADS на тех же операциях (она по сети быстрее в 1.5-2 раза)

Вообще я не критикую лето, это для меня единственная альтернатива платной ADS
Я хочу ее развить (или, по крайней мере приблизить) до уровня ADS

 Отправлено: 07.06.10 11:03. Заголовок: Такой конфликт можн..

цитата:

Такой конфликт можно разрешить блокировкой отдельных таблиц на уровне leto. То есть, пока leto_sum не отработает, другой клиент "висит" на skip по этой же таблице, и наоборот.

цитата:

Не знаю как в xHarbour. В Harbour это сделано прозрачно на основе эмуляции XBase++. Передача таблицы между потоками: HB_DBDETACH() и HB_DBREQUEST() Можно без этого - просто распределять открываемые таблицы между потоками

Да, этот вопрос, наверное, можно решить. Но остается главный - переписать реализацию mt, да так, чтобы обеспечить совместимость Harbour с xHarbour на C уровне. На prg уровне это, наверное, сделать легче, но тогда придется и ядро letodb переводить на prg уровень, что приведет к общему снижению производительности. Я бы предпочел лучше попробовать с процессами.

 Отправлено: 07.06.10 11:08. Заголовок: Локальную машину я п..

цитата:

Локальную машину я привел в пример для исключения влияния железа. Я знаю, что CDX медленнее по сети работает, но у меня есть результаты сравнения с ADS на тех же операциях (она по сети быстрее в 1.5-2 раза) Вообще я не критикую лето, это для меня единственная альтернатива платной ADS

Да почему бы и не покритиковать ? :)
Что касается сравнения с ADS - я делал тесты года два назад, такой разницы не было, результаты были очень близки. В некоторых тестах ( на добавление записи ) letodb был даже заметно быстрее. Надо будет проверить еще раз.

 Отправлено: 07.06.10 11:47. Заголовок: alkresin пишет: рез..

alkresin пишет:

цитата:

результаты были очень близки. В некоторых тестах ( на добавление записи ) letodb был даже заметно быстрее

В тестах все красиво :)
В реальном приложении не очень.
Например:
частые открытия таблиц очень замедляют работу лето
ожидание завершения leto_SendAnswer() тормозит поток обработки команд, что и выливается в такое преимущество ADS. На самом
деле поток уже все сделал, только ждет отдачу ответа, хотя мог бы заняться чем то полезным :)

 Отправлено: 07.06.10 12:16. Заголовок: частые открытия табл..

цитата:

частые открытия таблиц очень замедляют работу лето

Тут мы вряд ли что-то можем сделать. Хотя... Можно попробовать закрывать таблицы не сразу, а через сколько-то минут, если за истекшее время их никто не откроет опять.

цитата:

ожидание завершения leto_SendAnswer() тормозит поток обработки команд

Вы уверены, что hb_ipSend() действительно занимает много времени ? Как вы это проверяли ? Если время выполнения hb_ipSend() настолько критично, можно было бы отдать его другому потоку ( а то и нескольким ) C-уровня.

 Отправлено: 07.06.10 12:20. Заголовок: alkresin пишет: Но ..

alkresin пишет:

цитата:

Но остается главный - переписать реализацию mt, да так, чтобы обеспечить совместимость Harbour с xHarbour на C уровне.

Можно резко упростить задачу, оставив поддержку letodb сервер только для Harbour и обрубив ее для xHarbour. А клиентскую часть оставить и для Harbour, и для xHarbour.
Я думаю, для пользователей xHarbour не составит большого труда собрать сервер с помощью Harbour, если станет известно, что сервер под Harbour работает лучше.

 Отправлено: 07.06.10 12:38. Заголовок: alkresin пишет: Тут..

alkresin пишет:

цитата:

Тут мы вряд ли что-то можем сделать. Хотя... Можно попробовать закрывать таблицы не сразу, а через сколько-то минут, если за истекшее время их никто не откроет опять.

Насколько влияет открытие таблицы в PRG от аналогичного на С-уровне? Время запуска VM-машины?

цитата:

Вы уверены, что hb_ipSend() действительно занимает много времени ? Как вы это проверяли ?

Замерял время (очень тупо - в начале функции и в конце)

Pasha пишет:

цитата:

оставив поддержку letodb сервер только для Harbour

Очень хороший вариант!

 Отправлено: 07.06.10 12:42. Заголовок: Можно резко упростит..

цитата:

Можно резко упростить задачу, оставив поддержку letodb сервер только для Harbour и обрубив ее для xHarbour. А клиентскую часть оставить и для Harbour, и для xHarbour.

В принципе, можно. А в Harbour есть API для mt на C уровне ?

 Отправлено: 07.06.10 14:52. Заголовок: alkresin пишет: А в..

alkresin пишет:

цитата:

А в Harbour есть API для mt на C уровне ?

Скорее всего есть
Судя по наличию hbthread.h должен быть

 Отправлено: 07.06.10 15:09. Заголовок: Pasha пишет: Можно ..

Pasha пишет:

цитата:

Можно резко упростить задачу, оставив поддержку letodb сервер только для Harbour и обрубив ее для xHarbour. А клиентскую часть оставить и для Harbour, и для xHarbour. Я думаю, для пользователей xHarbour не составит большого труда собрать сервер с помощью Harbour, если станет известно, что сервер под Harbour работает лучше.

А как тогда добавлять свои функции на хХарборе в СЕРВЕР leto_db ? Переписывать на Харборе ?