Антипаттерн: хранить данные размером более 256 КБ в кеше.

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X.
информация

Apigee Edge предоставляет возможность хранить данные в кеше во время выполнения для обеспечения устойчивости и более быстрого извлечения.

  • Данные первоначально сохраняются в кэше в памяти процессора сообщений, называемом кэшем L1 .
  • Кэш L1 ограничен объемом зарезервированной для него памяти в процентах от памяти JVM.
  • Кэшированные записи позже сохраняются в кэше L2 , который доступен всем процессорам сообщений. Более подробную информацию можно найти в разделе ниже.
  • Кэш L2 не имеет жесткого ограничения на количество записей кэша, однако максимальный размер записи, которую можно кэшировать, ограничен 256 КБ. Размер кэша 256 КБ — рекомендуемый размер для оптимальной производительности.

Антипаттерн

Этот конкретный антипаттерн говорит о последствиях превышения текущих ограничений размера кэша на платформе Apigee Edge.

При кэшировании данных > 256 КБ последствия следующие:

  • Запросы API, выполняемые впервые на каждом из процессоров сообщений, должны получать данные независимо от исходного источника (политики или целевого сервера), поскольку записи размером > 256 КБ недоступны в кэше L2.
  • Хранение больших данных (> 256 КБ) в кэше L1 приводит к большей нагрузке на ресурсы платформы. Это приводит к тому, что кэш-память L1 заполняется быстрее и, следовательно, для других данных остается меньше места. Как следствие, вы не сможете кэшировать данные так агрессивно, как хотелось бы.
  • Кэшированные записи из процессоров сообщений будут удалены, когда будет достигнуто ограничение на количество записей. Это приводит к повторному извлечению данных из исходного источника на соответствующих процессорах сообщений.

Две блок-схемы.   Один для размера <= 256 КБ, который показывает потоки между прокси-сервером API и процессорами сообщений, а также потоки между процессорами сообщений и кэшем L2 постоянного хранилища. Один для размера> 256 КБ, который показывает потоки между прокси-сервером API и процессорами сообщений, а также потоки между процессорами сообщений и данными/ответами, не хранящимися в кэше L2.

Влияние

  • Данные размером > 256 КБ не будут храниться в L2/постоянном кэше.
  • Более частые вызовы исходного источника (политики или целевого сервера) приводят к увеличению задержек для запросов API.

Лучшая практика

  • Для достижения оптимальной производительности предпочтительно хранить данные размером < 256 КБ в кэше.
  • Если есть необходимость хранить данные размером > 256 КБ, рассмотрите:
    • Использование любой подходящей базы данных для хранения больших данных.

      ИЛИ

    • Сжатие данных

Дальнейшее чтение

,

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X.
информация

Apigee Edge предоставляет возможность хранить данные в кеше во время выполнения для обеспечения устойчивости и более быстрого извлечения.

  • Данные первоначально сохраняются в кэше в памяти процессора сообщений, называемом кэшем L1 .
  • Кэш L1 ограничен объемом зарезервированной для него памяти в процентах от памяти JVM.
  • Кэшированные записи позже сохраняются в кэше L2 , который доступен всем процессорам сообщений. Более подробную информацию можно найти в разделе ниже.
  • Кэш L2 не имеет жесткого ограничения на количество записей кэша, однако максимальный размер записи, которую можно кэшировать, ограничен 256 КБ. Размер кэша 256 КБ — рекомендуемый размер для оптимальной производительности.

Антипаттерн

Этот конкретный антипаттерн говорит о последствиях превышения текущих ограничений размера кэша на платформе Apigee Edge.

При кэшировании данных > 256 КБ последствия следующие:

  • Запросы API, выполняемые впервые на каждом из процессоров сообщений, должны получать данные независимо от исходного источника (политики или целевого сервера), поскольку записи размером > 256 КБ недоступны в кэше L2.
  • Хранение больших данных (> 256 КБ) в кэше L1 приводит к большей нагрузке на ресурсы платформы. Это приводит к тому, что кэш-память L1 заполняется быстрее и, следовательно, для других данных остается меньше места. Как следствие, вы не сможете кэшировать данные так агрессивно, как хотелось бы.
  • Кэшированные записи из процессоров сообщений будут удалены, когда будет достигнуто ограничение на количество записей. Это приводит к повторному извлечению данных из исходного источника на соответствующих процессорах сообщений.

Две блок-схемы.   Один для размера <= 256 КБ, который показывает потоки между прокси-сервером API и процессорами сообщений, а также потоки между процессорами сообщений и кэшем L2 постоянного хранилища. Один для размера> 256 КБ, который показывает потоки между прокси-сервером API и процессорами сообщений, а также потоки между процессорами сообщений и данными/ответами, не хранящимися в кэше L2.

Влияние

  • Данные размером > 256 КБ не будут храниться в L2/постоянном кэше.
  • Более частые вызовы исходного источника (политики или целевого сервера) приводят к увеличению задержек для запросов API.

Лучшая практика

  • Для достижения оптимальной производительности предпочтительно хранить данные размером < 256 КБ в кэше.
  • Если есть необходимость хранить данные размером > 256 КБ, рассмотрите:
    • Использование любой подходящей базы данных для хранения больших данных.

      ИЛИ

    • Сжатие данных

Дальнейшее чтение