唯一标识 VM 实例（Azure ML - Web 服务）
Uniquely identify instances of VMs (Azure ML - web services)
我将此问题更多地作为 'probe' 问题发布，并计划扩大讨论以防出现一些兴趣。这背后的原因是，根据我的经验，azure-ml（及相关）上的 SO 社区仍在发展并且没有太多反馈 - 但我很乐意帮助它变得更强大。
我的情况如下：我在 Azure ML 中进行了一项实验，它在 R 模块中完成所有工作。我将其发布为 Web 服务并将 'max concurrent calls' 滑块设置为 10 - 我相信这可以保证我的 Web 服务最多有 10 个实例在任何时候启动和 运行ning 服务请求（如果我错了请纠正我）。
现在，我正尝试通过对我的网络服务发出 10 次并行调用来进行一些性能测试，但得到了意想不到的结果...
我正在尝试 运行 负载测试并记录每个测试的实际去向（哪个实例）。我的想法是在一定的最大并发调用数 = X 下，了解负载均衡器实际上如何将这些调用分配给实例。我通过从 "bot.whatismyipaddress.com" 内部触发对 "bot.whatismyipaddress.com" 的调用来做到这一点=13=] 脚本。这是代码的重要片段：
library(rjson)
machine.ip <- readLines("http://bot.whatismyipaddress.com/", warn=F)
result$MachineIP <- machine.ip
此外，我正在使用 Web 服务 RRS 帮助页面中的示例 R 代码来触发对我的 Web 服务的最多 70 个（连续）调用。此示例代码 returns 返回控制台的一些信息：我的 Web 服务的结果以及有关调用通过哪个主机名的一些信息。这是一个示例：
* Hostname was NOT found in DNS cache
* Trying 40.114.242.9...
* Connected to europewest.services.azureml.net (40.114.242.9) port 443 (#0)
我面临的困难是我无法唯一地识别我的网络服务的不同实例。从呼叫中输出到控制台的信息（第二个片段）通常显示与内部-R-代码日志 (result$MachineIP)...
中不同的 IP 地址
有人可以指出我做错了什么吗？我如何唯一地识别为调用提供服务的不同实例？任何帮助将非常感激。谢谢！
P.S。我已经在 Azure 论坛上 this as well, but the first apporach does not work when calling it from inside the R script and I'm using a modified version of the second apporach (the one suggested there does not work). Here are also my questions 试过了，以防有人感兴趣。
如果有人能帮助我或指出一些信息来源，我将不胜感激！
感谢 Azure ML 论坛上的一些人解决了这个问题所以
我要 post 为任何登陆这里寻找答案的人提供答案...
简短的回答是否定的，这是不可能的。更详细的版本是：
"From within the R script you cannot identify the internal AzureML IP addresses or the unique web service instances. When you make an external network call from the R script to an outside URL, that URL will see one of the AzureML public virtual IP's as the source IP. These are IP's of the load balancers, and not of the machines that are physically running the web service. AzureML dynamically allocates the instances of R engine in the backend, handles failures, and uses multiple nodes for running the web service for high availability. The exact layout of these for a given web service is not programmatically discoverable."
这里也是对原讨论的link。
我将此问题更多地作为 'probe' 问题发布，并计划扩大讨论以防出现一些兴趣。这背后的原因是，根据我的经验，azure-ml（及相关）上的 SO 社区仍在发展并且没有太多反馈 - 但我很乐意帮助它变得更强大。
我的情况如下：我在 Azure ML 中进行了一项实验，它在 R 模块中完成所有工作。我将其发布为 Web 服务并将 'max concurrent calls' 滑块设置为 10 - 我相信这可以保证我的 Web 服务最多有 10 个实例在任何时候启动和 运行ning 服务请求（如果我错了请纠正我）。
现在，我正尝试通过对我的网络服务发出 10 次并行调用来进行一些性能测试，但得到了意想不到的结果...
我正在尝试 运行 负载测试并记录每个测试的实际去向（哪个实例）。我的想法是在一定的最大并发调用数 = X 下，了解负载均衡器实际上如何将这些调用分配给实例。我通过从 "bot.whatismyipaddress.com" 内部触发对 "bot.whatismyipaddress.com" 的调用来做到这一点=13=] 脚本。这是代码的重要片段：
library(rjson)
machine.ip <- readLines("http://bot.whatismyipaddress.com/", warn=F)
result$MachineIP <- machine.ip
此外，我正在使用 Web 服务 RRS 帮助页面中的示例 R 代码来触发对我的 Web 服务的最多 70 个（连续）调用。此示例代码 returns 返回控制台的一些信息：我的 Web 服务的结果以及有关调用通过哪个主机名的一些信息。这是一个示例：
* Hostname was NOT found in DNS cache
* Trying 40.114.242.9...
* Connected to europewest.services.azureml.net (40.114.242.9) port 443 (#0)
我面临的困难是我无法唯一地识别我的网络服务的不同实例。从呼叫中输出到控制台的信息（第二个片段）通常显示与内部-R-代码日志 (result$MachineIP)...
有人可以指出我做错了什么吗？我如何唯一地识别为调用提供服务的不同实例？任何帮助将非常感激。谢谢！
P.S。我已经在 Azure 论坛上 this as well, but the first apporach does not work when calling it from inside the R script and I'm using a modified version of the second apporach (the one suggested there does not work). Here are also my questions 试过了，以防有人感兴趣。
如果有人能帮助我或指出一些信息来源，我将不胜感激！
感谢 Azure ML 论坛上的一些人解决了这个问题所以 我要 post 为任何登陆这里寻找答案的人提供答案...
简短的回答是否定的，这是不可能的。更详细的版本是：
"From within the R script you cannot identify the internal AzureML IP addresses or the unique web service instances. When you make an external network call from the R script to an outside URL, that URL will see one of the AzureML public virtual IP's as the source IP. These are IP's of the load balancers, and not of the machines that are physically running the web service. AzureML dynamically allocates the instances of R engine in the backend, handles failures, and uses multiple nodes for running the web service for high availability. The exact layout of these for a given web service is not programmatically discoverable."
这里也是对原讨论的link。