| 0
- 19.11.2012 - 18:02
|
Заказчик заказал небольшой блок "црм" в связке с БП - (один документ 2 справочника - кроме отчетов не используют практически никаких данных из основной конфы - а наоборот - основная конфа БП 2.0 может тянуть для себя данные из этого блока). Решил раз скоро все равно БП 3.0 и УФ пусть сразу будет этот блок на УФ (заодно и разберусь, что это такое). Основная работа с блоком закончена, решил протестировать блок на предмет жора памяти: запустил три окна 1.толстый клиент - в нем открывал УФ блока; 2.тонкий клиент - в нем открывал УФ блока; 3.толстый клиент - в нем открывал обычные формы этого блока (набросал быстро специально для теста).     | | |
| 1
- 19.11.2012 - 18:04
|
вот результат: получается что УФ жрут в разы больше памяти чем обычные формы. Это так и должно быть или я неправильно все спроектировал? и где этому можно найти "научное" обоснование? а то не раз встречал мнение, что УФ это "рост" производительности | | |
| 2
- 19.11.2012 - 18:04
|  | | |
| 3
- 19.11.2012 - 18:07
| конфа на SQL, релиз платформы 15.294 (попутно вопрос: влияет ли это на результат теста?) | | |
| 4
- 19.11.2012 - 18:10
|
вот например: Поддержка управляемых форм для платформы 8.2 Начиная с версии 3.1 система "Гермес" поддерживает полную реализацию управляемых форм. Использование управляемых форм на платформе "1С-Предприятие 8.2" обеспечивает высокую гибкость, настраиваемость, масштабируемость, производительность и эргономичность работы конфигураций, поддерживает работу в режиме тонкого и веб-клиента, работу пользователей через Интернет, в том числе и по низкоскоростным каналам связи. http://mt-labs.ru/hermes/form у них говорят высокая производительность... а у меня нет ;((( | | |
| 5
- 19.11.2012 - 20:02
| Родной ты чего мерял-то? | | |
| 6
- 19.11.2012 - 20:12
| 5-Reaper >оперативную память (чисто по диспетчеру задач) | | |
| 7
- 19.11.2012 - 20:33
| Как количество выделенной операционный системой для процесса памяти связано с производительностью в твоем сознании? | | |
| 8
- 19.11.2012 - 20:45
| Цитата:
| | |
| 9
- 19.11.2012 - 20:49
|
да никак особо не связано в моем сознании... есть тока одна проблема: есть одна большая конфигурация (не та о которой речь в 0) вот в ней пытаются переписать обычные формы на управляемые - сейчас переписано примерно треть в основном списки справочников: все это вертится в терминале на сервере 32 гб, 120 пользователей - раньше для работы им хватало гигов 17-18, сегодня столкнулись с тем что каждый пользователь схавал около 300 метров - кто то больше кто то меньше - на сервере невозможно стало работать - в конечном счете упала производительность конфигурации (все тупо висело)... Вот я затеял это тестирование что бы понять, связано ли это напрямую с УФ или нет. Найти "научное" доказательстов что УФ жрут память пока не могу... | | |
| 10
- 19.11.2012 - 21:31
| (9) Дело было не в бабине. Для начала нужно провести аудит форм на предмет корректности. Я и сам попервоначалу таких уродов делал - мало никому не казалось. Во-вторых раньше чем прекратите использовать клиент обычного приложения - облегчения не ждите. Комбинированный режим обычных и тонких форм тупит жестко. А на тонких клиентах всех надо изгонять из терминала, нечего там пастись. | | |
| 11
- 19.11.2012 - 21:38
|
10-Reaper >касательно 9 там уроды еще те... эту тему лучше не развивать... меня интересует именно результат теста в 2... по каким причинам происходит увеличение используемой памяти? до каких пределов это будет происходить? по каким принципам нужно проектировать формы что бы минимизировать этот "жор"? где об этом читать? | | |
| 12
- 19.11.2012 - 21:47
|
По естественным. Клиентский контекст пополняется динамически, по мере обращения к модулям. Возросший трафик памяти говорит только о попытке оптимизировать сборщики мусора. По поводу памяти советую не морочиться. Гораздо полезнее почитать: http://v8.1c.ru/metod/books/book.jsp?id=231 | |
Интернет-форум Краснодарского края и Краснодара |
