много серверное веб приложение
количество людей оценивается не по количеству уникальных посетителей в день, а по количеству одновременно играющих.
Чтобы сделать сервер на котором одновременно будет играть порядка 5 тыс чел, скриптовые языки не подойдут, причём прийдётся нехило заморочиться с многопоточностью, так как количество потоков не должно расти пропорционально количеству игроков, иначе сервак загнётся уже после пары сотен.
Чтобы сделать сервер на котором одновременно будет играть порядка 5 тыс чел, скриптовые языки не подойдут, причём прийдётся нехило заморочиться с многопоточностью, так как количество потоков не должно расти пропорционально количеству игроков, иначе сервак загнётся уже после пары сотен.
Чтобы сделать сервер на котором одновременно будет играть порядка 5 тыс чел. одновременно, скриптовые языки не подойдут
Команда friendfeed.com, недавно присоединившаяся к Facebook, выложила в открытый доступ собственный неблокирующий веб-сервер на Python. Из-за своей неблокирующей природы (используется epoll) сервер легко выдерживает тысячи одновременных подключений. У Tornado есть все шансы стать лучшим выбором для реализации технологии Comet средствами языка Python.
http://habrahabr.ru/blogs/python/69346/
http://www.tornadoweb.org/
Я преувеличил с онлайн стратегией. Из игровых взаимодействий будет только что то вроде вызова на дуэль, который будут у игрока происходит от силы раз 10 за неделю...Остальное время в прицнипе в приложении запросы на сервер будут затрагивать только инфу о нем самом.
Питон - это не совсем скрипторвый язык.
Он компилируется в байткод и выполняется в виртуальной машине, наподобие java и c#. Кроме того, связка Flash+PHP - это как правило GET/POST запросы к веб-серверу от флешки с обработкой их на PHP и передачей обратно ответа. Естесственно для этого необходимо при каждом запросе создавать отдельный поток/процесс на сервере.
Он компилируется в байткод и выполняется в виртуальной машине, наподобие java и c#. Кроме того, связка Flash+PHP - это как правило GET/POST запросы к веб-серверу от флешки с обработкой их на PHP и передачей обратно ответа. Естесственно для этого необходимо при каждом запросе создавать отдельный поток/процесс на сервере.
мусье не слышал про fastcgi?
Это не так важно насколько тесное будет взаимодействие пользователей.
Важно как часто будут приходить запросы от клиента и насколько сложна будет их обработка.
Одно дело, когда ты в начале игры подгрузишь некие данные, потом после игры отправишь изменённую статистику на сервер, другое - когда при каждом действии юзера будет запрос на сервер, обработка там например маршрута движения игрока и выдача результата клиенту.
Второе необходимо как в случае тесного контакта между игроками во время игры, так и для просто устранения возможного читерства.
Если в твоём случае на читерство наплевать, то можно реализовать по первому варианту и тогда тысячи людей смогут одновременно играть и при простейшей связке Flash+PHP.
Важно как часто будут приходить запросы от клиента и насколько сложна будет их обработка.
Одно дело, когда ты в начале игры подгрузишь некие данные, потом после игры отправишь изменённую статистику на сервер, другое - когда при каждом действии юзера будет запрос на сервер, обработка там например маршрута движения игрока и выдача результата клиенту.
Второе необходимо как в случае тесного контакта между игроками во время игры, так и для просто устранения возможного читерства.
Если в твоём случае на читерство наплевать, то можно реализовать по первому варианту и тогда тысячи людей смогут одновременно играть и при простейшей связке Flash+PHP.
Насколько я понимаю, как минимум один поток на пользователя всё равно будет. Ну пусть не на каждый запрос. При количесте потоков в несколько тысяч всё сдохнет просто.
неправильно понимаешь
А как правильно?
Пришло сразу два запроса, один направился на обработку запущенному процессу FastCGI, а со вторым что происходит? Для него надо либо создать отдельный процесс/поток FastCGI, либо заставить дождаться выполнения первого запроса.
Пришло сразу два запроса, один направился на обработку запущенному процессу FastCGI, а со вторым что происходит? Для него надо либо создать отдельный процесс/поток FastCGI, либо заставить дождаться выполнения первого запроса.
процессов изначально несколько и они не выгружаются из памяти по окончанию обработки запроса
Так всё-таки процессов или потоков? Если процессов, то как осуществлять взаимодействие между игроками? Через всякие IPC? Да и мгновенно о неком изменении, которое возникло вследствие действий другого игрока нельзя сообщить - только дождавшись следующего запроса. Ну либо делать пустые запросы с неким интервалом.
Да и на закрытие-откытие сокетов при каждом запросе тоже уходят ресурсы.
В общем, использование http с какими бы то ни было приблудами типа fastcgi - это один сплошной костыль. Да и какой смысл в этом? Игры надо писать на простых сокетах.
Да и на закрытие-откытие сокетов при каждом запросе тоже уходят ресурсы.
В общем, использование http с какими бы то ни было приблудами типа fastcgi - это один сплошной костыль. Да и какой смысл в этом? Игры надо писать на простых сокетах.
Так всё-таки процессов или потоков? Если процессов, то как осуществлять взаимодействие между игроками? Через всякие IPC? Да и мгновенно о неком изменении, которое возникло вследствие действий другого игрока нельзя сообщить - только дождавшись следующего запроса. Ну либо делать пустые запросы с неким интервалом.До написания игры тебе еще далеко, ботать и ботать.
Да и на закрытие-откытие сокетов при каждом запросе тоже уходят ресурсы.
В общем, использование http с какимы бы то ни было приблудами типа fastcgi - это один сплошной костыль. Да и какой смысл в этом? Игры надо писать на простых сокетах.
Не волнуйся, через fastcgi я её точно писать не стану. 
изменении, которое возникло вследствие действий другого игрока нельзя сообщить - только дождавшись следующего запроса. Ну либо делать пустые запросы с неким интервалом.нет, это н епланируется. только вызов на "дуэль", сами дуэли в авторежиме.
мне больше интересно как просчитать нагрузки на ключевые элементы системы.
ведь сам сервер еще не начем не запроган - я пока даже не представляю нужно ли много сервервов или хватит одного с терабайтов винта, 16 гигами опперативы и 4 ядрами.
или может надо 16 ядер..
есть ли статьи по данному вопросу?...
мне больше интересно как просчитать нагрузки на ключевые элементы системы.Т.е. тебе нужно узнать, как строить систему — с расчётом на работу на множестве серверов, или на одном?
вопрос того, сколько тебе надо ядер - это очень странный вопрос на данной стадии развития проекта. Но в любом случае начинать проще исходя из предположения, что все поместится на один физический сервер, ну а далее по необходимости если будет серьезная нагрузка как-то решить этот вопрос тоже.
Одного сервера не хватит 99%, нужен еще как минимум сервер с бэкапом/резервный сервер на случай если главный умрет.
Одного сервера не хватит 99%, нужен еще как минимум сервер с бэкапом/резервный сервер на случай если главный умрет.
ну как бы у тебя игра - самое обычное веб-приложение, так что я не вижу проблемы в разделении её по физическим серверам.
ИМХО проще написать какой-нибудь предварительный вариант серверной части и прогнать на нем нагрузку, тогда все будет гораздо яснее.
ну и разделение по серверам надо начинать с банального:
1. вынести БД на отдельный сервер
2. какой-нибудь ngnix или lighttpd как reverse-proxy и, возможно, раздачи статического контента (на начальном этапе можно даже на том же физическом сервере где рабочий сервер будет работать)
ИМХО проще написать какой-нибудь предварительный вариант серверной части и прогнать на нем нагрузку, тогда все будет гораздо яснее.
ну и разделение по серверам надо начинать с банального:
1. вынести БД на отдельный сервер
2. какой-нибудь ngnix или lighttpd как reverse-proxy и, возможно, раздачи статического контента (на начальном этапе можно даже на том же физическом сервере где рабочий сервер будет работать)
Т.е. тебе нужно узнать, как строить систему — с расчётом на работу на множестве серверов, или на одном?В том числе да.
Нужно ли будет вообще заморачиваться на эту тему или можно будет купить (взять в аренде) самый мощный комп с 16 ядрами и 16 гигами оперативы и уже сейчас писать сервер....?
Без написания односерверного варианта и его прогона никак не обойтись?
И еще - где можно почитать про много серверность в данном контексте?
к примеру на том же "вконтакте" разнесены видео аудио картинки - но у нас такого конеткта по минимуму, основная нагрузка будет наверное на БД и на сам сервер (написанный например на php)
Определить точно нужные мощности на данном этапе никак не удастся, т.к. это зависит от кучи изменчивых факторов.
Ты можешь:
1. Почитать саксесс стори крупных проектов. Для того же жж по сети гуляет презенташка, как они скейлились. Это даст тебе представление, как оно примерно будет в конце, и позволит избежать самых примитивных граблей.
2. Писать сразу многосерверное приложение в твоем случае скорее ошибка нежели преимущество. Если бы ты точно представлял, что тебе надо, и уже имел бы обширный опыт в построении такого рода систем - тогда да, возможно удалось бы где-то сэкономить. А так, закладываясь сразу на непонятную скейлебилити, вы рискуете неоправданно переусложнить проект, и не справиться с его написанием.
Ты можешь:
1. Почитать саксесс стори крупных проектов. Для того же жж по сети гуляет презенташка, как они скейлились. Это даст тебе представление, как оно примерно будет в конце, и позволит избежать самых примитивных граблей.
2. Писать сразу многосерверное приложение в твоем случае скорее ошибка нежели преимущество. Если бы ты точно представлял, что тебе надо, и уже имел бы обширный опыт в построении такого рода систем - тогда да, возможно удалось бы где-то сэкономить. А так, закладываясь сразу на непонятную скейлебилити, вы рискуете неоправданно переусложнить проект, и не справиться с его написанием.
1. Для разработки нужны разработчики. Сперва вам нужно запустить систему в принципе. Примеры некоторых решений здесь были приведены, думать тебе самому.
2. Уже ответили.
3. Мало ресурсов. Если кто-то ответит на этот вопрос, будет хорошо. Есть сообщество ru_highload, там оптимизацию обсуждают. Пользуюсь случаем, отмечу http://www.smira.ru/. Там, правда, в основном про видеохостинг.
4. Это статический контент, у тебя задача сложнее.
2. Уже ответили.
3. Мало ресурсов. Если кто-то ответит на этот вопрос, будет хорошо. Есть сообщество ru_highload, там оптимизацию обсуждают. Пользуюсь случаем, отмечу http://www.smira.ru/. Там, правда, в основном про видеохостинг.
4. Это статический контент, у тебя задача сложнее.
ты все пишешь неправильно.
разделение картинок/аудио по серверам никакого отошения к многосерверности не имеет вообще. Это все статика и всем понятно что ее надо сервить отдельно если нагрузка будет хоть какая-то. Начать можно на том же сервере, потом перенесете. Когда говоришь об игре забудь вообще о статике, это отдельный вопрос (и очень простой). Это НЕ многосерверность в данном контексте.
Под многосерверным приложением стоит понимать одно единое приложение, работающее на нескольких серверах. Это если часть ваших игроков попадает на один сервер, часть на другой. В связи с тем, что мир у них единый, должны быть возможности взаимодействия друг с другом - чат, осмотр, еще что-нибудь. Это значит сервера должны друг с другом обмениваться инфой в реалтайме, всякие вопросы синхронизации, вопросы реального расположения серверов (должны быть в одном rack-е в датацентре ну короче куча гемора. Есть конечно полуготовые решения типа memcached, но все равно гемор.
Соответственно само приложение игры разумно писать на одном сервере, надеясь на то, что оптимизациями вы впоследствие сможете отложить разбиение на несколько серверов (или избежать его совсем потому что это реальный гемор. Какие нужны будут оптимизации сейчас вам никто не скажет. Кроме совсем очевидных вещей, типа не используйте БД напрямую в таких приложениях и не пишите на PHP.
разделение картинок/аудио по серверам никакого отошения к многосерверности не имеет вообще. Это все статика и всем понятно что ее надо сервить отдельно если нагрузка будет хоть какая-то. Начать можно на том же сервере, потом перенесете. Когда говоришь об игре забудь вообще о статике, это отдельный вопрос (и очень простой). Это НЕ многосерверность в данном контексте.
Под многосерверным приложением стоит понимать одно единое приложение, работающее на нескольких серверах. Это если часть ваших игроков попадает на один сервер, часть на другой. В связи с тем, что мир у них единый, должны быть возможности взаимодействия друг с другом - чат, осмотр, еще что-нибудь. Это значит сервера должны друг с другом обмениваться инфой в реалтайме, всякие вопросы синхронизации, вопросы реального расположения серверов (должны быть в одном rack-е в датацентре ну короче куча гемора. Есть конечно полуготовые решения типа memcached, но все равно гемор.
Соответственно само приложение игры разумно писать на одном сервере, надеясь на то, что оптимизациями вы впоследствие сможете отложить разбиение на несколько серверов (или избежать его совсем потому что это реальный гемор. Какие нужны будут оптимизации сейчас вам никто не скажет. Кроме совсем очевидных вещей, типа не используйте БД напрямую в таких приложениях и не пишите на PHP.
вопросы реального расположения серверов (должны быть в одном rack-е в датацентре)совсем не обязательно. посмотри архитектуру того же фейсбука. у них бд в одном конце штатов, а кеши в другом, емнип.
БД это не онлайн, это оффлайн. Они туда не пишут ничего в режиме реального времени афаик. Так что не в кассу)
Да, согласен. Не сразу понял, что ты имеешь в виду под «целостным приложением».
Оставить комментарий
356ft85
Планируем разработать приложение на Flash ActionScript (что то вроде онлайн стратегии простейшей) и запрогать сервер (на скриптовом языке PHP/Perl/etc)Как сделать односревернео приложения я в курсе, но вот что делать если в приложении у нас будет например 5 млн. уников в день, как оценить нагрузку на сервер, канал, БД , какой брать хостинг и т.д. - где можно почерпнуть инфу об этом?