shizzard

Ну на такое количество ошибок вполне можно и не обращать внимания. Укладывается в погрешность.

Да, я давно не запускал граббинг пользователей через API. Вполне могу представить, что починено :) А сколько запросов падают на ECONNRESET? Какой процент запросов проходит удачно в целом? Помнится, были такие ошибки, но из было меньше чем REQUEST_LIMIT_EXCEEDED, поэтому я не сильно по этому поводу парился. Рискну предположить, что такие запросы могут падать еще до передачи запроса на обработку в бэкенд, можно пробовать тут же перепослать запрос. Если же таких ошибок немного - можно просто на них забить.

Несколько месяцев назад* Нет, никаких претензий, просто там было описание разных способов планирования запросов, было бы нагляднее.

Я несколько месяцев писал об этом. Не могу найти тот пост, потерли, наверное. В общем, после долгих тестов я начал размазывать запросы по кванту равномерно. Это дало наилучшие результаты, хотя отлупы никуда не делись.

Это спорный вопрос :) Количество активных игроков не так велико. Я поступил так: Сервис делит игроков на "активных" и "неактивных". Неактивные игроки - те, которых нет в базе (возможно, забанены, или просто пустой идентификатор - как я понимаю, пространство идентификаторов на всех региональных серверах одно), или если количество боев давно не изменялось. Впоследствии сервис опрашивает данные активных и неактивных игроков в разных пропорциях - три прогона по активным идентификаторам, один по неактивным. Соотношение можно менять, конечно. Если неактивный игрок так или иначе становится активным и наоборот - переносим его в соответствующее множество. В итоге срезы по активным игрокам идут чаще, чем по неактивным. Помимо этого, большая часть данных по неактивным игрокам не требует операции записи в базу вообще. Скорость обновления базы существенно выросла.

Если у вас dedicated сервер, то вообще не думайте о том, что какие-то там расчеты сильно повлияют на время отклика. Java здесь совсем не при делах. Замеры времени выполнения участков кода реализуются на php так же просто, как и на java: $start = microtime(true); // Your code goes here... $end = microtime(true); $timing = $end - $start; Возможно, где-то что-то напутал, но суть ясна. Вообще раз у вас есть свой сервер, я бы посоветовал вам поставить на сервер graphite и писать метрики туда. Конкретику искать в гугле по запросу "php graphite".

Когда вы пишете софт, не нужно гадать - возьмите и замерьте время вычисления итоговых данных. Думаю, пара вызовов microtime(true) вам в этом поможет. Вообще добавить в ваш код щепотку мониторинга никогда не помешает, это очень дешевый способ диагностики. Побуду капитаном Очевидность: расчеты на shared hosting не имеет смысла выносить в клиент, потому что сетевые запросы блокируют поток выполнения вашего кода и он висит в wait, а расчеты - это CPU-bound задача, время выполнения которой прямо зависит от мощности вашего CPU. С учетом того, что расчеты выполняются гораздо быстрее сетевых запросов, вы тормозов из-за серверных расчетов не заметите. Заметить их можно будет на уж слишком большом количестве запросов, но тогда вы скорее упретесь в другие ограничения shared hosting, нежели в CPU. В таком случае правильным шагом будет переезд на более мощный сервер, но никак не перенос расчетов на клиентскую сторону. TL;DR: допилите мониторинг в свой код и (шлите себе письма|пишите логи) в случае, если время выполнения вырастает до неприемлемого значения. Дальше действовать нужно уже по ситуации.

Я не знаю, как работают такие сервисы. Вполне возможно, что ВГ предоставляет спецлимиты на запросы для таких товарищей - пометка об этом есть в ЛК DPP. Энивей, этот подход (слив данных с серверной стороны) не годится для shared-хостинга.

Хранить данные пользователей на сервере - это большой головняк. Размеры базы будут исчисляться десятками гигабайт, а на cron-скриптах написать вменяемый и стабильный софт, обновляющий базу, невозможно. Это помимо того, что полное обновление базы в вашем случае будет занимать сутки. В вашем случае нет нужды работать с данными на сервере. Вы можете перенести все запросы на клиентскую часть приложения (то есть в браузер), используя такую темную магию, как javascript programming. В таком случае у вас не будет серверных ограничений на запросы. Минус - ваш токен будет открыт и его могут украсть (как и токен WG Assistant, например).

Думаю, что значения на указанных сайтах кешируются. Небольшое отклонение вполне вероятно.

А в чем тогда проблема? Вот здесь: http://wiki.wnefficiency.net/pages/WN8 есть подробнейшее описание процесса вычисления WN-8. Просто вы пишете "что-то у меня не работает", а модуль телепатического чтения кода я дома забыл.

Формула WN-8 считает рейтинг по аккаунту учитывая текущие эталонные значения по всем танкам. Эти данные можно получить по ссылке http://www.wnefficiency.net/exp/expected_tank_values_latest.json, если я не ошибаюсь.

Вопрос действительно очень важный. Можно вас попросить проводить объявления в моменты, когда новый релиз вываливается в продакшен? Желательно с кратким описанием изменений. Так и вы получите нормальный фидбек на свой новый код (потестировать и и метрики снять я завсегда), и мы будем видеть, что работа идет. Я не сомневаюсь, что работа-то идет, но она идет как-то скрыто и незаметно.

Оставьте как есть. Для раздачи статики лучше использовать nginx в качестве прокси, если есть возможность поставить на сервере что нужно. Конфигурирование там несложное, конфиг для раздачи статики лежит на каждом углу.