【问题标题】:Caching cloud storage files on app engine在应用引擎上缓存云存储文件
【发布时间】:2021-11-30 21:54:03
【问题描述】:

我正在使用应用引擎来为一堆 sklearn 模型提供服务。这些模型的大小约为 100 mb,其中大约有 25 个。

尽管位于指定的应用引擎存储桶中,但下载它们有时可能需要长达 15 秒,并且通常会占据请求时间。

我目前使用包裹在 GCS 存储客户端周围的 FIFO 缓存层,但缓存命中率并不高,因为不同模型的使用非常分散且应用引擎内存有限。

Memcache 似乎太小了,而且 /tmp 也存储在 RAM 中。

缓存此类文件有更好的解决方案吗?

【问题讨论】:

    标签: google-app-engine google-cloud-platform google-cloud-storage


    【解决方案1】:

    您可以想出不同的解决方案来解决您的问题。

    1. 您可以将模型嵌入到您的部署中。像这样,模型已经在这里提供了服务。发布新模型版本时,您部署了新的应用引擎服务修订版
    2. 先前解决方案的问题在于部署频率:当其中一个模型更新时,您需要重新打包并重新部署您的 App Engine 服务。解决方案是微服务。每个 App Engine 服务可以有 1 个模型,因此只部署已更新的这个模型。如果您只想要入口点,您可以拥有第 26 个应用引擎服务,这是您的入口点,并将请求路由到正确的模型服务。
    3. 您也可以使用 Cloud Run 执行相同的操作,如果您需要特殊的东西,您可以在其中管理容器包装和细节。您还可以在 CPU 数量和内存大小方面拥有更大的灵活性。

    最后一点,在解决下载问题部分后,您可能会遇到冷启动问题:服务器启动和将模型加载到内存中的时间(在第一次请求时,实例启动时)。 Cloud Run 提出了最小实例功能来保持一定数量的实例温暖,从而消除冷启动问题。

    【讨论】:

    • 您好 Guilaume,感谢您的深入建议。 1. 不幸的是,App Engine 不允许这种大小的部署(甚至文件)。 2.这不是问题,模型已经很久没有更新了。制作更小的模型可能是未来减少一些问题的一种方法,但需要一些时间。许多不同的版本会产生高昂的成本和维护。 3. 尽管有限制,但我现在还是想坚持使用 App Engine(降低维护负担、更容易测试以及额外服务器端点的灵活性)
    • 我还看到很多“内存不足”错误。由于矢量化器构造不佳,某些模型在未腌制时似乎相当大。这一点,再加上使用的线程/工作者数量可能是主要问题。
    • 糟糕,我忘记了 App Engine 上的文件大小。无论如何,您的用例处于 App Engine 的极限,这就是为什么考虑另一种产品是一个好方法,不要为继续使用 App Engine 的奇怪变通方法而苦恼!
    • 这绝对是半年后重新审视的东西,但就目前而言,它现在似乎在 3 个 gunicorn 线程而不是 4 个线程上稳定运行。感谢您的建议!
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-05-09
    • 2014-04-06
    • 2014-08-17
    • 2013-01-02
    相关资源
    最近更新 更多