Существует ли в мире очень большая и крупная база данных, которая время от времени не страдает от проблем с производительностью? Держу пари, что их не так уж много. Поэтому каждый DBA (администратор базы данных), отвечающий за PostgreSQL, должен знать, как отслеживать потенциальные проблемы производительности, чтобы выяснить, что на самом деле происходит.

Повышение производительности PostgreSQL после настройки параметров

Многие думают, что изменение параметров в postgresql.conf — это реальный путь к успеху. Однако это не всегда так. Конечно, чаще всего хорошие параметры конфигурации базы данных очень полезны. Тем не менее, во многих случаях реальные проблемы будут возникать из-за странного запроса, скрытого глубоко в некоторой логике приложения. Даже вполне вероятно, что запросы, вызывающие реальные проблемы, не являются теми, на которые вы обратили внимание. Возникает естественный вопрос: как мы можем отследить эти запросы и выяснить, что на самом деле происходит? Мой любимый инструмент для этого — pg_stat_statements, который всегда должен быть включен по моему мнению, если вы используете PostgreSQL 9.2 или выше (пожалуйста, не используйте его в более старых версиях).

Логирование является очень важным инструментом разработчика, но при создании распределённых систем оно становится камнем, который нужно заложить прямо в фундамент вашего приложения, иначе сложность разработки микросервисов очень быстро даст о себе знать.

В .Net Core 3 добавилась отличная возможность передачи контекста корреляции в HTTP-заголовках, поэтому если ваши приложения используют прямые HTTP-вызовы для межсервисного взаимодействия, то вы можете воспользоваться этой коробочной функцональностью. Однако, если архитектура вашего бекенда подразумевает взаимодействие через брокера сообщений (RabbitMQ, Kafka и т.п.), то вам по-прежнему необходимо озаботиться темой передачи корелляционного контекста через эти сообщения самостоятельно.

В этой статье мы возьмём простое веб-апи приложение и организуем логирование, которое будет

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

• иметь единую точку входа с удобным анализом, чтобы инструментом логирования смогла пользоваться даже Поддержка, к которой летят вопросы вроде «у меня тут в приложении выскочила ошибка с таким-то айдишником запроса»

Введение

В этой статье рассматривались некоторые методы оптимизации LINQ-запросов.
Здесь же приведем еще некоторые подходы по оптимизации кода, связанные с LINQ-запросами.

И снова здравствуйте. В преддверии старта курса «Разработчик C#» перевели интересный материал про assert-сообщения в тестах и с радостью делимся с вами переводом.

---

В этом посте мы поговорим о том, должны ли вы использовать Assert-сообщения в ваших тестах.

Я получил интересный вопрос от коллеги читателя, на котором хотел бы остановиться поподробнее:

У меня вопрос по поводу Assert-сообщений: следует ли использовать перегрузку, содержащую параметр сообщения, и использовать ее для передачи строки, описывающей причину неудачи Assert (также “Утверждения”)?

Доброго времени суток, друзья!

Chrome Developer Tools — очень мощный набор инструментов для разработки веб приложений. С помощью этих инструментов мы можем перемещаться по DOM, осуществлять проверку запросов на сервер, настраивать производительность приложений и др.

Среди множества доступных возможностей, существует несколько по-настоящему интересных. Эти «фичи» помогают делать на один-два клика меньше — разве не для этого мы здесь собрались?

В преддверии старта курса «Разработчик C#» подготовили перевод интересного материала.

---

Async/Await — Введение

Языковая конструкция Async/Await существует со времен C# версии 5.0 (2012) и быстро стала одним из столпов современного программирования на .NET — любой уважающий себя C# разработчик, должен использовать ее для повышения производительности приложений, общей отзывчивости и разборчивости кода.

Async/Await делает обманчиво простым внедрение асинхронного кода и избавляет программиста от необходимости разбираться в деталях его обработки, но многие ли из нас действительно знают, как она работает, и каковы преимущества и недостатки этого метода? Существует много полезной информации, но она разобщена, поэтому я решил написать эту статью.

Ну что ж, давайте углубимся в тему.

У среднестатистической ИТ-компании есть требования, история таск-трекеров, исходники (возможно, даже с комментариями в коде), инструкции на типовые, важные и сложные случаи на проде, описание бизнес-процессов (от онбординга до “как пойти в отпуск”), контакты, ключи доступа, списки людей и проектов, описание зон ответственности — и куча других знаний, о которых мы наверняка забыли и которые могут храниться в самых удивительных местах.


Знания =/= документация. Это нельзя объяснить, это надо запомнить

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

Доброго времени суток, друзья!

Надеюсь, эта статья будет полезна как начинающим разработчикам, так и опытным.

В вопросах, которые показались мне сложнее прочих, приведены ссылки на дополнительную литературу.

Буду признателен за развернутые комментарии. Все замечания будут учтены при редактировании статьи.

Итак, поехали.