Начал работать над толстым клиентом для Голоса

Всем привет, прошлые размышления побудили меня начать изучать API Голоса и выстраивать архитектуру будущего приложения.

В комментариях предлагали идти путем инициативы открытого кода, но изучив условия инициативы понял: я под них не подхожу. Ни по списку технологий (у меня php/mysql/mongo/свой движок), ни по условиям разработки. Стало очевидно, что игра "по правилам" будет сильно тормозить меня.

Итак, что буду делать сейчас, по порядку:

• Получения списка пользователей (сейчас их 49130);
• Обновление данных каждого пользователя (баланс, профиль).

Тут же столкнулся с проблемой поиска нормального мануала по работе с WebSocket на PHP. Отталкиваясь от публикации @t3ran13 удалось настроить работу этого класса: https://github.com/Textalk/websocket-php

Много времени ушло на попытки сделать свое решение, в интернете полно сырых исходников для работы с WebSocket, но в большинстве своем они бьются, зависают и т.д. Хотя желание уйти от текущего класса есть (он весит 16 Мегабайт, что для узко-заточенного инструмента очень много), возможно, вернусь к этому вопросу потом. Стоит отметить, что везде упоминается node.golos.ws, хотя сейчас актуальным является только wss://ws.golos.io

Итак, вернемся к получению списка юзеров, тут ничего сложного, советую инструмент http://golostools.ru/explorer/#method=lookup_accounts&params=["","1000"] - достаточно зациклить запрос с смещением и поместить всех пользователей в базу.

А вот получение текущего статуса пользователя - другое дело.  get_accounts возвращает достаточно информации, но некоторые вещи пришлось обдумать. Во-первых, 50к аккаунтов, если запускать сбор/обновление каждую минуту по крону, надо рассчитать скорость и периодичность обновления для 1 аккаунта. Во-вторых, даты похожи на ISO 8601, но это не он, не сразу заметил ошибку в переделке дат в unixtime формат.

Рассмотрим вариант с ростом голоса в 10 раз, 500к аккаунтов. Естественно, большая часть из них проявляет минимальную активность, в связи с чем нужно выставлять приоритет для активных аккаунтов. Для этого подойдут 2 поля в базе данных - время последнего обновления и приоритет. За 1 минуту удается получить информацию по 250 аккаунтам. Думаю, это зависит и от нагрузки на API Голоса, и от активности аккаунта. Задержку между запросом информации я поставил 50 мс, она необходима, чтобы не перегружать собственный сервер (пробовал и 20 мс, и 100 мс - на количество обновленных аккаунтов в минуту особо не влияет).

Что получается - сейчас, чтобы обойти всю базу в 50к пользователей требуется 200 минут (на основе этого и поставил периодичность текущую в 5 часов). Что же будет, если рост Голоса произойдет в 10 раз? 500к юзеров, отдача от API сократится, допустим, в 5 раз. Это 10 000 минут или ~7 суток. Вполне понятно, что это теория и обход для обновления данных аккаунтов будет основываться на их активности. Критичного в этом ничего не вижу, для толстого клиента в самый раз.

В следующий раз планирую начать с архитектуры базы данных постов, комментариев и цикличности обновления. Если вам интересна эта тема и нравится мой слог, буду рад подписавшимся. Постараюсь не "сдуваться" и радовать вас аналитической информацией и данными по разработке толстого клиента для Голоса. Думаю, промежуточный прототип возможно будет запустить уже в июле.