我有一个在计算引擎上运行的实例,它使用 Torch 来预测图像中的对象。我想制作一个简单的 Web 界面,用户可以使用该界面上传图像,将图像发送到服务器(计算引擎),预测对象并将列表返回给用户。
在我的计算引擎(Ubuntu 14.04)中,这行代码用于预测图像中的对象。 (所有其他设置已在计算引擎中完成。)
th eval.lua -model /path/to/model -image_folder /path/to/image/directory -num_images 10
我想从网络应用程序调用此行并将图像传递到图像文件夹并获取对象列表。我该怎么办?
在过去的项目中,我讨论并使用了不同的方法在 Google App Engine 和 Google Compute Engine 之间进行通信。一般来说,两个常见的嫌疑人是:
-
Orchestration from App Engine: In this approach the App Engine application is the active part and sends requests to a service on the compute instance. This is what Igor Artamonov already described in his comment. We used a tomcat instance on the compute instances which ran a full rest api to invoke commands on the instance. Possible helpers:
- 当使用谷歌计算API从 App Engine,您可以获得计算实例的外部 IP 地址。这样您就知道您的请求必须发送到哪里。
-
从计算实例轮询:由于您知道 App Engine 应用程序的应用程序 ID,因此您可以在计算实例上编写一个简单的循环,以从 App Engine 应用程序请求新作业。我将这种方法与编排结合使用,该编排将向不再需要的实例发送关闭命令,从而减少应用程序引擎上的轮询负载。如果创建了新作业,我将启动一个新的计算实例,然后该实例将进行轮询,直到再次收到关闭命令。
两种方法都效果很好。如果您使用计算 API 并知道计算实例的 IP,则可以将轮询端点和命令调用请求限制到这些 IP,以实现基本安全。
我会尽量避免过多的投票,因为,让我给你一个报价:
主动轮询是穷人启动工作流程的解决方案。 (javaworld.com)
但是,如果您在计算实例完成工作负载后关闭它们,我看不出您不应该使用轮询的充分理由。如果您不这样做,并且将计算实例的数量增加到几个实例,您将在 App Engine 应用程序上增加负载,除了成本之外什么也得不到。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)