Отправлено: 03.04.10 20:51. Заголовок: Помогите протестировать первую xHarbour систему

Уважаемые профи!

Наконец перевёл систему на xHarbour (терминальный режим). Если не сложно помогите найти ошибки в её работе (сам уже тестил). Если есть желание, то с удовольствием приму критику в любом виде и отвечу на все вопросы. Система содержит исходный код (+ база очень крупной оптовки за 4 месяца) и варианты Clipper (нужна настройка ОС) и xHarbour (Win32) программ. Для установки скачать в любой каталог и распаковать архив. Все виды паролей - 11. Для создания индексов clipper (s_repair.bat), harbour (srepharb.bat). Справка F1 в любом режиме, инструкции в каталоге document. Для принудительного запуска st.bat (clip)/sth.bat (harb). По системе печати, если интересно - отдельно. Состав комплекса:
1. Оперативная программа. ls.exe (clip)/hls.exe (harb)
2. Администратор и бухгалтерия. la.exe (clip)/hla.exe (harb)
3. Аналитический контур. ldust.exe (clip)/hld.exe (harb)

Буду очень благодарен за найденные ошибки и критику в любой форме! Скачка с учётом исправлений всех замечаний на 04.04.2010 (5.92) http://get.freesoft.ru/?id=108083

 Отправлено: 06.04.10 21:48. Заголовок: AndreyZh пишет: Про..

AndreyZh пишет:

цитата:

Просто xHarbour меня сильно соблазнил, тем, что не меняя "ничего" можно резко (в 2 раза повысить скорость приложения). Но этот опыт лишний раз меня убедил, что сравнения систем (баз данных и т.д.) нужно проводить на "пограничных" состояниях

Это вы конечно исходили из ложных предпосылок. Если виртуальная машина работает в 2 раза быстрее, то это совсем не значит, что доступ к диску происходит в 2 раза быстрее или сетевые операции в 2 раза быстрее начинают выполнятся. Узкие места все равно остаются.
Теперь по сравнению систем. xHarbour приложение у вас является 32 разрядным win приложением и выполняется, как и положено любому нативному Windows приложению. Clipper приложение выполняется под NTVDM. Для чистоты эксперимента возьмите сборку xHarbour для DOS (есть такие) и сравните.

Pasha пишет:

цитата:

А по скорости Harbour сейчас превосходит xHarbour в среднем в 2 раза.

Это да, но работа в сети сильно нивелирует разницу в скорости виртуальных машин. И в сухом остатке можно рассчитывать на 6-10%.
Но если писать серверную часть, то конечно, как написал Miguel Angel Marchuet: "the result is impressive".

 Отправлено: 06.04.10 21:53. Заголовок: Dima А слабо показа..

Dima

цитата:

А слабо показать на самодостаточном живом примере что Xharbour работает уступает по скорости Clipper

Я как бы просто описал результаты тестов - суть есть некий критический объем БД, которую программа должна обрабатывать, превышая который xHarbour (dbf + ntx) начинает работать медленнее, чем clipper 5.01 (dbf + ntx) и всё. У меня "растройство", а Вы ещё издеваетесь При желании сами сгенерируйте набор связанных таблиц объёмом более 300Mb и попробуйте...

цитата:

Может быть "яма" в ваших алгоритмах ?

В тестах не сравнивались скорости алгоритмов обработки данных, а сравнивалась скорость обработки данных программами на Clipper 5.01 и xHarbour (сборка 12.2009) по единообразным алгоритмам. Если же Вы сомневаетесь в моём профессионализме разработчика - дайте мне свою небольшую программу и я её ускорю в пару раз.


Pasha

цитата:

Я все-таки советую обратить внимание на Harbour. По части совместимости с clipper он сейчас мало в чем уступает, а по некоторым моментам превосходит xHarbour. А по скорости Harbour сейчас превосходит xHarbour в среднем в 2 раза. Об это пишут и разработчики xHb, да я и сам проводил эти тесты.

Вполне возможно! Но первой мне попалась инструкция для новичков от Верченко Андрея, по этому и использовался xHarbour, да и казалось, что продукт от коммерческих разработчиков должен быть более тщательно проработан. Если Вас не затруднит перекомпилируйте систему из моей ссылки в первом сообщении (все исходники, bat) приложены и я с удовольствием (и на пользу дела) проведу повторное тестирование на скорость, а так же в дальнейшем на надёжность системы на Harbour.

цитата:

2. Надо использовать трюк в функции fsCommit в модуле rtl\filesys.c. Об этом здесь многократно писалось. 3. Для совместно открытых файлов используйте блокировку индекса на чтение dbOrderInfo(DBOI_READLOCK,,, .t.) Этот дает выигрыш в производительности в разы.

Все рекомендации очень полезны (и будут мной задействованы в будущем). Но сейчас была другая задача.

 Отправлено: 06.04.10 22:19. Заголовок: AndreyZh пишет: Есл..

AndreyZh пишет:

цитата:

Если же Вы сомневаетесь в моём профессионализме разработчика - дайте мне свою небольшую программу и я её ускорю в пару раз.

Вопрос был не ко мне и у меня нет никаких сомнений в вашем професионализме, но попробуйте оптимизировать сл. фрагмент кода

     
     crVall  := AllTrim(Upper(nameVal)) 
     &crVall := IF(Upper(Left(crVall,1))=='C', AllTrim(zVal),; 
                IF(Upper(Left(crVall,1))=='N', Val(zVal),; 
                IF(Upper(Left(crVall,1))=='D', Ctod(AllTrim(zVal)),; 
                IF(Upper(Left(crVall,1))=='L', ".T." $ Upper(zVal),"")))) 
  
 

 Отправлено: 06.04.10 22:23. Заголовок: Петр даже знаю како..

Петр
даже знаю какой будет ответ от AndreyZh .............

PS
Тем не менее с удовольствием посмотрю на его оптимизированный код.
И я по ходу совсем не прикалываюсь !!!!!!!!!!! Это к Топикстартеру относится.

 Отправлено: 07.04.10 01:01. Заголовок: Pasha пишет: 2. Над..

Pasha пишет:

цитата:

2. Надо использовать трюк в функции fsCommit в модуле rtl\filesys.c. Об этом здесь многократно писалось.

А можно еще раз написать про это ? А то делаешь поиск по сайту здесь, а поиск "косячит", т.е. не дает результата....
Заранее спасибо !

Pasha пишет:

цитата:

3. Для совместно открытых файлов используйте блокировку индекса на чтение dbOrderInfo(DBOI_READLOCK,,, .t.)

Дайте пожалуйста пример небольшой... Хотя бы конструкцию... Я хочу на своей большой системе попробовать...
Заранее спасибо !

 Отправлено: 07.04.10 09:27. Заголовок: Andrey пишет: А мож..

Andrey пишет:

цитата:

А можно еще раз написать про это ?

http://clipper.borda.ru/?1-4-0-00000477-000-10001-0-1257415410

 Отправлено: 07.04.10 09:39. Заголовок: 2. В модуле rtl\..

2. В модуле rtl\filesys.c в начале fsCommit надо вставить 4 строки, так:

HB_EXPORT void hb_fsCommit( FHANDLE hFileHandle )
{
HB_THREAD_STUB
HB_TRACE(HB_TR_DEBUG, ("hb_fsCommit(%p)", hFileHandle));
/*
Working hb_fsCommit() on Windows.
Personally I'm not a fun of this because it deeply interact with
internal OS buffering scheme.
in source/rtl/filesys.c add at the beginning of function hb_fsCommit()
(line: 2467 just before HB_STACK_UNLOCK)
*/
#if defined(HB_OS_WIN_32)
hb_fsSetIOError( TRUE, 0 );
return;
#endif

3. Выборки из файла можно выполнять так:

dbOrderInfo(DBOI_READLOCK,,, .t.)
dbSeek(..)
while ...
if ...
endif
skip
enddo
dbOrderInfo(DBOI_READLOCK,,, .f.)

Это блокировка индекса на чтение. Она выполняется всегда при любой навигавии по таблице, т.е. в операциях seek/skip/goto
Если выборка состоит из 100 строк, то блокировка/разблокировка будет выполняться 100 раз, и выборка будет тормозить.
Если блокировку сделать перед выборкой, то выборка будет выполняться быстро.
Но злоупотреблять READLOCK не стоит, поскольку на время блокировки эти данные недоступны для чтения с других станций.

 Отправлено: 07.04.10 12:10. Заголовок: Доброго дня! Вопрос..

Доброго дня!

цитата:

Вопрос был не ко мне и у меня нет никаких сомнений в вашем професионализме, но попробуйте оптимизировать сл. фрагмент кода

Смотрю на код... Что похожее есть у меня в программе... Если это "наезд", то пошукайте код еще и такое найдёте... Иногда, добавляя возможности в систему натыкаюсь на блоки написанные еще в 1992 году (см. funcanzh.prg) - они работают, так зачем их трогать?

В приведённом примере есть несколько "некрасивостей", но вне зависимости от этого у меня схожий блок выполняется единожды при запуске программы и занимает по времени 0.001 секунды и как проверить его оптимальность не знаю?

цитата:

даже знаю какой будет ответ от AndreyZh .............

Мне это очень интересно? Какой следует ожидать от меня ответ?


Ладно - это флуд, обед заканчивается, краткая инфа:

Под тест попала самая худшая аппратная конфигурация (сервер celer 1700 (без кэш)/128Mb/IDE 80Gb, раб.станции ещё хуже - всё под win 98). Это конечно "мрак" но всех устраивала работа dos программы. Радует, что xHarbour вариант вообще запустился, но в силу жутких тормозов девушки категорически отказались от дальнейшего тестирования.

Примечание. В winXP кириллица отражалась как заголовок окна, а под win 98 НЕТ. Не "кидайте в меня", но где-то около 150 ПК продолжает работать под win 98 и несколько win 95 (и я не мог заставить руководство избавиться от этого "мусора").

 Отправлено: 07.04.10 12:27. Заголовок: AndreyZh пишет: Под..

AndreyZh пишет:

цитата:

Под тест попала самая худшая аппратная конфигурация (сервер celer 1700 (без кэш)/128Mb/IDE 80Gb, раб.станции ещё хуже

Нормальный компьютер

цитата:

ещё хуже - всё под win 98

Под win98 тормозит терминал gtwin. Используйте gtwvt

 Отправлено: 07.04.10 16:53. Заголовок: Добрый вечер. УВЫ!!..

Добрый вечер.

УВЫ!!! С прискорбием сообщаю, что система на Clipper 5.01 пересобранная на xHarbour провалила тест на надёжность.

Тестирование проводилось на стабильно работающей мощной технике (рабочие станции XP Prof/Home Celer от 2400/RAM от 512/SATA от 160, выделенный сервер 4 ядерный Xeon/RAID 10/RAM 4Gb, сеть 100mb/1Gb). Существующая программа показывает стабильную работу (до 1
разрушения индексов в 6 месяцев) при весьма большой нагрузке до 10 операторов на запись + 50 КПК в двух системах мобильной торговли + 8 точек внешних автоматических заказов). Все процессы записи завершаются функциями (что гарантирует (у clipper) её успешность):
DbUnlockAll()
DbCommitAll()

Суть теста - 5 операторов одновременно вводят по 10 накладных + ввод 30 фин.документов + с 5 рабочих мест построение отчётов. Данная нагрузка не порушила данные, но операторы заметили глюк - после завершения массированной записи документов на одном (физически разные ПК) рабочем месте программа не могла в течении 3 минут произвести сохранения (были блокированны ресурсы) хотя формально блокировки были сняты.. Потом "просыпаясь" данные всё таки сохранялись.

То есть и как при тесте скорости, так и здесь возникает ощущение, что xHarbour виртуальная машина работает с неким КЭШ, который создаёт иллюзию скорости на малом объёме данных, а при его "переполнении" (выгрузки на физический носитель) включаются "тормоза".

Затем начался "садизм" - обычная практика пользователей. При этом НИКТО НЕ ПРОИЗВОДИЛ ввод данных в базу. Делалось закрытие программ "крестиком" и перезагрузкой ПК (на 3 рабочих местах). Система на Clipper спокойно к этому относится, т.к. до этого все данные "выдавлены после записи на физический носитель". Возникли проблемы:

1. Процессы оставили часть файлов заблокированными.
2. После корректного завершения программы с остальных рабочих мест система стала резко тормозить даже при запуске на сервере.
3. После принудительного закрытия блокированных файлов средствами MS WinServer 2008 была проведена проверка "логической целостности", обнаружившая разрушение данных.
4. Просмотр файлов средствами DBU показал физическое разрушение Dbf файлов (не тех, которые принудительно закрывали).


РЕЗЮМЕ. Перевод существующей, тщательно отработанной системы на Clipper посредством компилятора xHarbour не обеспечивает:

1. Ускорения работы системы на БОЛЬШИХ базах;
2. Стабильность и устойчивость системы скорее всего снизится.


РЕШЕНИЕ. При острой необходимости перевода существующей Clipper системы на (x)Harbour её необходимо радикально переделывать и желательно под SQL Server, например ADS, MS SQL Express, FireBird, MySql...


P.S. У меня осталось два вида тестирования (на завта), просто любопытство на будущее:

1. Проверка работоспособности на Win95;
2. Проверка ситуации с Win 98 (просто плохая совместимость с данной системой или Win98 в качестве сервера) на конторе, где сервер (выделенный MS Windows Server 2003 и большинство рабочих станций на Win 98).

 Отправлено: 07.04.10 17:17. Заголовок: AndreyZh пишет: Сис..

AndreyZh пишет:

цитата:

Система на Clipper спокойно к этому относится

А чем линковали ? Rtlink , Blinker и тд ?
Real Mode или Protected ?

 Отправлено: 07.04.10 18:09. Заголовок: А чем линковали ? Rt..

цитата:

А чем линковали ? Rtlink , Blinker и тд ? Real Mode или Protected ?

Rtlink / Real Mode

 Отправлено: 07.04.10 18:59. Заголовок: Интересно а как обст..

Интересно а как обстоят дела у Юрия ?
http://clipper.borda.ru/?1-4-60-00000430-000-0-0

У него и юзеров поболее будет и базы побольше.
Ни кто не в курсе ?

 Отправлено: 07.04.10 19:54. Заголовок: AndreyZh пишет: Смо..

AndreyZh пишет:

цитата:

Смотрю на код... Что похожее есть у меня в программе... Если это "наезд"

Это ваш код и это не наезд

цитата:

В приведённом примере есть несколько "некрасивостей", но вне зависимости от этого у меня схожий блок выполняется единожды при запуске программы и занимает по времени 0.001 секунды и как проверить его оптимальность не знаю?

этот код я взял из request.ch. На счет единажды не уверен. Визуально и путем профилирования.

цитата:

РЕЗЮМЕ. Перевод существующей, тщательно отработанной системы на Clipper посредством компилятора xHarbour не обеспечивает: 1. Ускорения работы системы на БОЛЬШИХ базах; 2. Стабильность и устойчивость системы скорее всего снизится.

Механический перевод - да. Потому, что я уже говорил [x]Harbour приложение - это в вашем случае 32 разрядное Win приложение, которое работает абсолютно как все остальные приложения Windows, т.е. использует дисковый кэш, системный стек TCP/IP по определенным правилам принятым в Windows. И на самом деле DbCommitAll() для Windows никак не указ и не гарантия сброса информации на диск. Руссинович М. Внутреннее устройство Microsoft Windows на ночь помогут вам.
AndreyZh пишет:

цитата:

РЕШЕНИЕ. При острой необходимости перевода существующей Clipper системы на (x)Harbour её необходимо радикально переделывать и желательно под SQL Server, например ADS, MS SQL Express, FireBird, MySql...

Вы MS SQL Express или хотя бы MySql for Win на Celeron 1700, не выделенный сервер когда нибудь пробовали?
Или рабочий SQL сервер кнопочкой reset перезагружать

 Отправлено: 07.04.10 21:01. Заголовок: Петр Что же Вы так..

Петр

Что же Вы такой недобрый?

цитата:

этот код я взял из request.ch. На счет единажды не уверен. Визуально и путем профилирования

"Чья туфля - моя туфля". И используется не единожды - то же верно. В системе запросов на 3-6 отчётах (из 300) для закачки "сохранённых параметров отчёты". Максимально (50 строк) - 0.5 секунды (уговорили). Создано где-то в 2006 году (виноват - забыл, да и не жаловался никто), а теперь используя "автоматом".

цитата:

Потому, что я уже говорил [x]Harbour приложение - это в вашем случае 32 разрядное Win приложение, которое работает абсолютно как все остальные приложения Windows, т.е. использует дисковый кэш, системный стек TCP/IP по определенным правилам принятым в Windows.

Где же вы раньше были - может бы и не мучился сам с переводом системы, да и не мучил других. А "задним умом" все мы сильны!

цитата:

И на самом деле DbCommitAll() для Windows никак не указ и не гарантия сброса информации на диск.

Да??? Для Clipper получается указ, а остальные "что рыжие"?

цитата:

Руссинович М. Внутреннее устройство Microsoft Windows на ночь помогут вам.

А что сон после прочтения более крепкий? Или наоборот не усну, а то и на работы можно опоздать. Вообще-то у меня самого около 80Gb технической литературы, к которой обращаюсь "по мере необходимости", а вообще "голова - не мусорный ящик".

цитата:

Вы MS SQL Express или хотя бы MySql for Win на Celeron 1700, не выделенный сервер когда нибудь пробовали?

Нет! А зачем мне это надо? Люди нормальные ПК за 10-16 т.р. купить не могут/нехотят, а Вы о сервере за 148 т.р. говорите.

цитата:

Или рабочий SQL сервер кнопочкой reset перезагружать

Я нет, а операторы пробовали --- очень хороший аргумент для руководства был "о бессмыслености смены файл-серверной архитектуры и моего программного обеспечения" == стоимость восстановления сервера и информации равнялась моей 6 месячной зарплаты в данной фирме.

 Отправлено: 12.04.10 20:24. Заголовок: Амнистия в связи с ..

Амнистия в связи с Всемирным днем космонавтики


AndreyZh
Продолжаем , но без наездов на участников форума !

 Отправлено: 12.04.10 21:58. Заголовок: Добрый вечер! Andre..

Добрый вечер!

цитата:

AndreyZh Продолжаем , но без наездов на участников форума !

Очень хотелось бы уяснить "устав монастыря" или юмор на форуме запрещён? Или кто-то "более равный перед законом"? Ну ладно - это ночной бред....

Раннее были опубликованы предварительные результаты тестирования с первичной реакцией пользователей. В течении прошедшей недели около 200 users (14 фирм) должны были её "мучить". Соответственно окончательные результаты и выводы будут к концу этой недели, когда их всех объеду, выслушаю их мнение и проверю тщательность тестирования (по внутренним журналам), а так же целостность данных по подсистеме "анализа логической целостности".

На досуге почитал описалки http://www.otc.pl/download/default.aspx?l=2 халявные RDD к mySQL для clipper .AND. (x) Harbour - может это "решение всех проблем"? Интересно, а кто-нибудь реально работает с RDD к SQL Server?

 Отправлено: 13.04.10 14:45. Заголовок: AndreyZh пишет: Да?..

AndreyZh пишет:

цитата:

Да??? Для Clipper получается указ, а остальные "что рыжие"?

Для MS-Dos - указ, для Windows - нет.

 Отправлено: 13.04.10 20:41. Заголовок: Сергей Р & Петр ..

Сергей Р & Петр

Очень бы хотелось уяснить проблему, а главное пути её разрешения (программным, а не организационным путём). Работаем под Windows.Имеем код:

sele <Область>
fillock()
*** Изменяем поля, в том числе индексные
DbUnlock()
DbCommit()

После последней операции программу на Clipper 5.01 исполняющуюся на рабочей станции (не сервере) могу "закрывать" любым способом, в том числе RESET и данным ничего не будет - десятком лет проверено мной и пользователями. Но некорректное прерывание программы на xHarbour порождает разрушение, по меньшей мере индексов (проверено на тесте).

1. Так ли это (по опыту других)?
2. Как бороться программным путём?


По тестам программы на xHarbour...

1. Пользователи посредством "строгости" xHarbour наткнулись на мою очень серьёзную ошибку - в одном месте (удаление отгрузки) "забыл" закрывать таблицу, которая многократно открывалась/закрывалась во всех режимах. xHarbour при повторной попытке открытия открытого файла вылетал по ошибке выполнения. Clipper честно продолжал "размножать" одноименные алиасы, пока предел открытых областей не превышал максимум, после чего программа в любом (произвольном) месте "вылетала" без сообщений. Режим редкий, следовательно случаи вылетов так же практически не встречались.

2. Жалуются на более медленную работу проги на xHarbour в сравнении с Clipper... Особенно это "бросается в глаза" при одновременной сетевой работе... Деградация скорости на порядок. Программа и базы находятся на сервере.

3. Мне очень не понравилась реакция - "если системы похожи, то зачем городить огород".

 Отправлено: 13.04.10 21:10. Заголовок: AndreyZh пишет: Жал..

AndreyZh пишет:

цитата:

Жалуются на более медленную работу проги на xHarbour в сравнении с Clipper... Особенно это "бросается в глаза" при одновременной сетевой работе... Деградация скорости на порядок. Программа и базы находятся на сервере.

хХарбор в сети чуть медленней чем Клипер ! Это я на своих программах выявил ! Я тесты приводил здесь на форуме !
У меня разница получалась на 10-15 сек. по выборке из 30 000 записей.
После переделки алгоритма разница составила 2-5 сек.
От ваших "стенаний" скорость не увеличиться.
Я думаю даже после перевода на Harbour ! Драйвер же одинаков везде !

Резуме: переделывайте работу с базой !!!