Требования к производительности: пользователи и администраторы
Пользователи оценивают производительность приложения по их опыту:
- Быстро ли приложение отвечает?
- Отображается ли значок песочных часов при выполнении фоновых операций?
- Приложение запускается и закрывается быстро?
- Обрабатываются ли ошибки понятным способом?
Подводя итог, пользователи хотят, чтобы приложения были быстрыми и предсказуемыми.
В отличие от этого, администраторы часто оценивают производительность приложения по тому, насколько эффективно оно использует сетевые ресурсы. Администраторы могут спросить:
- Имеет ли приложение низкие издержки и эффективное использование сети?
- Используется ли минимальное количество подключений, чтобы сервер обслуживал как можно больше пользователей одновременно?
- Я постоянно звоню в службу поддержки?
Короче говоря, администраторы хотят, чтобы приложения масштабироваться.
Рекомендации по обеспечению производительности
При разработке приложения windows Sockets эти требования к производительности преобразуется в полезные правила.
Быстрая инициализация сетевых приложений.
Пользовательский интерфейс не должен ждать ответов сети. Некоторые задачи можно выполнять до того, как сеть станет доступной или без нее. Если сеть не отвечает, пользователю может потребоваться пользовательский интерфейс для простых операций, таких как закрытие приложения.
Не дожидайтесь завершения работы сети.
Правильно написанные клиент-серверные приложения корректно обрабатывают прерывание отключений. Не запускайте потенциально длительную операцию, например синхронизацию файлов или папок с сервером, которая не может быть прервана при завершении работы. Сети не всегда реагируют, поэтому даже небольшие операции могут занять много времени. Предоставление пользователям положительных отзывов, включая сведения о ходе выполнения и предполагаемое время выполнения.
Обеспечьте адаптивный пользовательский интерфейс.
Скорость реагирования приложения помогает избежать ненужных вызовов в службу поддержки. Хорошим ориентиром для интерактивного ответа является 500 миллисекундами. Пользователи воспринимают паузы дольше 500 миллисекундах как задержку в производительности. Приложения должны быть достаточно адаптивными, чтобы предоставить пользователю уверенность в отношении приложения.
Проанализируйте сетевые ошибки.
Не все сетевые ошибки являются критическими. Например, приложение, которое получило или опубликовало все свои данные, скорее всего, может игнорировать ошибки при закрытии подключения. Не предполагайте, что сеть или пользователь доступен; либо обрабатывать ошибки без вмешательства пользователя, либо игнорировать их, если ошибки некритичны.
Приложение должно определять собственные разумные тайм-ауты.
Например, запрос windows Sockets connect() может блокироваться при некоторых условиях на целых 21 секунду. Приложениям может потребоваться вводить собственные тайм-ауты в соответствии с их пользователями.
Сведите к минимуму затраты на протокол.
Экономия пропускной способности сети частично связана с минимизацией нагрузки на протокол, которую несет приложение. Кроме того, речь идет об устранении ненужного сетевого трафика. Для передачи данных приложения можно использовать протоколы с меньшими затратами на заголовки. Например, при отправке небольших объемов некритических или повторяемых данных используйте UDP, а не TCP, чтобы уменьшить затраты, связанные с установлением и обслуживанием подключения. Если одни и те же данные должны быть отправлены нескольким получателям, рассмотрите возможность многоадресной рассылки. Имейте в виду, что приложения UDP не управляются потоком. Отправка за пределы доступной пропускной способности может привести к катастрофическому сбою сети. Служебную программу Netstat можно использовать с параметрами -e и -s для отображения статистики по различным протоколам.
Экономия системных ресурсов.
Если не использовать надлежащие ограничения, системные ресурсы можно быстро использовать. Например, сокеты и TCP-подключения потребляют ресурсы. Не используйте несколько TCP-подключений для каждого клиента, где одно из них будет служить цели приложения.
Для транзакционных приложений хорошее взаимодействие с пользователем и низкий уровень использования сети не являются противоречивыми целями. Сеть является узким местом. Ресурсоемкие приложения тратят больше времени на ожидание, а хорошо написанные сетевые приложения предназначены для минимизации ненужного времени ожидания как для пользовательского интерфейса, так и для передачи данных по сети.
Связанные темы