Собственно сабж. Предположительно выбор из PHP, Perl, gcc
Разумеется, понимаю что последний — самый быстрый, но и разработка на нем дороже и сложнее. К тому же, классов нет. Также понимаю, что PHP медленен.
Мне же хочется найти компромис между скростью/сложностью/стоимостью разработки и скоростью/надежностью/расширяемостью получившегося продукта.

Здравствуйте, Марат, Вы писали:
М>Собственно сабж. Предположительно выбор из PHP, Perl, gcc
М>Разумеется, понимаю что последний — самый быстрый, но и разработка на нем дороже и сложнее. К тому же, классов нет.
???
С чего так решил?
А по поводу сабжа: что за задача, платформа, поддержка технологий и пр.?

Здравствуйте, Galayko, Вы писали:
G>???
G>С чего так решил?
G>А по поводу сабжа: что за задача, платформа, поддержка технологий и пр.?

Классов нет — имел в виду, что если не плюсовый С брать, то быстрее работает. А по поводу сложности... может я и ошибаюсь, но толкового спеца на С найти дороже, чем на PHP.
По сабжу: зачада — браузерная MMORPG, платформа — freebsd.
Технологии какие имеются в виду?

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

М>Собственно сабж. Предположительно выбор из PHP, Perl, gcc
М>Разумеется, понимаю что последний — самый быстрый, но и разработка на нем дороже и сложнее. К тому же, классов нет. Также понимаю, что PHP медленен.
М>Мне же хочется найти компромис между скростью/сложностью/стоимостью разработки и скоростью/надежностью/расширяемостью получившегося продукта.

Почему не джава?

Здравствуйте, denis.zhdanov, Вы писали:
DZ>Почему не джава?

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

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

М>Здравствуйте, denis.zhdanov, Вы писали:
DZ>>Почему не джава?

М>Предполагается браузерная игра с применением Ajax.
и как это мешает применению java?
вон гуглу не помешало

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

C>и как это мешает применению java?
C>вон гуглу не помешало

Ну как вариант можно рассмотреть конечно. Тогда остается вопрос с производительностью и надежностью — если сравнить с другими языками?

Здравствуйте, Марат, Вы писали:
М>Ну как вариант можно рассмотреть конечно. Тогда остается вопрос с производительностью и надежностью — если сравнить с другими языками?
почитай здесь:
[ANN] 10 презентаций о создании scalable приложений

Автор: Mamut
Дата: 02.05.07

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

М>Собственно сабж. Предположительно выбор из PHP, Perl, gcc
М>Разумеется, понимаю что последний — самый быстрый, но и разработка на нем дороже и сложнее. К тому же, классов нет. Также понимаю, что PHP медленен.
М>Мне же хочется найти компромис между скростью/сложностью/стоимостью разработки и скоростью/надежностью/расширяемостью получившегося продукта.

Как показывает http://highscalability.com/ сейчас вообще неважно на чем писать.

Youtube — это Python + MySQL + lighttpd + Apache
Flickr — это PHP + MySQL + Apache + Perl + Java
Digg — это PHP + Mysql + Apache
MySpace — это сначала вообще Coldfusion + IIS был, сейчас постепенно на ASP.NET + IIS переходят
Basecamp — это Ruby-on-Rails + хз знает что еще (как минимум, Amazon S3)

Сейчас проблема не в языках, а в правильной архитектуре и быстрой и правильной разработке. Если большинство разработчиков хорошо знают PHP, то заставлять их писать на С++ — это самоубийство, например.


ЗЫ. Для browser-based игры вообще важно — чтобы сервак выдерживал большое количество одновременных мелких запросов. Здесь все упрется не в язык, а в сервак. И то пока упрется...

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

C>>и как это мешает применению java?
C>>вон гуглу не помешало

М>Ну как вариант можно рассмотреть конечно. Тогда остается вопрос с производительностью и надежностью — если сравнить с другими языками?

Хорошо. Очень хорошо. Если сравнивать с php и perl. По критерию надежность в сравнении с gcc — просто чудесно.

Но опять же, все зависит от квалификации программистов, сроков и многих других факторов.

C>и как это мешает применению java?
C>вон гуглу не помешало

А где у гугла java?

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

М>Здравствуйте, denis.zhdanov, Вы писали:
DZ>>Почему не джава?

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

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

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


DM>А где у гугла java?
gmail

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

C>gmail

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

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

М>Классов нет — имел в виду, что если не плюсовый С брать, то быстрее работает.
Эта информация очень сильно устарела.
Вобще при сравнимом (до C/C++ == 5/1) колличестве кода (если писать правильно) С++ не редко получается быстрее чем С.
Ибо:
1)Шаблоны + агрессивный инлайн.
2)Исключения быстрее кодов возврата.

Короче С имеет смысл использовать только для экзотических платформ где нифига кроме С и АСМа не работает.

М>По сабжу: зачада — браузерная MMORPG, платформа — freebsd.
Тебе не язык нужен.
Тебе нужен человек который такие проекты успешно создавал.

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

WH>Тебе не язык нужен.
WH>Тебе нужен человек который такие проекты успешно создавал.

Спасибо за совет. Да только в бюджете проекта сумма на консультанта (или опытного gamedev teamlead-а) не заложена. Поэтому учиться придется мне. А где как не на форуме получить бесплатный совет?

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

WH>>Тебе не язык нужен.
WH>>Тебе нужен человек который такие проекты успешно создавал.

М>Спасибо за совет. Да только в бюджете проекта сумма на консультанта (или опытного gamedev teamlead-а) не заложена. Поэтому учиться придется мне. А где как не на форуме получить бесплатный совет?
Проекты, в которых не заботятся о привличении опытных профессионалов в бОльшинстве случаев обречены на провал. К сожалению, ни раз убеждался на собственном опыте. Но... удачи Вам.

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

Здравствуйте, kuj, Вы писали:
kuj>Проекты, в которых не заботятся о привличении опытных профессионалов в бОльшинстве случаев обречены на провал. К сожалению, ни раз убеждался на собственном опыте. Но... удачи Вам.
kuj>P.S. Про C++ советую забыть. Это не язык, который можно взять и с ходу начать программировать, не имея за плечами многих лет опыта.

Ну вообще-то у меня 8-летний опыт программирования на С/С++ (и несколько других языков), только вот отсутствует опыт разработки крупных расширяемых веб-проектов рассчитанных на высокую нагрузку. Собственно именно в области расширяемости и высокой нагрузки и нужен совет.

C>>и как это мешает применению java?
C>>вон гуглу не помешало

DM>А где у гугла java?

Java — один из трех "официальных" языков, используемых в гугле. Два других — Питон и С++

Про gmail я нашел, например, здесь: http://panela.blog-city.com/python_at_google_greg_stein__sdforum.htm:

[Python is used in] а few services including code.google.com and google groups. Most other front ends are in C++ (google.com) and Java (gmail).

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

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

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

Здравствуйте, 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. не надо бояться базу в память грузить полностью — не такие они уж большие как правило. А если реально оч большая, то делается подгрузка данных только для тех кто в онлайне ну и пр. не слишком сложные решения.