Операции ввода-вывода, как правило, являются самыми дорогими по производительности. Это особенно верно, когда вы выполняете дисковый или сетевой ввод-вывод (который обычно является самым дорогим, потому что если вам приходится ждать ответа от другого хоста, вам придется ждать всех операций обработки и ввода-вывода, которые делает удаленный хост ). Выполняйте эти операции только тогда, когда это абсолютно необходимо, и, возможно, рассмотрите возможность использования кэша, когда это возможно.
Операции с базой данных могут быть очень дорогими из-за сетевого / дискового ввода-вывода и времени перевода в и из SQL. Использование БД или кэша в памяти может помочь уменьшить проблемы ввода-вывода, а некоторые (не все) базы данных NoSQL могут сократить время перевода SQL.
Регистрировать только важную информацию. Использование библиотек журналов, таких как log4j , может помочь, потому что вы можете добавить журналирование по своему желанию в свое приложение, но вы устанавливаете каждое сообщение на определенный уровень журнала. Какой бы уровень журнала вы ни выбрали, приложение будет регистрировать сообщения только на этом уровне или выше. Таким образом, если вам нужно устранить неполадки с функциональностью, вам нужно всего лишь изменить быструю конфигурацию и перезапустить приложение, чтобы получить дополнительные сообщения. Затем, когда вы закончите, просто верните приложение на уровень по умолчанию, чтобы вы не регистрировали его слишком часто.
Включать только те функции, которые необходимы. Дополнительные функции могут быть полезны, но могут увеличить время обработки, предоставить дополнительные места для сбоя приложения и стоить вашей команде время, которое может быть потрачено на более важные задачи.
Используйте и настройте ваш менеджер памяти правильно. Процедуры сбора мусора могут снизить производительность, если они настроены неправильно. Если каждую минуту ваше приложение зависает на секунду или две для сбора мусора, ваш клиент, вероятно, не будет счастлив.
Профиль только после того, как вы обнаружили проблему с производительностью. Профилировщики заставят производительность приложений выглядеть хуже, чем она есть, потому что ваше приложение и профилировщик работают на одном хосте, потребляя одинаковые аппаратные ресурсы.
Не выполняйте преждевременную настройку производительности. Существуют общие приемы, которые можно использовать для повышения производительности на каждом языке, но запуск настройки производительности в процессе разработки приложений может дорого обойтись при разработке, поскольку еще есть функциональные возможности, которые необходимо добавить.
Это не обязательно повысит производительность, но сведет зависимость класса к минимуму. Когда вы приступите к настройке производительности, есть большая вероятность, что вам придется переписать целые части кода, которые, если есть много зависимостей от раздела, который вы настраиваете производительность, тем больше вероятность, что вы нарушите код. Часто это может быть эффектом домино, потому что после исправления проблемы с производительностью, вам нужно исправить все зависимости и, возможно, зависимости исходных зависимостей. Оценка производительности на несколько часов может быстро превратиться в месяцы с приложением, которое имеет много зависимостей.
Если речь идет о производительности, не используйте интерпретируемые языки (языки сценариев).
Используйте только необходимое оборудование. Иметь систему с 64-ядерным процессором может показаться классным, но если в вашем приложении работает только два или три потока, то 64-ядерная выгода мало что дает. Фактически, в редких случаях чрезмерное аппаратное обеспечение может иногда снижать производительность, поскольку чипы должны быть подключены для обработки всего оборудования, что может привести к тому, что ваше приложение будет тратить больше времени на переключение между ядрами или процессорами, чем на самом деле.
Любые метрики синхронизации, о которых вы сообщаете, делают как можно более детализированными. В настоящее время вам может потребоваться беспокоиться только о количестве миллисекунд, которые занимает процесс, но в будущем, когда вы сделаете свое приложение все быстрее и быстрее, вам может потребоваться более детальная синхронизация. Если версия A использует миллисекунды, а версия B использует микросекунды, как можно сравнить производительность, если версия B занимает примерно такое же количество миллисекунд? Версия B может быть лучше, но вы просто не можете сказать, потому что версия A не использовала достаточно детальные метрики.