2010-08-08 2 views
8

Я работаю с приложением java Twitter (используя Twitter4J api). Я создал приложение и могу просмотреть текущую временную шкалу пользователей, профили пользователей и т. Д.Превышен предел скорости - Пользовательское приложение для Twitter

Однако при использовании приложения кажется, что он довольно быстро превышает 150 запросов на ограничение скорости, установленное на клиентах Twitter (я знаю разработчиков может увеличить это до 350 на данных учетных записях, но это не будет разрешено для других пользователей).

Несомненно, это не затрагивает всех клиентов, какие-либо идеи относительно того, как обойти это?

Кто-нибудь знает, что считается запросом? Например, когда я просматриваю профиль пользователя, я загружаю объект User (twitter4j), а затем получаю имя экрана, имя пользователя, описание пользователя, статус пользователя и т. Д. Для размещения в объекте JSON - будет ли это одним вызовом для получения объекта или будет ли он включать все вызовы user.get ...?

Заранее спасибо

ответ

4

Вам действительно нужно следить, что ваш текущий счетчик запроса является при работе с Twitter.

Тем не менее, твиттер, похоже, не отбрасывает счетчик на 304 Не изменен (по крайней мере, это не последний раз, когда я имел дело с ним), поэтому убедитесь, что нет какого-либо нарушения нормального использования кеширования HTTP, и ваш практический запрос в час увеличивается.

Обратите внимание, что твиттер страдает от ошибки в mod_gzip на apache, где электронный тег не сформирован при изменении его, чтобы отразить, что кодировка содержимого отличается от кодировки без gzipped (это Right Thing это просто ошибка в реализации). Из-за этого прием содержимого gzipped из твиттера означает, что он никогда не отправит 304, что увеличивает количество запросов и во многих случаях подрывает эффективность использования gzip.

Следовательно, если вы принимаете gzip (ваша веб-библиотека может сделать это по умолчанию, посмотрите, что вы можете увидеть с помощью инструмента, такого как Fiddler, я парень .NET с небольшим знанием Java, отвечая на уровень взаимодействия твиттера с HTTP, поэтому я не знаю деталей веб-библиотек Java), попробуйте отключить это и посмотрите, не улучшилось ли это.

+0

Спасибо за совет - я буду исследовать HTTP-кеширование и убедиться, что я кеширую вызовы соответствующим образом. Мне удалось определить, что значительная часть проблемы заключалась в том, что когда я делал список объектов JSON (например, недавнюю временную шкалу), я извлекал все данные, которые могут понадобиться в дальнейшем (например, для каждого обновления на timeline я получал всю информацию о пользователях, такую ​​как имя/описание/число последователей и т. д.). Я изменил его, чтобы он извлекал только базовые данные для списка, а затем «лениво» извлекал дополнительные данные по мере необходимости. Еще раз спасибо! – rhinds

+0

FWIW, я сообщил об ошибке с взаимодействием между 304 и gzip в твиттере. Так как это ошибка apache, вероятно, она не будет исправлена ​​на их уровне. Ошибка apache уже была известна в apache, когда я обнаружил это в твиттере. –

1

Почти каждый тип чтения с серверов Twitter (т. Е. Все, что вызывает HTTP GET) считается как запрос. Получение пользовательских временных рамок, ретвитов, прямых сообщений, получение пользовательских данных - всего 1 запрос. В значительной степени единственный вызов API Twitter, который читается с сервера, не рассчитывая на ваш лимит API, проверяет статус ограничения скорости.