Виталий Балахнин, ну, это очень мало, 64 игрока, каждый допустим даже по 1 КБайту, получается 64 КБайт на сервер и даже если ты будешь опрашивать все одновременно, уложишься в 50МБайт и перебирать 64 сущности за запрос и так 600 раз - это вообще не много. Надо смотреть, что не так с твоим решением, ты где-то используешь слишком много лишней памяти. Пробовал использовать memory profiler?
Антон Р., ну, интернам платят, они даже ещё не джуны. А если хочется поработать бесплатно, то лучше уже Open-Source, так можно будет написать в резюме делал коммиты в такие-то проекты, и код можно будет показать и опыт будет и полезное для общества дело.
Виталий Балахнин, и кст, если запросы на обновление происходят часто, то я бы для этого пользователя хранил список из N серверов, где он был и в первую очередь опрашивал эти сервера.
Виталий Балахнин, я имел ввиду по ID пользователя, т.е. "getUserById(serverId, userId)" или никнейму, не суть. Если только список, то твой метод решения единственно верный, просто надо оптимизировать, не хранить лишнее, использовать все потоки, т.е. создать N event loop'ов(в Go такой функционал будет из коробки например). Какого размера данные приходят? Я имею ввиду ответ сервера, сколько в этом массиве пользователей и сколько данных на каждого пользователя отдаёт сервер? Есть ли возможность в апи выбрать только нужные тебе поля? А установить limit и offset в запросе?
> Виталий Балахнин, Я бы сначала весь список записал к себе в БД.
> А потом в этой базе и искал игроков, там мне кажется будет намного эффективнее, раз тебе отдают весь список игроков))
нет, на задаче найти одного пользователя не будет, только лишняя трата памяти и тактов процессора
> К примеру абстрактная таблица сотрудников с их фио, табельными номерами, должностями и фотографиями... а каждое фото из-за усердия кадровички - 56мегапиксельный tiff)
Тут уже проблемы не в "select *", а в том, что фото хранятся в БД и при этом не сжимаются.
