Pull to refresh

Comments 25

Добрый день!
У меня один вопрос, как вы общаетесь с клиентом? Он у вас запрашивает данные или же он подписывается и сервер ему отправляет что-то (дуплекс)?
Добрый! С клиентом общаемся по HTTP, запрос-ответ + Long Polling.
Спасибо, я так и предполагал, еще бы привести код PerfWatch, интересно решение.
Добрый день, а не покажете код PerfWatch?
Добрый! Нет, к сожалению, весь код показать нет возможности, но сами замеры построены на функциях QueryPerformanceCounter и GetThreadTimes
Спасибо. QueryPerformanceCounter — возвращает текущее значение счётчика таймера.
QueryPerformanceFrequency — возвращает частоту таймера (число тиков в секунду).
Все понятно.
Какой у вас используется балансировщик нагрузки между серверами?
Как будете делать масштабирование, когда в этом возникнет необходимость?
Мы используем подход сходный с shards. Данные разделяются на разные базы и хостятся на разных физических серверах. С каждой базой связан игровой сервис (как правило, размещаются на одном физическом сервер, что позволяет достичь минимальных задаржек при работе). Пару база и сервис мы называем сегментом. Пользователи при регистрации распределяются по сегментам и в дальнейшем запросы пользователя идут к нужному сегменту. Для управления сегментами сейчас используем простой подход. Создаем два сегмента на одном физическом сервере и когда нагрузка доходит до определенного нами лимита, мы разносим сегменты на два физических сервера, при этом добавляя по одному новому на каждый. Это не обеспечивает идеальной балансировки, но позволяет достичь более чем достаточного качества и мы пока не сталкивались с проблемами. Если столкнемся, будем рассматривать вариант более умного разделения на сегменты с перебалансировкой пользователей с учетом их активности.
не возникает ли проблемы с растущим объемом взаимодействия между сегментами?
Спасибо за подробный ответ
Не планируете выложить свою либу для сепиализации json?
Спасибо за статью, многие мои догадки и знания из личного опыта оптимизиции производительности получили подтверждение )
Вопрос по логированию — log4cxx на порядок убивает производительность (по CPU), пробовали отключать log4net?
У себя мы не обнаружили такого влияния на прозводительность, о котором Вы говорите. Наоборот, эта библиотека показала себя очень хорошо, она достаточно простая и стабильная.
чистый ADO.NET имеет минимальный оверхед, а все запросы созданы вручную, знакомы и греют душу, он отправляет любые ORM в глубокий нокаут

Наверное имелось в виду использование DataReader, Connection, Adapter, т.е. по-сути .NET Framework Data Providers? Потому как под ADO.NET обычно подразумевают его высокуровневую часть, т.е. DataSet, который внутри еще и XML-based и чудовищно неповоротлив, особенно в сравнении с современными ORM.
Да, верно — мы ограничились использованием Connection, Command и DataReader.
А какие ORM тестировали?
Поговаривают, что, например, у BlToolkit и аналогов оверхед, довольно невысокий.
На тот момент наибольший опыт был в использовании NHibernate и Entity Framework. В целом, мы достаточно легко приняли решение отказаться от использования этих и других ORM. Возможно, современные реализации преуспели в снижении накладных расходов, но у нас до сих пор не возникло желания переходить на их использование.
Спасибо за статью, весьма познавательно.

Расскажите пожалуйста подробнее про зависимости ваших dal/bll/ui уровней. Используются ли в большинстве своём общие сущности или, отказываясь от ORM Вам выгоднее стало использовать уникальные структуры под каждый запрос? Используете конвертеры между уровнями или, может протягиваете dal объекты напрямую до ui? Кэш у вас используется на уровне сервера или вынесен на отдельный или и то и другое? Собираете ли отдельную статистику для профилирования на более высоком уровне(контроллеров допустим) или же стараетесь замерить это при разработке, а в лайве уже мониторите лишь общие цифры? Польуетесь ли async'ами при io операциях? Чем отдаёте статику?

Извиняюсь за сумбур, но действительно интересно.
Сейчас есть уже LINQ2DB, BLToolkit плавно уйдет с арены.
Действительно, производительность там прилично выше, но, это легковесные ORM.
А почему уйдут?
Легковестность в нагруженных проектах — это же преимущество, а не недостаток.
Потому что LINQ2DB занимается Игорь, это пересмотр BLToolkit. В следующий раз почитайте, прежде чем вставить умный комментарий:)
Кстати, уйдут и уйдет разные вещи.
если столько времени тратится на json, может логичней делать бинарную сериализацию? или с вашей библиотекой это уже стало неактуально?
Sign up to leave a comment.