Назад | Перейти на главную страницу

Высокопроизводительный сервер - что мне использовать?

У меня есть большой игровой движок, который обслуживает клиентов для мобильных телефонов и веб-сайт. БД - MSSQL2008, а движок написан на C #.

Веб-сайт построен на ASP.NET MVC, а веб-служба для мобильных телефонов также построена на ASP.NET MVC (вероятно, будет перенесен на WCF или чистый сервер сокетов).

Веб-сайт и веб-служба расположены на сервере IIS 7, а БД расположена на выделенном сервере. Оба подключены к локальной быстрой локальной сети.

Игра требует ответа в режиме реального времени (менее 1 секунды) от каждого пользователя. Когда я провел некоторое нагрузочное тестирование сервиса, оказалось, что у ~ 250 пользователей время отклика составляло 1 секунду (на 50 это было около 200 мс). Он должен поддерживать более 10000 подключенных пользователей. (Я думаю, репликация сервера).

Я подумал о добавлении еще одного слоя - выделенного сервера реального времени для игрового веб-сервиса. Я слышал, что Python можно использовать для создания очень высокопроизводительных сервисов - было бы разумно добавить этот слой? (слой должен иметь временную базу данных в памяти, чтобы обслуживать игроков в реальном времени, а затем выгружать все это во внутреннюю базу данных каждые X секунд).

Моя архитектура хороша? Как это можно было улучшить?

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

  • Большую часть времени SQL-сервер является жестким потребителем дискового ввода-вывода; Само по себе это целая тема оптимизации (схема базы данных, SQL-запрос против StoreProc и т. Д.). Вы можете использовать профилировщик SQL.
  • Используете ли вы какой-либо механизм состояния с помощью веб-службы, если вы используете SQL-сервер для сохранения этого состояния, возможно, это проблема производительности.
  • Вы пробовали профилировать свой код .Net и код SQL-запроса?
  • Если вы отправляете двоичный фрагмент через SOAP, двоичный контент необходимо закодировать в base64, это может вызвать некоторые накладные расходы (сеть и пропускная способность), такие же, как для SSL;
  • Вы спрашиваете себя об использовании менее словесного протокола, кроме WebService / SOAP; возможно протокол HTTP / JSON или даже собственный двоичный.
  • Создание прокси-сервера на python - интересная вещь, но я почти уверен, что вы могли бы реализовать аналогичную концепцию, используя .Net и службу Windows, но вы также можете спросить себя, по какой цене, поскольку, если вам когда-либо понадобится кластеризовать все это, вам нужно будет добавить к этому больше синхронизации и надежности (защиты от сбоев).

Игра требует ответа в режиме реального времени (менее 1 секунды) от каждого пользователя.

И это пользователи мобильных телефонов с различным качеством обслуживания (3G / 3G / 4G / Wi-Fi), приемом, задержкой, джиттером, фрагментацией и т. Д., И вы ожидаете время отклика <1 с? Вы тестировали это с помощью один телефон не говоря уже о сотнях?

Я могу поговорить с частью SQL Server.

Какие у вас есть аппаратные характеристики для этого? Какую версию SQL Server вы используете? Хотя вы можете добавить больше памяти в коробку и сохранить данные в памяти, но это решение не масштабируется через некоторое время. Здесь вам нужно использовать множество передовых методов, если вы хотите масштабироваться для многих пользователей.

Обычные узкие места - это память, ввод-вывод, процессор.

  1. Больше памяти помогает.
  2. Хорошая дисковая система [RAID 10] действительно помогает. Хорошей практикой является разделение журналов данных и транзакций на отдельные шпиндели. В зависимости от количества операций ввода-вывода переместите базу данных tempdb на ее собственные шпиндели и найдите узкие места. Связано ли это узким местом ввода-вывода или распределением. Использование Trace Flag TF 1118 и многих файлов данных tempdb помогает.
  3. Предварительно выделите файлы данных и журналов, чтобы они не увеличивались автоматически во время обычных бизнес-операций.
  4. Начните с хорошей схемы + хорошего кода после тщательной проверки. Дрянной код - это дрянной код, и мусор на входе остается мусором вне зависимости от того, какую платформу вы используете.
  5. Очень хорошо понимать структуру индекса и иметь хороший план обслуживания индекса (обновлять статистику)
  6. Загрузите свой sql-код с большим объемом данных.
  7. Посмотрите на определение узких мест и проблем с производительностью в SQL Server. Здесь очень важна статистика ожидания и статистика виртуальных файлов. Определите, какие процедуры являются дорогостоящими, на основе cu, логического ввода-вывода и большого количества выполнений. Посмотрите недостающие индексы DMV. Научитесь читать данные из кэша планов SQL Server.
  8. Посмотрите на мгновенную инициализацию файла
  9. И здесь так много всего, что сложно перечислить все. Это хорошая отправная точка, но это НЕ исчерпывающий список.

Ссылка: http://dl.dropbox.com/u/13748067/SQL%20Server%202008%20Diagnostic%20Information%20Queries%20%28April%202011%29.sql

http://www.sqlskills.com/BLOGS/KIMBERLY/category/Indexes.aspx

http://www.sqlskills.com/BLOGS/PAUL/category/Indexes-From-Every-Angle.aspx

http://www.datamanipulation.net/sqlquerystress/

  1. Игровые серверы обычно работают по индивидуальному протоколу на основе протокола UDP.
  2. Необходимо сделать этот сервер для этого протокола с нижних уровней, насколько я знаю, нет общедоступного фреймворка или чего-то, что могло бы помочь
  3. Для хранения состояния используйте память или некоторый кеш, а не базу данных SQL