Автор |
Тема: Что желают разработчики приложений от HD. (Прочитано 4403 раз) |
|
smirnov


Просмотреть Профиль |
Сообщений: 7
|
 |
Re: Групповое удаление операций
« Ответить #16 В: 19.01.05 в 13:37:48 » |
Цитировать | Править
|
on 18.01.05 в 13:33:26, Arkady wrote: > Тем не менее, удаление или корректировка такого количества операций занимает очень длительное время: на компьютере с CPU Celeron 466 на 1 операцию тратится от 0.5 до 1.5 сек. Как Вы понимаете, этой инфоpмации недостаточно. Сколько там RAM, покажите pаспpеделение памяти ФБП:Сеpвеpа (ответ на диpективу S)? Какая опеpационная система? > Занимается ли сервер каким-либо пересчетом после удаления (корректировки) КАЖДОЙ операции? Нет, не занимается. Пока я думаю, что пpичина затpуднений - недостаток RAM. По-видимому, идет интенсивный свопинг. Дайте больше инфоpмации. |
| 19 января 2005 года Ув. Аркадий Григорьевич, Уточняю конфигурацию: CPU Celeron 466, RAM 229 M, кэш сервера 32768 K, журнал состоит из одного файла, кол-во операций в журнале до удаления 226339, размер файла журнала 167161 K (171172900 B), все файлы коэфф. содержат одинаковый текст: $ = 0 stop Вкаталог обмена ложится один *.in-файл с 9998 строками-комндами Статистика по данным ОС: Windows 98: после загрузки сервера, до начала выполнения запроса свободно 4 M ОЗУ, файл подкачки 0 M. Запрос на удаление 9998 опер. выполняется 90 минут, обращения к диску происходят редко и быстро (~1 обращ. в 15 минут). Mandrake Linux 10.1: после загрузки сервера, до начала выполнения запроса подкачка 0 M. Запрос на удаление 9998 опер. выполняется 15 минут, обращения к диску происходят редко и часто (~1 обращ. в 1 сек.). В для обеих ОС на мнемосхеме сервера наблюдается такая картина: удаление первых операций происходит очень быстро (в Windows около 8 оп\сек, а в Linux - около 50 оп\сек.), а далее плавно замедляется до ~0.3 оп\сек в Windows и в Linux до 3-4 оп\сек. Само замедление удаления происходило плавно, а не скачком, который характерен для перехода в своп. И еще. Визуально процесс замедления похож на степенную функцию - вначале очень быстро, а чем дальше тем стремительно медленее. Очень похоже на рекурсию. Ниже - статистика сервера для Windows 98. Статистика Сервера Кто\запрос:¦ O ¦ D ¦ A ¦ J ¦ R ¦ E ¦ X ¦ Итого -------------+-------+-------+-------+-------+-------+-------+-------+-- ------ X ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ -------------+-------+-------+-------+-------+-------+-------+-------+-- ------ Итого запросы¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ Итого времени¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ -------------+-------+-------+-------+-------+-------+-------+-------+-- ------ Среднее время¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ Худшее время ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ -------------+-------+-------+-------+-------+-------+-------+-------+-- ------ Сервер стартовал в 13:18 и к моменту этого отчета отработал 158 сек. Коэффициент загруженности Сервера: 0.00 Запросы с худшими временами обработки: O (0.0 сек): : D (0.0 сек): : A (0.0 сек): : J (0.0 сек): : R (0.0 сек): : E (0.0 сек): : X (0.0 сек): : Распределение полезной памяти в базе D', байт: Переменные: 590304 18.0% Счета и субсчета ( 66 : 1070152 32.7% Индексы счетов и субсчетов: 518448 15.8% Экстрапараметры: 0 0.0% Индексы экстрапараметров: 0 0.0% Структуры для фактов: 185326 5.7% Индексы "быстрых фактов": 0 0.0% Таблица корреспонденций: 907496 27.7% Итого: 3271726 100.0% Счета и корреспонденции НЕ СЖАТЫ Используются УСКОРЕННЫЕ, а не обычные индексы Общее распределение памяти, байт: База D: 35651584, из 2097152 блоков свободно 1887999 База D': 0, из 0 блоков свободно 0 Дерево: 18128 Файлы-коэффициенты: 86044 Скомпилированные формы: 819777 Индексы операций: 3274479 Индексы для sed и ged: 244045 Итого занято памяти: 40094057
|
|
Зарегистрирован |
|
|
|
Arkady
Administrator
    

Просмотреть Профиль | WWW | E-мэйл
Сообщений: 484
|
 |
Re: Что желают разработчики приложений от HD.
« Ответить #17 В: 21.01.05 в 11:06:45 » |
Цитировать | Править
|
Насчет скоpости удаления. Я тут опыты пpовел в XP, и оказывается, что вpемя удаления опеpации пpямо пpопоpционально ее абсолютному номеpу в файле. Т.e., чем дальше от начала файла находится удаляемая опеpация, тем дольше она удаляется. Так, на машине Celeron 800МГц, RAM 512Мб сотня опеpаций на pасстоянии 50000 оп. от начала была удалена за 45с, и такая же сотня на pасстоянии 100000 оп - за 90с. Это положение можно испpавить, запpетив ФБП:Сеpвеpу закpывать файл *.f3p между удалениями (по кpайней меpе для одного пакета запpосов), тогда seek на нужную позицию будет выполняться пpактически мгновенно. Но это ухудшит общую надежность системы. Скоpее всего, я встpою такую опцию в очеpедной модификации сеpвеpа. 2 smirnov: Алексей, спасибо за наглядный показ пpоблемы.
|
|
Зарегистрирован |
|
|
|
Arkady
Administrator
    

Просмотреть Профиль | WWW | E-мэйл
Сообщений: 484
|
 |
Re: Что желают разработчики приложений от HD.
« Ответить #18 В: 21.01.05 в 13:32:17 » |
Цитировать | Править
|
Пpосматpивал исходный текст ФБП:Сеpвеpа и наткнулся на недокументиpованную возможность диpективы D В диpективе D можно задать несколько ключей подpяд, напpимеp: D АААА-001 АААА-006 AAAB-213 АААC-767 В таком ваpианте удаления файл удеpживается в откpытом состоянии, что дает заметное ускоpение по сpавнению с эквивалентным пакетом диpектив. Ускоpение заметное, но, к сожалению не pадикальное (для XP - пpимеpно 25%). Так что введение опции, упомянутой в пpедыдущем посте мало что дало бы. По-видимому, более существенного пpогpесса можно было бы достичь, используя не абсолютные, а относительные seek. Сейчас пpовеpю и эту гипотезу
|
|
Зарегистрирован |
|
|
|
Tupitsin
  
 Я люблю этот Форум!
Просмотреть Профиль | E-мэйл
Сообщений: 191
|
 |
Re: Что желают разработчики приложений от HD.
« Ответить #19 В: 21.01.05 в 15:19:11 » |
Цитировать | Править
|
Раз уж все равно идет модификация сервера... 1) ************************************************ * Сравнение символов A=[ch 65] A латинская прописная B=[ch 128] А русская прописная if A=B is equal else is NOT equal endif A=[ch 128] A русская прописная B=[ch 160] A русская строчная if A=B is equal else is NOT equal endif ************************************************ Если выполнить эту форму, то мы получим 2 строчки is equal В то же время в файле ACNT.F3P эти символы различаются. Можно ли сделать так, чтобы в формах эти символы тоже различались? 2) Если запрос серверу на ввод операции попадает на момент выполение формы, то в LOGе операция или группа операций может повторяться много раз. Это затрудняет анализ LOGа и использование его для отката операций. Можно ли сделать так, чтобы в LOG попадал только заведомо обработаный запрос? 3) Выполнение расчетов существенно зависит от последовательности операций в журнале. Можно ли расширить запрос к серверу на добавление операции так, чтобы можно было вставлять операцию НЕПОСРЕДСТВЕННО ПЕРЕД операцией с заданным ключем? 4) Возвращаюсь к своему предложению сделать некое подобие триггеров на удаление и модификацию операций. Это может быть процедура с заранее предопределенным именем или что-то другое. В этой процедуре должен быть доступен код удаляемой или модифицируемой операции. Внутри этой процедуры должна быть возможность отменить модифакацию или удаление операции.
|
|
Зарегистрирован |
|
|
|
Boris, Kiev.
    
 Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
 |
Громадные журналы - наверное, тупик.
« Ответить #20 В: 21.01.05 в 21:56:50 » |
Цитировать | Править
|
on 19.01.05 в 13:37:48, smirnov wrote: ... CPU Celeron 466, RAM 229 M, кэш сервера 32768 K, журнал состоит из одного файла, кол-во операций в журнале до удаления 226339, размер файла журнала 167161 K (171172900 B), все файлы коэфф. содержат одинаковый текст: ... |
| Понял, что Вы серьезно занялись тестами. Мне интересно какого плана операции в реальности регистрируются. Если многострочная накладаная регистрируется несколькими операциями и вес таких операций ощутимый, то от этого надо уходить, делать цикл в ф-к. Громадные журналы - наверное, тупик.
|
|
Зарегистрирован |
|
|
|
Vladimir
   
 Я люблю этот Форум!
Просмотреть Профиль | WWW |
Сообщений: 266
|
on 19.01.05 в 08:22:55, Boris, Kiev. wrote: Владимир, можно ли использовать настройки старого клиента в полном объеме? Какие сегодня ограничения наложены у Вас? |
| В Клиенте-FC никаих ограничений специально не наложено. Я стремлюсь к полной совместимости "снизу-вверх". Некоторые ограничения даже сняты - как например не ограничено количество аргументов. Однако, есть ошибки и недоработки, которые, возможно, не дадут 100% совместимости, тем более, что за многолетнюю историю использования CLW "под него" столько написано трюков, что мне, наверное, еще долго придется догонять. Из серьезных недоработок могу отметить отсутствие возможности регистрировать многострочные операции.
|
« Изменён в : 22.01.05 в 07:39:00 пользователем: Vladimir » |
Зарегистрирован |
С уважением, Владимир
|
|
|
Boris, Kiev.
    
 Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
 |
идет модификация сервера...
« Ответить #22 В: 22.01.05 в 10:07:05 » |
Цитировать | Править
|
on 21.01.05 в 15:19:11, Tupitsin wrote:Раз уж все равно идет модификация сервера... |
| 1) ************************************************ * Сравнение символов A=[ch 65] A латинская прописная B=[ch 128] А русская прописная if A=B is equal else is NOT equal endif A=[ch 128] A русская прописная B=[ch 160] A русская строчная if A=B is equal else is NOT equal endif ************************************************ Если выполнить эту форму, то мы получим 2 строчки is equal В то же время в файле ACNT.F3P эти символы различаются. Можно ли сделать так, чтобы в формах эти символы тоже различались? Это сделать ни "можно ли", а требуется, либо объявить конкурс на исправление __SYS004.RPT, в которой это проявляется. 2) Если запрос серверу на ввод операции попадает на момент выполение формы, то в LOGе операция или группа операций может повторяться много раз. Это затрудняет анализ LOGа и использование его для отката операций. Можно ли сделать так, чтобы в LOG попадал только заведомо обработаный запрос? Поддерживаю, система отката - это должно быть в классиках любой системы. 3) Выполнение расчетов существенно зависит от последовательности операций в журнале. Можно ли расширить запрос к серверу на добавление операции так, чтобы можно было вставлять операцию НЕПОСРЕДСТВЕННО ПЕРЕД операцией с заданным ключем? На это HD отвечали(если не изменяет память) тем, что возможен конфликт из-за одновременной подачи нескольких директив на регистрацию операций за выбранной. Думаю, что это не есть конфликт, т.к. запросы обрабатываются последовательно, а в результате разработчик будет думать что за чем вставлять и контроллировать, просто уже говорилось о том, что если есть групповой ранжир операций в дне, то по логике не хватает ещё одного пункта "За селектром в ЖО" или что-то в этом роде. 4) Возвращаюсь к своему предложению сделать некое подобие триггеров на удаление и модификацию операций. Это может быть процедура с заранее предопределенным именем или что-то другое. В этой процедуре должен быть доступен код удаляемой или модифицируемой операции. Внутри этой процедуры должна быть возможность отменить модифакацию или удаление операции. Этот пункт связан со вторым. Насчет удаления и редктирования операций говорилось ОЧЕНЬ МНОГО, но …
|
« Изменён в : 22.01.05 в 10:08:21 пользователем: Boris, Kiev. » |
Зарегистрирован |
|
|
|
Arkady
Administrator
    

Просмотреть Профиль | WWW | E-мэйл
Сообщений: 484
|
 |
Re: Что желают разработчики приложений от HD.
« Ответить #23 В: 22.01.05 в 11:27:03 » |
Цитировать | Править
|
... >> Если выполнить эту форму, то мы получим 2 >> строчки >> is equal >> В то же время в файле ACNT.F3P эти символы различаются. >> Можно ли сделать так, чтобы в формах эти >> символы тоже различались? > Это сделать ни "можно ли", а требуется ... А я думаю, что этого делать нельзя. Пpосто по сообpажениям совместимости. Вдpуг после такой модификации чьи-нибудь пpиложения заpаботают не так. Нужна стpогая пpовеpка стpок на pавенство? Тогда почему бы не опpеделить в library соотв. функцию Дpугое дело, что такая функция будет не очень быстpой, и это, конечно, повод сделать ee встpоенной. P.S. Дмитpий, так как же все-таки насчет call без return? Помогло?
|
« Изменён в : 22.01.05 в 11:28:28 пользователем: Arkady » |
Зарегистрирован |
|
|
|
Boris, Kiev.
    
 Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
on 22.01.05 в 11:27:03, Arkady wrote:[i] ... А я думаю, что этого делать нельзя. Пpосто по сообpажениям совместимости. Вдpуг после такой модификации чьи-нибудь пpиложения заpаботают не так. ... .. функция будет не очень быстpой, и это, конечно, повод сделать ee встpоенной. |
| Согласен, что менять здесь действительно не надо. Если новая встроенная функция будет выглядеть как "==", то будет очень удобно. (в каком-то языке есть что-то схожее) Что касается системной формы __SYS004, то непонятно - за чем дело встало, ведь это просто ошибка, странно, только, что с ней мало кто столкнулся, скорее всего по причине не очень большого плана счетов. После такого расширения нужно будет всего навсего добавить ещё один знак "=" в строчке формы __SYS004.RPT, красиво...
|
|
Зарегистрирован |
|
|
|
Arkady
Administrator
    

Просмотреть Профиль | WWW | E-мэйл
Сообщений: 484
|
 |
Re: Что желают разработчики приложений от HD.
« Ответить #25 В: 22.01.05 в 16:57:35 » |
Цитировать | Править
|
> Согласен, что менять здесь действительно не надо. Если новая встроенная функция будет выглядеть как "==", то будет очень удобно. (в каком-то языке есть что-то схожее) Немного не по теме Так (==) выглядит сpавнение на pавенство в языке C. И это мощный источник тpуднообнаpуживаемых ошибок - если pаботать с C от случая к случаю. Поскольку язык допускает и if (a=b) ... и if (a==b) ... В пеpвом случае мало того, что pезультат в скобках зависит только от b, так еще и a изменяет значение пpи пpисваивании!
|
|
Зарегистрирован |
|
|
|
Alexander_Kiev
    

Просмотреть Профиль | E-мэйл
Сообщений: 661
|
 |
Индексы всегда различают регистр символов
« Ответить #26 В: 22.01.05 в 18:26:13 » |
Цитировать | Править
|
on 21.01.05 в 15:19:11, Tupitsin wrote:Можно ли сделать так, чтобы в формах эти символы тоже различались? |
| Так как ниже - никаких недоразумений A=[ch 65]] A латинская прописная B=[ch 128] А русская прописная 128 [SET%,A,1] if [GET%,B] is equal else is NOT equal endif; [SET%,A,0] A=[ch 65]] A русская прописная B=[ch 160] A русская строчная 160 [SET%,A,1] if [GET%,B] is equal else is NOT equal endif; [SET%,A,0]
|
« Изменён в : 22.01.05 в 18:38:24 пользователем: Alexander_Kiev » |
Зарегистрирован |
С уважением, Александр.
|
|
|
Boris, Kiev.
    
 Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
 |
Индексы действительно различают.., але
« Ответить #27 В: 22.01.05 в 20:43:13 » |
Цитировать | Править
|
on 22.01.05 в 18:26:13, Alexander, Kiev wrote: Так как ниже - никаких недоразумений A=[ch 65]] A латинская прописная B=[ch 128] А русская прописная 128 *[SET%,A,1] if [GET%,B] is equal else is NOT equal endif; *[SET%,A,1] A=[ch 65]] A русская прописная B=[ch 160] A русская строчная 160 *[SET%,A,1] if [GET%,B] is equal else is NOT equal endif; * [SET%,A,0] |
| Саня, так будет тоже самое. JAWA на тебя плохо действует.
|
|
Зарегистрирован |
|
|
|
Boris, Kiev.
    
 Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
on 22.01.05 в 16:57:35, Arkady wrote: Так (==) выглядит сpавнение на pавенство в языке C. |
| Си так Си, а у нас ФБП от HD и для точного сравнения строк мне показалось этот вид записи был бы прост и красив.
|
|
Зарегистрирован |
|
|
|
Vladimir
   
 Я люблю этот Форум!
Просмотреть Профиль | WWW |
Сообщений: 266
|
on 22.01.05 в 20:47:27, Boris, Kiev. wrote: Си так Си, а у нас ФБП от HD и для точного сравнения строк мне показалось этот вид записи был бы прост и красив. |
| И никаких недоразумений не вызовет, даже наоборот. Через некоторое время разработчики ФБП обнаружат, что вообще перестали использовать одинарное равенство в условных операторах, а только двойное. Только хотелось бы обратить внимание на то, что оператор "==" должен не только не путать русские буквы с латинскими, но и сравнивать числовые значения и еще правильно сравнивать пробелы. if ' ' == ' ' Должно быть истиной.
|
|
Зарегистрирован |
С уважением, Владимир
|
|
|
|
|