Высокопроизводительный сервер - что мне использовать? - PullRequest
1 голос
/ 20 апреля 2011

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

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

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

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

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

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

Большое спасибо!

Ответы [ 2 ]

4 голосов
/ 20 апреля 2011

Сайт, который вы используете, чтобы задать этот вопрос, также находится в очень похожем стеке, и они написали об этом на blog.stackoverflow.com, а также в serverfault blog .Возможно, вы могли бы посмотреть, что они делали, но я подозреваю, что вам, возможно, придется взглянуть на какой-то слой кеша.

0 голосов
/ 20 апреля 2011

Помимо SO, еще одним хорошим примером для сайта, который достиг очень высокого масштаба в стеке Microsoft, является PlentyOfFish.com.

Вы можете прочитать об их архитектуре в блоге High Scalability , Coding Horror и других. Погуглив « многообещающего масштабирования », вы обнаружите ряд других источников, а также интервью на эту тему с основателем Маркусом Фриндом.

...