Стоимость обслуживания запросов в интернет-магазине через httpresponse

Question

У меня очень простой вопрос.

Какова стоимость обслуживания запроса в интернет-магазине через httpresponse. Прямо сейчас я обслуживаю изображения, загружая их в blobstore и создавая imageServingLink () и передавая изображения пользователю по этой ссылке. Это стоит только полосы пропускания, а не времени экземпляра, но имеет ограничение в 1600 пикселей по размеру.

Так что вместо этого я хотел бы предоставить свои изображения через httpresponse.

Так что обслуживание через httpresponse обойдется мне в дополнительную квоту, например, время экземпляра (на время загрузки пользователем изображения) или только пропускную способность.

Я знаю, что где-то читал, что это стоит только полосы пропускания, но в документации интернет-магазина не ясно!

И второй вопрос:

Служит ли httpresponse в интернет-магазине быстрее или медленнее, чем через службу миниатюр?

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

Я с нетерпением жду ответа.

== EDIT ==

Эта часть мне не совсем понятна:

Обслуживание статического контента (Java, Python) обрабатывается специализированным приложением. Инфраструктура двигателя, которая не потребляет часы экземпляра. Если вам нужно установить пользовательские заголовки, используйте API Blobstore (Java, Python, Идти). Фактическая порция ответа Blob не использует экземпляр Часы.

Так что теперь в хранилище блогов используется экземпляр или нет для обслуживания ответов?

В чем разница между статическим и динамическим файлом в хранилище и как он узнает?

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

Answer 1

Запросы к URL-адресам, генерируемым API-интерфейсом изображений, не потребляют часы работы экземпляра, поскольку для них не требуется запуск кода вашего приложения.Инфраструктура App Engine может предоставлять изображение вашим пользователям без необходимости когда-либо связываться с вашим приложением, поэтому время экземпляра не тратится.

Предполагается, что вы говорите о BLOB-объектах, которые задокументированы здесь -то есть, устанавливая соответствующие заголовки хранилища больших двоичных объектов и позволяя инфраструктуре App Engine возвращать ответ большого двоичного объекта - единственными дополнительными затратами являются время экземпляра, затрачиваемое вашим обработчиком, и дополнительная задержка, которую будут испытывать ваши пользователи.

Answer 2

Изображения, обслуживаемые imageServingLink() / get_serving_url(), поступают от специального оборудования Google, специализирующегося на быстрой обработке изображений, и вы платите только за пропускную способность.

Если вам нужно вместо этого обслуживать изображения из приложения,тогда, конечно, вам придется заплатить некоторое время экземпляра в дополнение к пропускной способности, и это будет немного медленнее.Это время экземпляра предназначено для выполнения вашего кода до тех пор, пока вы не вернетесь из обработчика запроса, фактическая загрузка данных клиентом не потребляет времени экземпляра.

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