☰

如何最大限度地减少 Azure 应用服务和 Azure SQL 数据库之间的延迟？

tag-icon • tag-icon azure azure-sql azure-app-services
如何最大限度地减少 Azure 应用服务和 Azure SQL 数据库之间的延迟？

我们有一个使用 Java Tomcat 8.5 的 Azure 应用服务应用程序在美国西部地区运行。此服务的服务计划为标准版、大版。

此应用服务应用程序连接到属于美国西部弹性组的 SQL 数据库服务，其服务计划为标准 1200 eDTU。

我们面临的问题是两台服务器之间的交互性能非常差。

我们已通过调用应用服务上的 RESTful WebService 进行测试，该服务应在数据库的 2 个表中插入 50 条记录。总共插入了 100 条记录。执行此任务需要 3000 毫秒。

我们通过保存插入过程开始和结束之间的时间戳来测量这一点。因此不包括从本地客户端到应用服务通信的时间。

如果我们在本地机器上运行对 Restful WebService 的相同调用，并且 SQL 数据库与 Tomcat 服务器在同一台本地机器上运行，则该任务将在 400 毫秒内完成。

所以我打算认为问题应该是 Azure 云上这两个服务器之间的连接延迟，或者也许我在这里遗漏了一些东西。

所以这就是我问的原因，我对 Azure 技术还很陌生，也许我们可以采取其他选择来提供服务器之间更好的通信，或者有一种我不知道的方法来调试这个问题。

附带一个问题，如果这两台服务器位于我自己的数据中心内，我会确保它能直接在自己的网络上进行通信，不确定目前该服务之王是否在 Azure 中可用。

这是服务插入记录的2个表的定义：

CREATE TABLE [dbo].[Vehiculo](
   [Id] [decimal](18, 0) IDENTITY(1,1) NOT NULL,
   [CodigoCliente] [int] NOT NULL,
   [NumeroVehiculo] [int] NOT NULL,
   [Denominacion] [varchar](99) NOT NULL,
   [NumeroTarjeta] [int] NULL,
   [Placa] [varchar](10) NULL,
   [CuentaPresupuestal] [varchar](99) NULL,
   [NumeroPatrimonial] [varchar](99) NULL,
   [Grupo] [varchar](99) NULL,
   [NumeroEconomico] [varchar](99) NULL,
   [ClienteId] [decimal](18, 0) NULL,
   [UltimaActualizacion] [datetime] NULL,
   [Tenant] [varchar](50) NULL,
   [IdOrigenDeDatos] [decimal](18, 0) NOT NULL,
   [FechaAlta] [datetime] NOT NULL,
   [FechaUltimaModificacion] [datetime] NOT NULL,
   [PrimerActualizacion] [datetime] NOT NULL,
 CONSTRAINT [PK_Vehiculo] PRIMARY KEY CLUSTERED 
(
   [Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, 
 ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]


CREATE TABLE [dbo].[Cliente](
    [Id] [decimal](18, 0) IDENTITY(1,1) NOT NULL,
    [Codigo] [int] NOT NULL,
    [Denominacion] [varchar](255) NOT NULL,
    [CondicionVenta] [varchar](50) NOT NULL DEFAULT ('N/A'),
    [TipoDeValor] [varchar](50) NOT NULL DEFAULT ('N/A'),
    [PlazoDePago] [int] NOT NULL DEFAULT ((0)),
    [UltimaActualizacion] [datetime] NULL,
    [Tipo] [varchar](50) NOT NULL DEFAULT ('N/A'),
    [Grupo] [varchar](50) NOT NULL DEFAULT ('N/A'),
    [Zona] [varchar](50) NOT NULL DEFAULT ('N/A'),
    [EjecutivoDeCuenta] [varchar](50) NOT NULL DEFAULT ('NO INFORMADO'),
    [Clasificador] [varchar](20) NOT NULL DEFAULT ('CLIENT'),
    [Indicador001] [varchar](50) NULL,
    [FechaIndicador001] [datetime] NULL,
    [Indicador002] [varchar](50) NULL,
    [FechaIndicador002] [datetime] NULL,
    [Geolocalizacion] [varchar](50) NULL,
    [Latitud] [decimal](8, 6) NULL,
    [Longitud] [decimal](9, 6) NULL,
    [Colonia] [varchar](50) NOT NULL DEFAULT ('N/A'),
    [Delegacion] [varchar](50) NOT NULL DEFAULT ('N/A'),
    [Ciudad] [varchar](50) NOT NULL DEFAULT ('N/A'),
    [Estado] [varchar](50) NOT NULL DEFAULT ('N/A'),
    [Correo] [varchar](200) NULL,
    [Tenant] [varchar](50) NULL,
    [IdOrigenDeDatos] [decimal](18, 0) NOT NULL,
    [FechaAlta] [datetime] NOT NULL,
    [FechaUltimaModificacion] [datetime] NOT NULL,
    [PrimerActualizacion] [datetime] NOT NULL,
 CONSTRAINT [PK_Cliente] PRIMARY KEY CLUSTERED 
 (
    [Id] ASC
 )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, 
 ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
 ) ON [PRIMARY]

正如你所见的第一张表车辆有 17 列，并且客户有 29 列。

答案1

除了确保它们位于同一区域和同一可用区域（如果使用它们）之外，您无法采取很多措施来控制虚拟机与 SQL DB 的接近度。需要考虑以下几点：

  • 您可以在虚拟机上启用加速网络以增加网络吞吐量
  • 如果您使用任何类型的 VPN 或 Express Route 连接回本地资源，请确保从 IaaS VM 到 PaaS SQL 的流量不会被路由回本地并流出互联网
  • 尝试使用 Azure 中的某些诊断工具来测量性能，例如 Azure Monitor、Network Watcher 和 SQL 监视工具，看看是否可以发现任何问题

相关内容