Pull to refresh

Comments 25

Как разработчики социальных игр, мы отказались от серверов на PHP и перешли на Java.

Ибо пэха — проигрывает как по производительности, так и по удобству (например, в java не придется при каждом запросе дергать БД для считывания инфы об игроке). Да и скорость разработки поднялась, т.к. приходится писать меньше лишнего кода подобного рода.

Я уж не говорю о создании топов игроков на PHP+MySQL, когда чтобы узнать свой рейтинг приходится каждый раз мучить базу запросами типа SELECT COUNT(*) FROM players where score > my_score.
Тоже не дергаем БД. Для этого есть memcached.

По производительности Java выигрывает, не спорю, но не является «серебрянной пулей»

Рейтинги у нас строятся специальным серваком, который под это заточен.

И что касается удобства — пых не требует преобразования типов, да и программистов найти на нем проще.

А если прижмет, то всегда успеем переписать на яву ( ни разу не прижимало, если честно — когда наступала необходимость оптимизировать, денег уже было достаточно чтобы арендовать еще один сервер и не париться о том, что где-то мы потеряли процентов 20 производительности )

и Redis можно использовать :) и Node. часть и на РНР — будет быстрее и достаточно производительно.
Реалтайм-игрушки (где жетская синхронизация нужна в мультиплеере) не прокатят. А таблицу рейтингов дернуть раз в полдня — вполне сойдёт.

До сокетов дойдет дело в любом случае, если проект будет серьезный.
Многие вещи в flex4/as3 писались с оглядкой на Java северные решения, такие как blazeds или LiveCycle. Отсутствие геморроя с каналами, с мессаджингом, и прочим что выходит за базовый RPC, сильно влияет на выбор.
Смотрел и phpamf, pyamf все обеспечивают только минимум, которого впрочем хватает для простых игрушек.

>программистов найти на нем проще
Я бы сказал дешевле.

> Многие вещи в flex4/as3 писались с оглядкой на Java северные решения, такие как blazeds или LiveCycle.

Пруф дайте пожалуйста.
Официальной доки вам хватит? Все примеры и референсы даны для BlazeDS. BlazeDS разработан под крылышком адоба. Аннотации для меппинга на POJO для хранимых объектов.
Интересная технология. Судя по отзывам, довольно шустрая.

Возможно стоит пересмотреть некоторые моменты разработки наших серверов.
UFO landed and left these words here
Последняя версия вышла 2 февраля, поэтому проект AMFPHP еще рано хоронить.

Тоже рассматривали как вариант зенд. Но проанализировав преимущества и недостатки такого подхода, пришли к выводу, что тащить за собой фреймворк и подстраиваться под него ради использования одной его библиотеки не очень хорошо.
а мы изначально ее использовали — оказалось в наш фреймворк встроить вывод еще и в виде AMF оказалось делом нескольких строчек — из-за отличного нового класса Zend_Serialize
Zend_Amf не тащит за собой фреймворк. Его вполне можно использовать отдельно.
Не все так сладко.

Он тащит за собой 5 зависимостей

Zend_Server_Interface
Zend_Server_Reflection
Zend_Server_Reflection_Function_abstract
Zend_Server_Reflection_Method

+ расширение PHP Reflection

framework.zend.com/wiki/display/ZFPROP/Zend_Amf+-+Wade+Arnold?focusedCommentId=7373250

Это для нас очень нежелательно, т.к. каждое расширение PHP увеличивает время ответа и усложняет настройку сервера.

Согласен, то что перечислено выше — используется, но я не особо уверен в том, что даже с этими зависимостями Zend_Amf сильно проигрывает (и проигрывает ли?) по скорости AMFPHP.
Если вы проводили тесты-сравнения — было бы интересно увидеть.
Тесты не проводили.
Просто решили не тащить за собой мертвые зависимости.

Тем более представьте, как бы увеличилась статья, если бы вдруг вместо AMFPHP использовался Zend_amf.

А так все просто

1. Скачал
2. Настроил

PROFIT!
Не поверите, но с Zend_Amf:
1) Скачал (настраивать не надо)
2) Написал $server = new Zend_Amf_Server(); $server->addFunction($mth); $server->handle();
3) Забыл AMF, как страшный сон )

Но тут, как понимаю, уже на вкус и цвет…
Дайте пожалуйста ссылочку на standAlone Zend_Amf — потестирую у себя.
Потестировал.

Прогонял простой вызов hello, который описан в статье
на LVDS-512 от селектела,

ПО:
ubuntu+ngnix+fastcgi+eaccelerator
(Версии не важны, т.к. измерения относительны)

для измерения времени — microtime, для измерения памяти — memory_get_usage

Контрольный прогоны начиная со 101 (чтобы включился кеш и начал работать eaccelerator в полную силу)

Данные заносились в лог, далее усреднялись.
всего контрольных прогонов: 1000

AMFPHP
TIME: 12,3 ms
MEMORY: 50,5 K

ZEND_AMF
TIME: 20,5 ms
MEMORY: 93,6 K

Результат налицо.
Возможно, я не включил полезные оптимизации, но если скажете, что делать, могу повторить тесты.

М… к сожалению туплю — не могу найти по указанной ссылке, какой тест прогонялся?
Завтра также постараюсь погонять тесты, если все так, как вы говорите, то это действительно повод задуматься. Хотя мне кажется, что тут очень сильно все зависит от данных на входе.
ИМХО если на входе простая структура, то по скорости выиграет AMFPHP, а если что-то более сложное, да с ref-ами то Zend…
UFO landed and left these words here
Невнимательно посмотрел. 2 февраля 2010 года — т.е. почти год назад. Вполне вероятно что Вы правы.

Но тем не менее, эта реализация AMF довольно стабильна, удобна в управлении и ни разу нас не подводила (5 проект на ней делаем)

Лучшее — враг хорошего ;)
Плюс Zend_Amf еще в том, что Вы можете оперировать объектами, а не массивами без лишних преобразований. А также использовать логику контроллера (модели) и без AMF, что позволит разрабатывать/тестировать функционал без готовой флешки.

Насчет объектов — спорный момент.
Старый добрый foreach еще никто не отменял.
А тестировать можно и с PHPAMF — в комплекте есть браузер, при должной сноровке которого хватает в 99% случаев.
есть вот такая замечательная штука — sourceforge.net/projects/php-amf3/
тесты не делал, но должно быть гораздо быстрее, правда за это нужно платить установкой ))

кстати не пхп единым, последние проекты делали на python и пользовали pyamf в связке с django и twisted.
очень удобно и результаты более чем удовлетворительны. ))
Sign up to leave a comment.

Articles