2 ответов в теме

[esselesse]

Ограничения скорости доступа к сервисам CREST

CCP FoxFour | 2014-11-18 14:15 | Тут могла быть ваша реклама.

 

(Прим. переводчика: о CREST можно почитать тут: http://eve-ru.com/blogs/devblog/853 )

Начиная писать вступление к этой статье, я хотел начать вступление со слов "Привет разработчикам", после чего я не мог думать ни о чем, кроме как о РАЗРАБОТЧИКАХ, РАЗРАБОТЧИКАХ!.. Разбив в конце концов лицо об клавиатуру в попытках переключиться на какие-нибудь другие мысли, я так и не смог придумать более оригинального вступления.

 

КЭШИРОВАНИЕ В CREST

 

Прежде чем мы поговорим об ограничениях скорости доступа, хотелось бы коснуться темы кэширования в CREST. Недавно я писал в дев-блоге о некоторых изменениях касаемо вышеупомянутой темы. Эти изменения затронули конфигурацию NGINX - первое просто увеличивало размер кэша, а вторым были некоторые подготовительные работы, результаты которых проявились в Фебе.

 

До Фебы мы могли замерять время кэширования CREST лишь в секундах - этот процесс был реализован с помощью декоратора на языке Python. Это означало, все обращения к этому ресурсу получали результаты, полученные в одно и то же время кэширования. К примеру, если мы пытаемся закэшировать что-нибудь навроде рыночной истории, мы устанавливаем размер кэша на 1 час (В смысле, в кэш пишется история всего лишь одного часа рыночной истории в день - Прим. переводчика). К сожалению, в таком случае рыночная история не изменяется в течение дня - это происходит только в полночь по UTC. 

 

 Поэтому постоянно получается так, что при обращении к ресурсу в течение дня мы получаем одни и те же результаты - так как кэшевый 1 час истек.  Если, допустим, какое-либо действие было совершено не в полночь, а, скажем, где-то в 2 часа ночи - то точка отсчета нового подобного события сдвинется на 2 часа в следующие сутки.  Что не есть хорошо. 

 

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

 

 

Эти изменения в CREST были запущены в Фебе, и их результатом стала существенная разница в количестве кэш-попаданий - что для разработчика есть хорошо. И - так как я знаю, как вы любите всякие графики - вот вам граф кэш-попаданий для всех HTTP200 запросов к CREST:

 

Очень большие изменения наблюдаются в графике истечения срока кэша. Те, что все-таки попадают в эту категорию, в большинстве своем из тех, что запрашиваются в час ночи по UTC и затем много позже днем, когда кэш уже просрочен. С кэшем, длящимся до полуночи, стало меньше проблем.

 

НОВЫЕ ОГРАНИЧЕНИЯ СКОРОСТИ ДОСТУПА

 

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

 

Обращений в секунду: 30

Размер бурста: 100

 

 

Надеюсь, что это сделает вашу жизнь чуть более проще, лучше, и поможет вам делать побольше всяких крутых штук!

 

CCP FoxFour

Команда Size Matters (Размер Имеет Значение).

 

P.S. Эту простую картинку делали ну явно не 30-40 минут и явно не 3 человека, изучающие язык R. Честно-честно.

 

 

Спасибо Sarah Cor и хомосапиенс за помощь в переводе.

Спасибо Denadan за приказ о расстреле.

Сообщение отредактировал esselesse: 13 March 2015 - 0:24
красный цвет. рассстрелять!

[хомосапиенс]

 

(прим. переводчика - над переводом следующего предложения я не задумывался.)

p.s. эта картинка НЕ заняла по 30-40 минут у разработчиков, учаищихся говорить R. Клянусь.

that graph so didn't take 3 devs 30-40 minutes learning R to create... I swear.

 

R - язык для статистического анализа, чтоб делать такие картинки. Так что не говорить

[esselesse]

 

подправил, спасибо большое