我正在构建一个 Web 应用程序,并决定将其托管在 Windows Azure 上。
我的应用程序有三个组件:
- 使用 Play Framework 创建的前端(机器 A)
- 用 Java 编写的执行我的业务逻辑的后端核心(机器 B)
- 数据库(机器 C)
由于我有一个免费的 Bizspark 帐户,所以我创建了 3 个免费的 Azure 用户:为每个用户我创建了一个中型 Ubuntu 12.04 LTS 机器,并在每台机器上安装了一个组件。
每个组件都在自己的机器上运行以提高性能。我感兴趣的连接是从机器 A 和 B 到机器 C 的连接。
我成功连接到数据库机器,创建了所有需要的端点,并赋予了正确的访问权限
但
我遇到的问题如下:
SEVERE: FATAL: DataSourcePool [mysql] is down!!!
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 1,197,486 milliseconds ago.
Caused by: java.net.SocketException: Connection timed out
或者:
WARNING: DataSourcePool closing leaked connection?
Nov 27, 2013 8:55:46 PM com.avaje.ebeaninternal.server.lib.sql.DataSourcePool validateConnection
WARNING: heartbeatsql test failed on connection[mysql.31]
Nov 27, 2013 8:55:46 PM com.avaje.ebeaninternal.server.lib.sql.PooledConnection closeConnectionFully
INFO: Closing Connection[mysql.31] psReuse[19] psCreate[19] psSize[19]
或者:
javax.persistence.PersistenceException: java.sql.SQLException: Unsuccessfully waited
[1000] millis for a connection to be returned. No connections are free. You need to
Increase the max connections of [100] or look for a connection pool leak using
datasource.xxx.capturestacktrace=true
由于我的应用程序在另一台 Web 服务器上运行良好,我认为我的网络配置有问题。我认为在 eBean 从池中获取连接之前 1000ms 已经用完了。我尝试执行一些基本的连接测试,例如从我的核心计算机到数据库计算机的 Ping 或 Traceroute,但 Azure 阻止了 ICMP 消息。然后我尝试了 TCPPING,输出如下:
tcpping xxx.cloudapp.net 3306
TCP Ping 1:0,808ms
TCP Ping 2:0,934ms
TCP Ping 3:1,036ms
TCP Ping 4:0,860ms
TCP Ping 5:0,927ms
TCP Ping 6:0,905ms
TCP Ping 7:0,949ms
TCP Ping 8:1,079ms
TCP Ping 9:1,274ms
TCP Ping 10:0,983ms
TCPTraceroute 不起作用,它只显示星号......
我不知道这些结果是否可信,但我不知道 Azure 是如何工作的。我认为平均 1 秒是一个巨大的进步。
然后我尝试远程连接到数据库机器:我在核心机器上安装了 MySQL 5.5 客户端并像这样连接:
mysql -u [username] -h [db machine hostname].cloudapp.net --port=3306 -p[password]
一切都很好,而且似乎也相当快,从控制台视图中我看不到任何类型的滞后。
有关机器的一些细节:
你能告诉我怎样做才能减少这种延迟吗?
答案1
好吧,除了你正在利用平台优势这一事实之外,以下是我的想法。
我认为连接虚拟机的最佳方式是利用 Azure 虚拟网络。但是,截至今天(2013 年 12 月 5 日),您无法跨多个帐户跨越虚拟网络。您唯一的选择是通过 VIP(公共 IP 地址)访问计算机,您现在就是这么做的。我认为您观察到的时间大约是 1 ms(毫秒),而不是 1 s(秒)!我认为 1 ms 在某种程度上是可以忽略的。此外,您必须倒回 Match 类。您引用的错误消息:
最后一个从服务器成功接收的数据包是 1,197,486 毫秒前
指的是1,197,486
毫秒。1 秒正好是 1000 毫秒。这意味着 1,197,486 毫秒约为 1,198 秒,或大约 20 分钟。好吧,20 分钟的超时肯定与网络延迟无关。
如果您希望事情正确或正确 - 只需将所有内容放在同一个帐户、单个虚拟网络中并使用内部 IP 地址进行通信 - 这样您将跳过 Azure 负载均衡器,而这是在通过公共 IP 地址进行跨部署通信时无法避免的。
或多或少,从今天起,每个 Azure 部署(包括您的虚拟机)都按照以下描述的图片运行这篇博文。假设您有 3 个这样的图表,每个图表只有一个 VM,而不是图表上显示的 5 个。