Меню

Сортировать:

Новое Популярное
Ускорение программ через параллельное программирование (11)

Комментарий от  

Олег Точенюк

  |  03 сентября 2020, 08:04

Александр Носов 03 сентября 2020, 07:30

Даже если использовать треть диалогов для параллельных задач, можно в 8 раз ускорить некоторые процессы. Для некоторых операций это будет серьезным увеличением.

Та я не возражаю, конечно параллельное выполнение ускоряет работу программы, просто меня заинтересовали приведенные цифры и количество свободных процессов которые были в системе для достижения данного результата.
Ускорение программ через параллельное программирование (11)

Комментарий от  

Александр Носов

  |  03 сентября 2020, 07:30

Олег Точенюк 02 сентября 2020, 12:19

Ну например так:
MAX_PBT_WPS = 24
FREE_PBT_WPS = 22 (на момент запуска)
 
Пользователей скажем так где-то 1100-1200, понятно что активных гораздо меньше. Система S/4

Даже если использовать треть диалогов для параллельных задач, можно в 8 раз ускорить некоторые процессы. Для некоторых операций это будет серьезным увеличением.
Ускорение программ через параллельное программирование (11)

Комментарий от  

Олег Точенюк

  |  02 сентября 2020, 12:19

Александр Носов 01 сентября 2020, 10:09

Да, диалогов. А у вас какие значения вернет SPBT_INITIALIZE в продуктиве?
Насчет пользователей не располагаю достоверной информацией.

Ну например так:
MAX_PBT_WPS = 24
FREE_PBT_WPS = 22 (на момент запуска)
 
Пользователей скажем так где-то 1100-1200, понятно что активных гораздо меньше. Система S/4
Ускорение программ через параллельное программирование (11)

Комментарий от  

Александр Носов

  |  01 сентября 2020, 10:09

Олег Точенюк 01 сентября 2020, 09:42

Диалогов? 100 процессов не попадалось если честно, обычно гораздо скромнее. Кстати это какое количество пользователей у вас в системе, если не секрет, что более 100 диалогов открыто?

Да, диалогов. А у вас какие значения вернет SPBT_INITIALIZE в продуктиве?
Насчет пользователей не располагаю достоверной информацией.
Ускорение программ через параллельное программирование (11)

Комментарий от  

Олег Точенюк

  |  01 сентября 2020, 09:42

Александр Носов 01 сентября 2020, 08:18

Ограничение группы серверов не более 25% от общего количества процессов. Всего более 100 процессов. Это разве много?

Диалогов? 100 процессов не попадалось если честно, обычно гораздо скромнее. Кстати это какое количество пользователей у вас в системе, если не секрет, что более 100 диалогов открыто?
Ускорение программ через параллельное программирование (11)

Комментарий от  

Александр Носов

  |  01 сентября 2020, 08:18

Олег Точенюк 01 сентября 2020, 07:47

Хорошая у вас система, с сорока свободными процессами и еще наверное плюс десятком дополнительных, на других пользователей, пока программа выполняется :-)

Ограничение группы серверов не более 25% от общего количества процессов. Всего более 100 процессов. Это разве много?
Ускорение программ через параллельное программирование (11)

Комментарий от  

Олег Точенюк

  |  01 сентября 2020, 07:47

Александр Носов 31 августа 2020, 16:47

Если 5-8 часов разделить на 30-40 свободных процессов, получится 7-16 минут.

Хорошая у вас система, с сорока свободными процессами и еще наверное плюс десятком дополнительных, на других пользователей, пока программа выполняется :-)
Ускорение программ через параллельное программирование (11)

Комментарий от  

Александр Носов

  |  31 августа 2020, 16:47

Олег Точенюк 31 августа 2020, 14:28

Чего-то у меня цифры не бьются. Например на установку статуса пусть уходит 1 секунда, и время закрытия 5 часов итого за это время при последовательном закрытии у тебя закрывается 5 * 3600 = 18 000 заказов. После распараллеливания, заказ как зарывался за 1 секунду так и будет закрываться, что его параллельно, что последовательно грузить (бапишке фиолетово она в своем процессе отработает необходимое ей время как ты ее не крути). По твоим словам, теперь это все стало отрабатывать за пару минут, ну пусть это будет 5 минут для ровности. Итого у тебя каждую минуту закрывается сколько? Правильно 3600 / 5 = 720 заказов. Короче я в своей жизни систему с 720 свободными процессами не видел еще, твоя видимо первая будет, ну это чтобы оно таки за пару, точнее 5 минут отработало. В общем если бы была реальная статистика с рабочей системы приведена, было бы чуть интереснее. В свое время когда такое делал я просто привел цифры, чтение 120 000 документов:
 
Паралельно 3 процесса: 11 520 002 милисекунд
Последовательно : 20 632 688 милисекунд
 
А ну и сейчас перформы уже не модно Василий К. придет будет говорить, что это не правильное программирование :-), на классах параллельность выглядит чуток интереснее и красивее в реализации, программа обработки выглядит типа так:
LOOP AT <по каким-то объектам которые надо обработать>.
lcl->read( ).    "Прочитали что надо обработать в процесе
lcl->process( ). "Запустили процесс обработки
lcl->wait( ).    "Ждем если нет свободных процессов, иначе идем на следующий шаг.
ENDLOOP.

Если 5-8 часов разделить на 30-40 свободных процессов, получится 7-16 минут.
Ускорение программ через параллельное программирование (11)

Комментарий от  

Олег Точенюк

  |  31 августа 2020, 14:28

Чего-то у меня цифры не бьются. Например на установку статуса пусть уходит 1 секунда, и время закрытия 5 часов итого за это время при последовательном закрытии у тебя закрывается 5 * 3600 = 18 000 заказов. После распараллеливания, заказ как зарывался за 1 секунду так и будет закрываться, что его параллельно, что последовательно грузить (бапишке фиолетово она в своем процессе отработает необходимое ей время как ты ее не крути). По твоим словам, теперь это все стало отрабатывать за пару минут, ну пусть это будет 5 минут для ровности. Итого у тебя каждую минуту закрывается сколько? Правильно 3600 / 5 = 720 заказов. Короче я в своей жизни систему с 720 свободными процессами не видел еще, твоя видимо первая будет, ну это чтобы оно таки за пару, точнее 5 минут отработало. В общем если бы была реальная статистика с рабочей системы приведена, было бы чуть интереснее. В свое время когда такое делал я просто привел цифры, чтение 120 000 документов:
 
Паралельно 3 процесса: 11 520 002 милисекунд
Последовательно : 20 632 688 милисекунд
 
А ну и сейчас перформы уже не модно Василий К. придет будет говорить, что это не правильное программирование :-), на классах параллельность выглядит чуток интереснее и красивее в реализации, программа обработки выглядит типа так:
LOOP AT <по каким-то объектам которые надо обработать>.
lcl->read( ).    "Прочитали что надо обработать в процесе
lcl->process( ). "Запустили процесс обработки
lcl->wait( ).    "Ждем если нет свободных процессов, иначе идем на следующий шаг.
ENDLOOP.
Изменение данных таблиц через отладчик или ФМ (19)

Комментарий от  

Олег Точенюк

  |  30 августа 2020, 21:22

Олег Башкатов 30 августа 2020, 19:55

а можно вопрос немного переиначу:
что делать, если такой человек уже принят? и он уже формирует архитектуру и выдает ТЗ и уверен, что он прав, и уверяет других, что так лучше?
и там уже не 2 + 2 = 5, там 2 + 2 = 'ЛучшийВмиреОтвет подбери себе сам и с музыкой'.

Ну выход то у тебя всегда есть, вроде крепостное право отменил давно уже :-) А так что ты с ним можешь сделать? Он же уже работает и вадает как я понимаю тебе ТЗ. Ну можешь делать так как считаешь нужным, некоторое время.
Изменение данных таблиц через отладчик или ФМ (19)

Комментарий от  

Олег Башкатов

  |  30 августа 2020, 19:55

Олег Точенюк 27 августа 2020, 20:24

Ну что же раз желающих дать правильный ответ нет, или они очень заняты, напишу почему нет. В системе S/4 как и в предыдущих системах SAP ECC, завод всегда однозначно связан с балансовой единицей, через связку таблиц T001W - T001K - T001 следовательно, если кто-то делает таблицу, где ключами выступают поля БЕ + Завод, этим самым человек показывает свое абсолютное непонимание схемы БД в части логистики, а с другой стороны, ну раз он использует в примере, такую связку, то видимо он представляется всем как специалист по абап в области логистики, коим по моему мнению он не является ни в каком виде. Вот поэтому я не взял бы на работу такого абапера, который не понимает базовых основ в системе в той функциональности на которую он по видимому претендует. Ну это тоже самое, что математик пишет 2 + 2 = 5, на вопрос продемонстрировать операцию сложения. Как говорится а что тут такого, мы же про знак плюс, а не правильность написанного действия.

а можно вопрос немного переиначу:
что делать, если такой человек уже принят? и он уже формирует архитектуру и выдает ТЗ и уверен, что он прав, и уверяет других, что так лучше?
и там уже не 2 + 2 = 5, там 2 + 2 = 'ЛучшийВмиреОтвет подбери себе сам и с музыкой'.
Изменение данных таблиц через отладчик или ФМ (19)

Комментарий от  

Олег Точенюк

  |  27 августа 2020, 20:24

Олег Точенюк 04 августа 2020, 18:17

Если человек делает такую таблицу, не возьму, потому что... ну короче вы тоже похоже не поняли в чем проблема? Это знаете как для примера как выглядит знак сложения в арифметике написать 2 + 2 = 5, потому что мы сейчас не об правильности суммирования, а о демонстрации как выглядит знак суммирования. Я правильно вас понял, вы такого математика возьмете, так как ну подумаешь, что оно там написало, оно же знак сложения демонстрировало, да?

Ну что же раз желающих дать правильный ответ нет, или они очень заняты, напишу почему нет. В системе S/4 как и в предыдущих системах SAP ECC, завод всегда однозначно связан с балансовой единицей, через связку таблиц T001W - T001K - T001 следовательно, если кто-то делает таблицу, где ключами выступают поля БЕ + Завод, этим самым человек показывает свое абсолютное непонимание схемы БД в части логистики, а с другой стороны, ну раз он использует в примере, такую связку, то видимо он представляется всем как специалист по абап в области логистики, коим по моему мнению он не является ни в каком виде. Вот поэтому я не взял бы на работу такого абапера, который не понимает базовых основ в системе в той функциональности на которую он по видимому претендует. Ну это тоже самое, что математик пишет 2 + 2 = 5, на вопрос продемонстрировать операцию сложения. Как говорится а что тут такого, мы же про знак плюс, а не правильность написанного действия.
Изменение данных таблиц через отладчик или ФМ (19)

Комментарий от  

Олег Точенюк

  |  04 августа 2020, 18:17

Александр Носов 04 августа 2020, 12:46

А разве для демонстрации программы должна быть "правильная" таблица?
Программистов, использующих foo и bar в примерах тоже на работу не возьмете? :)

Если человек делает такую таблицу, не возьму, потому что... ну короче вы тоже похоже не поняли в чем проблема? Это знаете как для примера как выглядит знак сложения в арифметике написать 2 + 2 = 5, потому что мы сейчас не об правильности суммирования, а о демонстрации как выглядит знак суммирования. Я правильно вас понял, вы такого математика возьмете, так как ну подумаешь, что оно там написало, оно же знак сложения демонстрировало, да?
Коротко о разном. Новые примеры наиболее успешной практики использования SAP MII (1)

Комментарий от  

Олег Назаров

  |  04 августа 2020, 16:25

Добрый день, что это текст, если это ссылка то она не рабочая, как ее использовать.
MVC и обработка событий (7)

Комментарий от  

Александр Носов

  |  04 августа 2020, 16:24

Связь между контроллером и представлением можно ослабить:
1. В контроллер передавать интерфейс представления.
2. Интерфейс представления должен содержать: метод для отображения представления; события взаимодействий с пользователем; контекст (часть модели для отображения).
3. В контроллере нужно реализовать события представления.
4. В конструкторе контроллера нужно подписаться на события представления и связать модель с контекстом представления.
Изменение данных таблиц через отладчик или ФМ (19)

Комментарий от  

Александр Носов

  |  04 августа 2020, 12:46

Олег Точенюк 04 августа 2020, 11:27

Интересная ссылка на программу автор которой абап освоил (ну в какой-то мере), а вот структуру/схему таблиц БД с которой собственно говоря он работает - нет. Так сказать образец абапера которого я бы на работу брать не рекомендовал, а то ведь назетит всякой ерунды, а вам потом с этим жить. Можете на собеседовании приводить пример таблицы автора ZTEST с вопросом, что в этой таблице не так. Если ничего не ответит, переходите к следующему.
 
Пока писать сам, что не так, не буду, посмотрю на варианты от читателей :-). Так сказать какие могут быть варианты.

А разве для демонстрации программы должна быть "правильная" таблица?
Программистов, использующих foo и bar в примерах тоже на работу не возьмете? :)
Изменение данных таблиц через отладчик или ФМ (19)

Комментарий от  

Олег Точенюк

  |  04 августа 2020, 11:27

Александр Носов 03 августа 2020, 16:08

Я против редактирования таблиц подобными способами, но иногда возникают исключения. Пример из личного опыта. Был перенос запроса с корректировкой выполняемой программы. Возник дамп, образовалась неконсистентность данных. Требовалось оперативно поправить статусы в документах для исправления ошибок.
P.S: Если нет прав на отладку, можно воспользоваться аналогом SE16N: sapboard.ru/forum/viewtopic.php и abap4.ru/zse16n.html

Интересная ссылка на программу автор которой абап освоил (ну в какой-то мере), а вот структуру/схему таблиц БД с которой собственно говоря он работает - нет. Так сказать образец абапера которого я бы на работу брать не рекомендовал, а то ведь назетит всякой ерунды, а вам потом с этим жить. Можете на собеседовании приводить пример таблицы автора ZTEST с вопросом, что в этой таблице не так. Если ничего не ответит, переходите к следующему.
 
Пока писать сам, что не так, не буду, посмотрю на варианты от читателей :-). Так сказать какие могут быть варианты.
Изменение данных таблиц через отладчик или ФМ (19)

Комментарий от  

Александр Носов

  |  03 августа 2020, 16:08

Я против редактирования таблиц подобными способами, но иногда возникают исключения. Пример из личного опыта. Был перенос запроса с корректировкой выполняемой программы. Возник дамп, образовалась неконсистентность данных. Требовалось оперативно поправить статусы в документах для исправления ошибок.
P.S: Если нет прав на отладку, можно воспользоваться аналогом SE16N: sapboard.ru/forum/viewtopic.php и abap4.ru/zse16n.html
Использование механизма разграничения (Accrual Engine) для ведения параллельного учета (7)

Комментарий от  

Олег Точенюк

  |  28 июля 2020, 18:31

Ирина Алмоян 21 июля 2020, 23:35

Почему рисунки не отображаются?

Ну вот картинки исправили, все должно отображаться.
Использование механизма разграничения (Accrual Engine) для ведения параллельного учета (7)

Комментарий от  

Олег Точенюк

  |  23 июля 2020, 08:25

Ирина Алмоян 21 июля 2020, 23:35

Почему рисунки не отображаются?

Да часть картинок куда-то пропала. Сейчас попробуем узнать.