Оптимизация производительности Smart Client

Question

У меня есть умный клиент (WPF), который выполняет вызовы к серверу va services (WCF). Экран, над которым я работаю, содержит список объектов, которые он загружает при вызове конструктора. Я могу добавлять, редактировать и удалять записи в списке.

Как правило, после каждого добавления или удаления я перезагружаю всю модель из службы снова, для этого есть ряд причин, в том числе тот факт, что данные могли изменяться на сервере между вызовами.

Этот подход оказался большим ударом по производительности, потому что я загружаю все, что посылает список вверх и вниз по проводу в Add and Edit.

Какие другие опции открыты для меня, нужно ли мне отправлять только необходимую информацию на сервер и как мне не загружать все данные снова при выполнении добавления или удаления?

Answer 1

Оптимальный способ сделать то, что вы описываете (я предполагаю, что вы знаете, что клиент / серверный ввод-вывод уже является узким местом), это отправлять только изменения в обоих направлениях после заполнения клиента.

Это может быть просто, если вы применили модель ведения журнала для обновления данных. Чтобы любой процесс мог внести изменения в общие данные, он должен создать транзакцию с меткой времени, которая будет добавлена ​​в журнал. Обновление данных выполняется методом, который применяет транзакцию к данным.

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

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

Answer 2

1. Убедитесь, что эта функция хорошо инкапсулирована, чтобы вы могли играть с ней, не касаясь других компонентов.
2. Держите ваш источник под контролем версий и часто проверяйте.
3. Я настоятельно рекомендую иметь набор автоматических модульных тестов, чтобы убедиться, что все работает, как и ожидалось, перед рефакторингом и продолжает работать, когда вы выполняете каждое изменение.
4. Если снижение производительности происходит при передаче данных сервером-> клиентом, помимо запросов, обработки и дискового ввода-вывода на сервере, вы можете подумать о разработке хэша данной коллекции или графа объектов и передаче хэша к методу службы на сервере, который запрашивает и вычисляет хеш из БД, сравнивает хэши и возвращает true или false. Только если false вы перезагрузите данные. Это работает, если изменения маловероятны или нечасты, потому что для получения данных требуется два вызова, когда они изменились. Если изменения в БД вызывают беспокойство, вы можете не захотеть получать изменения только тогда, когда пользователь изменяет или добавляет что-то - это может быть совершенно отдельное действие, основанное, например, на таймере. Ваша стратегия параллелизма действительно зависит от ваших данных, количества пользователей, вероятности того, что несколько пользователей будут заинтересованы в одновременном изменении одних и тех же данных и т. Д.