Здравствуйте, Mamut, Вы писали:

М>>>Предполагается браузерная игра с применением Ajax.

_>>в данном случае самым эффективным будет AJAX + С++демон(простенький http-сервер),
_>>при грамотной реализации возможна поддержка нескольких десятков тысяч подключений одновреммено и
_>>отработка 20-30 тыс запросов в сек. на одном, не супер-пупер хосте

M>Ключевое здесь — "грамотная реализация". Я так понимаю, предполагается написание своего веб-сервера? Зачем?

Веб-сервер не нужен, это демон на 80 порту и отрабатывающий необходимый минимум http-запросов от JS, т.е. написанный
специально для него

M>>Ключевое здесь — "грамотная реализация". Я так понимаю, предполагается написание своего веб-сервера? Зачем?

_>Веб-сервер не нужен, это демон на 80 порту и отрабатывающий необходимый минимум http-запросов от JS, т.е. написанный
_>специально для него

Угу, многопоточный, шустрый, fault-tolerant. Зачем?

Здравствуйте, Mamut, Вы писали:

M>Угу, многопоточный, шустрый, fault-tolerant. Зачем?

Угу, у нас есть подобный проект.
Очень эффективно, ресурсоемкость/загрузка невероятно низкая.
Правда, нужны именно грамотные программисты и денежка соответствующая.

M>>Угу, многопоточный, шустрый, fault-tolerant. Зачем?

S>Угу, у нас есть подобный проект.
S>Очень эффективно, ресурсоемкость/загрузка невероятно низкая.
S>Правда, нужны именно грамотные программисты и денежка соответствующая.

В том-то и дело Плюс n человеколет. Не забываем также, что онлайновые игры — это весьма динамично изменяющаяся среда. В них постоянно добавляются новые элементы и изменяются старые. Вывод: придется писать модульный веб сервер, со своим протоколом общения между модулями и опять же со всеми теми же критериями по многопоточности, производительности и устойчивости к ошибкам. Не уверен, что в данном случае овчинка стоит выделки.

Например, MySpace выдержали до полумиллионов учетных записей на двух IIS на Dell-серверах Причем первое, с чем они столкнулись — это производительность именно базы данных. У других примерно такая же проблема. Редко кто упирается в проблемы с сервером или языком.

Здравствуйте, Mamut, Вы писали:

M>Например, MySpace выдержали до полумиллионов учетных записей на двух IIS на Dell-серверах Причем первое, с чем они столкнулись — это производительность именно базы данных. У других примерно такая же проблема. Редко кто упирается в проблемы с сервером или языком.
Имел опыт развертывания системы на 500000 учетных записей на 1 4хпроцессорном серваке. Сейчас аналогичные машинки стоят у народа дома. Сложность конечно была пониже, чем у Online Game, но подтверждаю про перформанс: все упиралось в DBMS.

S>Угу, у нас есть подобный проект.
S>Очень эффективно, ресурсоемкость/загрузка невероятно низкая.
S>Правда, нужны именно грамотные программисты и денежка соответствующая.

И как оно сравнительно с nginx или lighttpd? Сильно превосходит?

Здравствуйте, Schnitzer, Вы писали:

S>Здравствуйте, Mamut, Вы писали:

M>>Угу, многопоточный, шустрый, fault-tolerant. Зачем?
Хватит и однопоточного на неблокируемых.

S>Угу, у нас есть подобный проект.
S>Очень эффективно, ресурсоемкость/загрузка невероятно низкая.
S>Правда, нужны именно грамотные программисты и денежка соответствующая.

Пошел повышения зарплаты просить .

Здравствуйте, Mamut, Вы писали:

M>В том-то и дело Плюс n человеколет. Не забываем также, что онлайновые игры — это весьма динамично изменяющаяся среда. В них постоянно добавляются новые элементы и изменяются старые. Вывод: придется писать модульный веб сервер, со своим протоколом общения между модулями и опять же со всеми теми же критериями по многопоточности, производительности и устойчивости к ошибкам. Не уверен, что в данном случае овчинка стоит выделки.

С таким подходом точно надо n лет. Проще надо думать и быть ленивее — тогда будет все ок.

M>Например, MySpace выдержали до полумиллионов учетных записей на двух IIS на Dell-серверах Причем первое, с чем они столкнулись — это производительность именно базы данных. У других примерно такая же проблема. Редко кто упирается в проблемы с сервером или языком.

Важно не количество записей в базе, а сколько человек в онлайне одновременно. У нас база в несколько миллионов записей (подчти 10) так я ее просто
в память полностью гружу при старте и все летает. Ну надо около 4 Гб оперативки для этого, но сейчас 64-разрядные тачки не экзотика. Есстесно
нужно обеспечивать непротиворечивость с базой, но и это просто решается. А динамика-динамикой, но я думаю что гараздо проще раз в несколько недель
перекомпилить и перезапустить, чем извращаться с модульностью (делал подобные проекты — овчинка выделки не стоит, только конечно если не хотите
позволить пользователям писать свои модули и подключать их ).

P.S. не надо бояться базу в память грузить полностью — не такие они уж большие как правило. А если реально оч большая, то делается подгрузка данных только для тех кто в онлайне ну и пр. не слишком сложные решения.