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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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