Comments 35
Честно говоря не первый раз натыкаюсь на эти сервисы но так и не понял зачем их юзать. Вот простой небольшой проект. На нем чат. Зачем мне юзать эти пушеры если я просто делаю выборку из базы и кешу ее на пару секунд скажем. Или что-то подобное.
Подскажите тугодуму где они скажем ОЧЕНЬ нужны? Потому что я видимо что-то упускаю.
Подскажите тугодуму где они скажем ОЧЕНЬ нужны? Потому что я видимо что-то упускаю.
Без сарказма, правда хотелось бы понять. Может действительно пригодится.
Для реализации реал-тайм и стрима. Иначе придеться ставить свой сервер, поддерживать разные протоколы веб-сокетов, флабек для других версий и т.п. инфраструктуру.
Ну что значит реал-тайм, стримы? Какой-то постоянно обновляемый элемент (блок с текстом скажем) на сайте? Ну я через jquery буду делать ajax-запрос раз в секунду например к пхп-скрипту и все. Или речь идет о чем-то другом?
~100 запросов в секунду от 100 пользователей, мистер да вы самоубийца.
Ну тут можно навскику даже несколько вариантов придумать. Обращаться к мемкешу, или демоном ложить сформированный хтмл файликом а клиенты будут его подтягивать, без пхп и базы вообще. Наверняка куча хороших решений на просторах сети есть.
В чем преимущество именно использования описанных сервисах? Именно когда очень большие нагрузки и чтобы не париться а быть уверенным что все будет тип-топ работать видимо?
В чем преимущество именно использования описанных сервисах? Именно когда очень большие нагрузки и чтобы не париться а быть уверенным что все будет тип-топ работать видимо?
Довод понятный — возможно кому-то легче мемкаше поднять и написать скрипт, а кому то зарегистроваться на сторонем сервисе, почитать доки, и написать скрипт.
Маштабируемостьразве что на стороннем сервисе должна легче решаться, без головной боли. Два мемкеша настроить на двух серверах под один апликайшен сервер — ето не в два раза больше заплатить на сторонем сервисе.
Маштабируемостьразве что на стороннем сервисе должна легче решаться, без головной боли. Два мемкеша настроить на двух серверах под один апликайшен сервер — ето не в два раза больше заплатить на сторонем сервисе.
Почитайте для начала статейки про сокеты, про Node.js и прочие подобные штуки. Тогда вопросы отпадут сами-собой.
Все простые решения работают до определенного момента. Дальше они не работают, а работает то, что описал автор. За что ему и спасибо.
Для разработки данного функционала уйдет более 2-3 недель если окончательно. Если Ваш рабочйи день оплачивается ~$100 то это крайне не выгодно.
а в чем проблема? Живой пример — 8 ядерный дедик отдает 30мегабит в пике с лоад аверайдже менше 0.4, в скрипте около 30 запросов к одной таблице, и 3 закешированых в мемкаше запроса к двум таблицам. Проблемы были сначала, после анализа все решения, где накапливалось больше ляма рекордов в таблице пришлось выбросить или переделать под мемкаше.
Сервер покруче думаю без проблем отдаст гигабит.
В посте решение без примера — поєтому и решение непонятно. Цитата с поста явное преувеличение- «Но вопрос о реал-тайм взаимодействии с пользователями сайта стоит остро прочти для любого проекта» — попробую придумать пример — таньчики онлайн:
Есть 1000 полигонов, на каждом по 10 игроков. Существует риск пиковых нагрузок в 10000 полигонов. Также каждый игрок может редактировать свой профайл. Милион пользователей в базе, активных 100 тисяч, играют в среднем 10к.
Я так понимаю автор описывает проблему взаимодействия игроков на полигоне.
Сервер покруче думаю без проблем отдаст гигабит.
В посте решение без примера — поєтому и решение непонятно. Цитата с поста явное преувеличение- «Но вопрос о реал-тайм взаимодействии с пользователями сайта стоит остро прочти для любого проекта» — попробую придумать пример — таньчики онлайн:
Есть 1000 полигонов, на каждом по 10 игроков. Существует риск пиковых нагрузок в 10000 полигонов. Также каждый игрок может редактировать свой профайл. Милион пользователей в базе, активных 100 тисяч, играют в среднем 10к.
Я так понимаю автор описывает проблему взаимодействия игроков на полигоне.
а в чем проблема? Живой пример — 8 ядерный дедик отдает 30мегабит в пике с лоад аверайдже менше 0.4, в скрипте около 30 запросов к одной таблице, и 3 закешированых в мемкаше запроса к двум таблицам. Проблемы были сначала, после анализа все решения, где накапливалось больше ляма рекордов в таблице пришлось выбросить или переделать под мемкаше.
Сервер покруче думаю без проблем отдаст гигабит.
В посте решение без примера — поєтому и решение непонятно. Цитата с поста явное преувеличение- «Но вопрос о реал-тайм взаимодействии с пользователями сайта стоит остро прочти для любого проекта» — попробую придумать пример — таньчики онлайн:
Есть 1000 полигонов, на каждом по 10 игроков. Существует риск пиковых нагрузок в 10000 полигонов. Также каждый игрок может редактировать свой профайл. Милион пользователей в базе, активных 100 тисяч, играют в среднем 10к.
Я так понимаю автор описывает проблему взаимодействия игроков на полигоне.
Сервер покруче думаю без проблем отдаст гигабит.
В посте решение без примера — поєтому и решение непонятно. Цитата с поста явное преувеличение- «Но вопрос о реал-тайм взаимодействии с пользователями сайта стоит остро прочти для любого проекта» — попробую придумать пример — таньчики онлайн:
Есть 1000 полигонов, на каждом по 10 игроков. Существует риск пиковых нагрузок в 10000 полигонов. Также каждый игрок может редактировать свой профайл. Милион пользователей в базе, активных 100 тисяч, играют в среднем 10к.
Я так понимаю автор описывает проблему взаимодействия игроков на полигоне.
Зачем делать раз в секунду запрос от клиента к серверу, если сервер может сам раз в час сообщить клиенту, что произошло событие, о котором клиенту нужно знать?
Бог с ней нагрузкой на сервер, а пользовательский трафик? Пускай 256 байт запрос и 256 ответ, 512 байт в секунду, 30 КБайт в минуту, 1,8 Мбайт в час, а это, например, почти 15 руб на моем тарифе в телефоне.
Бог с ней нагрузкой на сервер, а пользовательский трафик? Пускай 256 байт запрос и 256 ответ, 512 байт в секунду, 30 КБайт в минуту, 1,8 Мбайт в час, а это, например, почти 15 руб на моем тарифе в телефоне.
Сообщение там пришло, тут лайкнули фотографию, здесь запрос в друзья пришел… «Дешевле» все это добро доставлять, через Push сервисы, чем каждую секунду стучаться аяксом.
Facebook же стучит аяксом?
Дешевле стучаться к кому-то, чем к себе. И там не просто периодический аякс, а просто длинные запросы, которые крутятся на сервере пока не появится ничего нового.
Посмотрите контакт, он немного впереди фейсбука по используемым технологиям.
ага, хороший пример, хорошо бы автор себе в статю утянул.
пуш сервисы это несколько более широкое понятие нежели просто чат. Но конечная суть та же, обмен сообщениями, только не обязательно между людьми. Формат их можер разниться, отправляться и приниматься они могут по разным каналам и протоколам, читаться/писаться разными людьми или процессами, нагрузка доходить до сотен тысяч в секунду. Храниться это все будет где то где много места и каналы широки. Если Вас устраивает чат на десяток пользователей Вам это пока не надо. Это для тех у кого напр. суппорт атакуют десятки тысяч клиентов, где ответы им удобно группировать в каналы и сообщения по темам (одно на сотню идентичных вопросов), где надо осуществлять предварительную маршрутизацию сообщений (напр. подходящая тема подходящему специалисту суппорта). Причем все это в автомате итп. На самом деле целая наука требующая нешуточных знаний и опыта. Насколько я понял автор попытался дать общий API для разных сервисов дабы можно было ими всеми пользоваться из одного проекта выбирая более подходящий сервис для каждой конкоретной задачи. Вот так если в 2х словах. За это ему и плюсик. Все интереснее нежели очередной обзор как открыть 2 крышки ноута дабы увеличить его память. Чесслово, последнее время, хотелось бы поменьше массы, побольше качества на хабре. И эта статья, на мой взгляд, вполне интересна и заслуживает внимания. С Уважением с Хаброобчеству. Михаил.
В первый раз слышу о подобных сервисах, как-то мимо меня они прошли (видимо потому что гуглил по php push library :( ), хотя идея очень интересная. И как раз столкнулся с необходимостью разбираться с чем-то вроде Dklab_Realplexor. А тут статья на тему как обойтись без него :)
Можно несколько вопросов о подробностях общих, чтоб не лазить по документации каждого?
1. Безопасность (аутентификация, авторизация). Допустим чат с приватными каналами. На своем сервере я бы проверял права доступа к каналу по session_id, откуда бы вытаскивал user_id, role_id, acl, список каналов и т. п. Как на этих сервисах решается? Надеюсь не только по сокрытию имени канала. Read only клиенты предусмотрены?
2. Насколько я понимаю, это получаются cross domain запросы. Что за костыли используются? :)
3. Поддерживается ли транспорт WebSocket хоть одним сервисом?
4.Цена вопроса. Цены посмотрел. Вопросы не снимаются (частично) :)
И вопрос по библиотеке конкретно — насколько трудно будет обернуть свой сервер/демон? Просто по опыту работы с внешними сервисами аутентификации и хранения данных понял, что проще всего и свой «нативный» предоставлять так же как внешний, единственно стараться не по http(s) запросы к нему слать, а через «бинарный» сокет или вообще через вызов функций/методов в реализации общего интерфейса.
Можно несколько вопросов о подробностях общих, чтоб не лазить по документации каждого?
1. Безопасность (аутентификация, авторизация). Допустим чат с приватными каналами. На своем сервере я бы проверял права доступа к каналу по session_id, откуда бы вытаскивал user_id, role_id, acl, список каналов и т. п. Как на этих сервисах решается? Надеюсь не только по сокрытию имени канала. Read only клиенты предусмотрены?
2. Насколько я понимаю, это получаются cross domain запросы. Что за костыли используются? :)
3. Поддерживается ли транспорт WebSocket хоть одним сервисом?
4.
И вопрос по библиотеке конкретно — насколько трудно будет обернуть свой сервер/демон? Просто по опыту работы с внешними сервисами аутентификации и хранения данных понял, что проще всего и свой «нативный» предоставлять так же как внешний, единственно стараться не по http(s) запросы к нему слать, а через «бинарный» сокет или вообще через вызов функций/методов в реализации общего интерфейса.
1 — Везде по разному, обычно решаеться внешней аутенфикацией и по итогам — клиенты работают с несколькими каналами, часть из которых паблик, часть — приватные (по факту уникальности имени канала — и это оправдано, ведь клиент то js, толку там от пароля не очень много). Например, у пушера вот статья об этом: pusher.com/docs/authenticating_users В общем случае — это перекладываеться не на клиентов, а на паблишера — кто отправляет данные, тот проверяет доступы и думает, кому отправить. У нас в partcl наоборот, все клиенты read-only, паблиш данных идет только через приложение. У других обычно смешанная модель (публиковать можно и через HTTP-API и сразу из клиента). У пушера публикация данных из клиента также идет по веб-сокету, авторизация по отдельному аякс-запросу (если отправять данные специфическому клиенту, нужно в конфиге метода сенд указать параметр socket_id). У PubNub-а публикация идет через HTTP-интерфейс, как из клиента, так и с любой внешней библиотеки. Это оправданно, так как все эти сервисы ориентированы на ситуации, когда много читателей, относительно немного публикаций или же частота публикаций у одного автора относительно низкая.
2 — используют техники, для которых это не помеха. Обычно у всех WebSocket, с фалбеком на флеш-вариант. Снова таки, у нас сначала идет самый простой способ — jsonp-polling, а потом, после начала, уже решаем каким транспортом соединиться (флеш-сокеты или нативные веб-сокеты).
3 — Наоборот, вебсокеты это основной транспорт для всех сервисов (исключаем только ioBridge, он специфический).
4 — Касательно своего домена/сервиса — Абсолютно не сложно — надо реализовать AbstractAdapter интерфейс и два метода (конструктор и сенд). окей, вы раскрыли мои планы :) Эта библиотека — часть большого проекта, в процессе написания вторая часть, которая будет предоставлять унифицированный (такой-же) интерфейс к большинству опенсорсных и коммерческих хостед серверов (начиная от DkLab Realplexor, заканчивая коммерческими которые могут принимать данные по AMQP или JMQ). Некоторая сложность в том, что далеко не все сервера уимеют специальный выделенные АПИ (Котерову респект, в его проекте это предусмотрено), поэтому для тех серверов, где нет, будем эмулировать клиента (да, вебсокет клиент на РНР и т.п.).
В итоге, должна получиться одна библиотека (или сервис), который пушит данные любому клиенту, через любой сервис/сеть/транспорт, связываеться с удаленным сервером по любому варианту RPC, поддерживая даже мобильные пуш-сервисы и социальные сети.
если что, пишите вопросы здесь или приватом, думаю смогу что подсказать.
2 — используют техники, для которых это не помеха. Обычно у всех WebSocket, с фалбеком на флеш-вариант. Снова таки, у нас сначала идет самый простой способ — jsonp-polling, а потом, после начала, уже решаем каким транспортом соединиться (флеш-сокеты или нативные веб-сокеты).
3 — Наоборот, вебсокеты это основной транспорт для всех сервисов (исключаем только ioBridge, он специфический).
4 — Касательно своего домена/сервиса — Абсолютно не сложно — надо реализовать AbstractAdapter интерфейс и два метода (конструктор и сенд). окей, вы раскрыли мои планы :) Эта библиотека — часть большого проекта, в процессе написания вторая часть, которая будет предоставлять унифицированный (такой-же) интерфейс к большинству опенсорсных и коммерческих хостед серверов (начиная от DkLab Realplexor, заканчивая коммерческими которые могут принимать данные по AMQP или JMQ). Некоторая сложность в том, что далеко не все сервера уимеют специальный выделенные АПИ (Котерову респект, в его проекте это предусмотрено), поэтому для тех серверов, где нет, будем эмулировать клиента (да, вебсокет клиент на РНР и т.п.).
В итоге, должна получиться одна библиотека (или сервис), который пушит данные любому клиенту, через любой сервис/сеть/транспорт, связываеться с удаленным сервером по любому варианту RPC, поддерживая даже мобильные пуш-сервисы и социальные сети.
если что, пишите вопросы здесь или приватом, думаю смогу что подсказать.
Спасибо за подробный ответ, жаль «повторное голосование запрещено» :)
Предложением воспользуюсь попозже, когда до реализации дело дойдёт. Единственное что сейчас ясно, что каждому клиенту нужен один отдельный канал точно и прослушивание его посторонними (вернее конкурентами) крайне нежелательно, сложность брутфорса должна быть сопоставима со сложностью подделки дефолтной сессионной куки в PHP, а события будут генерироваться сервером в результате обработки очереди заданий. И даже если это будет уведомление типа «клиент такой-то стукнись на сервер, для тебя есть новые данные» то что-то из перехвата таких сообщений (частота, время и т. п.) можно, наверное, получить. Плюс продвинутый чат хочется предложить, как элемент социализации и доступа к поддержке.
Предложением воспользуюсь попозже, когда до реализации дело дойдёт. Единственное что сейчас ясно, что каждому клиенту нужен один отдельный канал точно и прослушивание его посторонними (вернее конкурентами) крайне нежелательно, сложность брутфорса должна быть сопоставима со сложностью подделки дефолтной сессионной куки в PHP, а события будут генерироваться сервером в результате обработки очереди заданий. И даже если это будет уведомление типа «клиент такой-то стукнись на сервер, для тебя есть новые данные» то что-то из перехвата таких сообщений (частота, время и т. п.) можно, наверное, получить. Плюс продвинутый чат хочется предложить, как элемент социализации и доступа к поддержке.
На счет ограничения у pubnub в 1800 символов интересно.
Для меня этот сервис выглядит как идеальное решение, но сие ограничение удивляет.
Ваш клас сейчас это как то решает?
Для меня этот сервис выглядит как идеальное решение, но сие ограничение удивляет.
Ваш клас сейчас это как то решает?
В текущей реализации — нет. В следующей версии (думаю, неделя-две) решит. Со мной уже связывались ребята из пабнаба, буду с ними работать по этому вопросу. Если это только в библиотеке, тогда решим, если же это ограничение самого сервиса, то я со своей стороны сделаю обход (в виде разделения на несколько сообщений и контроль целостности), но это потребует некоторого кода на клиенте, который также будет выложен.
Вообще, думаю в будущем стоит заняться и унифицированной либой для клиентской части :)
Вообще, думаю в будущем стоит заняться и унифицированной либой для клиентской части :)
Честно говоря, от статьи ожидал не только описания сервисов, но и цен.
Sign up to leave a comment.
Единый API на РНР для всех облачных push-сервисов