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