Question

我正在运行一个ASP.NET mvc5应用程序，目前有500万用户。它托管在Azure云中。对于身份验证，我使用Asp.Net Identity for EntityFramework。

但是，我得到的用户越多，寄存器功能就越慢。我尝试缩放数据库，但结果仍然相同。新用户注册大约需要6-7秒。

此外，我尝试搜索如何提高身份系统的性能，但我找不到任何相关内容。

我真的很想知道是否有人知道如何才能提高它的性能。

更新：我在搜索的字段上有索引，而且，我在Azure中选择的数据库订阅是具有200个DTU的P3 SQL数据库。

我描述了数据库，我发现了一个可疑的选择查询。我删除了一些预测并用“....”替换它们，所以它不会太长，你可以看到有关的查询。

SELECT 
    [UnionAll2].[Gender] AS [C1], 
    ....
    [UnionAll2].[UserName] AS [C27], 
    [UnionAll2].[C1] AS [C28], 
    [UnionAll2].[UserId] AS [C29], 
    [UnionAll2].[RoleId] AS [C30], 
    [UnionAll2].[UserId1] AS [C31], 
    [UnionAll2].[C2] AS [C32], 
    [UnionAll2].[C3] AS [C33], 
    [UnionAll2].[C4] AS [C34], 
    [UnionAll2].[C5] AS [C35], 
    [UnionAll2].[C6] AS [C36], 
    [UnionAll2].[C7] AS [C37], 
    [UnionAll2].[C8] AS [C38], 
    [UnionAll2].[C9] AS [C39]
    FROM  (SELECT 
        CASE WHEN ([Extent2].[UserId] IS NULL) THEN CAST(NULL AS int) ELSE 1 END AS [C1], 
        [Limit1].[Gender] AS [Gender], 
        ....
        [Limit1].[UserName] AS [UserName], 
        [Extent2].[UserId] AS [UserId], 
        [Extent2].[RoleId] AS [RoleId], 
        [Extent2].[UserId] AS [UserId1], 
        CAST(NULL AS int) AS [C2], 
        CAST(NULL AS varchar(1)) AS [C3], 
        CAST(NULL AS varchar(1)) AS [C4], 
        CAST(NULL AS varchar(1)) AS [C5], 
        CAST(NULL AS varchar(1)) AS [C6], 
        CAST(NULL AS varchar(1)) AS [C7], 
        CAST(NULL AS varchar(1)) AS [C8], 
        CAST(NULL AS varchar(1)) AS [C9]
        FROM   (SELECT TOP (1) 
            [Extent1].[Id] AS [Id], 
            ....
            [Extent1].[UserName] AS [UserName]
            FROM [dbo].[Users] AS [Extent1]
            WHERE ((UPPER([Extent1].[UserName])) = (UPPER(@p__linq__0))) OR ((UPPER([Extent1].[UserName]) IS NULL) AND (UPPER(@p__linq__0) IS NULL)) ) AS [Limit1]
        LEFT OUTER JOIN [dbo].[UserRoles] AS [Extent2] ON [Limit1].[Id] = [Extent2].[UserId]
    UNION ALL
        SELECT 
        2 AS [C1], 
        [Limit2].[Gender] AS [Gender], 
        ....
        [Limit2].[UserName] AS [UserName], 
        CAST(NULL AS varchar(1)) AS [C2], 
        CAST(NULL AS varchar(1)) AS [C3], 
        CAST(NULL AS varchar(1)) AS [C4], 
        [Extent4].[Id] AS [Id1], 
        [Extent4].[UserId] AS [UserId], 
        [Extent4].[ClaimType] AS [ClaimType], 
        [Extent4].[ClaimValue] AS [ClaimValue], 
        CAST(NULL AS varchar(1)) AS [C5], 
        CAST(NULL AS varchar(1)) AS [C6], 
        CAST(NULL AS varchar(1)) AS [C7], 
        CAST(NULL AS varchar(1)) AS [C8]
        FROM   (SELECT TOP (1) 
            [Extent3].[Id] AS [Id], 
            ....
            [Extent3].[UserName] AS [UserName]
            FROM [dbo].[Users] AS [Extent3]
            WHERE ((UPPER([Extent3].[UserName])) = (UPPER(@p__linq__0))) OR ((UPPER([Extent3].[UserName]) IS NULL) AND (UPPER(@p__linq__0) IS NULL)) ) AS [Limit2]
        INNER JOIN [dbo].[UserClaims] AS [Extent4] ON [Limit2].[Id] = [Extent4].[UserId]
    UNION ALL
        SELECT 
        3 AS [C1], 
        [Limit3].[Gender] AS [Gender], 
        ....
        [Limit3].[UserName] AS [UserName], 
        CAST(NULL AS varchar(1)) AS [C2], 
        CAST(NULL AS varchar(1)) AS [C3], 
        CAST(NULL AS varchar(1)) AS [C4], 
        CAST(NULL AS int) AS [C5], 
        CAST(NULL AS varchar(1)) AS [C6], 
        CAST(NULL AS varchar(1)) AS [C7], 
        CAST(NULL AS varchar(1)) AS [C8], 
        [Extent6].[LoginProvider] AS [LoginProvider], 
        [Extent6].[ProviderKey] AS [ProviderKey], 
        [Extent6].[UserId] AS [UserId], 
        [Extent6].[UserId] AS [UserId1]
        FROM   (SELECT TOP (1) 
            [Extent5].[Id] AS [Id], 
            ....
            [Extent5].[UserName] AS [UserName]
            FROM [dbo].[Users] AS [Extent5]
            WHERE ((UPPER([Extent5].[UserName])) = (UPPER(@p__linq__0))) OR ((UPPER([Extent5].[UserName]) IS NULL) AND (UPPER(@p__linq__0) IS NULL)) ) AS [Limit3]
        INNER JOIN [dbo].[UserLogins] AS [Extent6] ON [Limit3].[Id] = [Extent6].[UserId]) AS [UnionAll2]
    ORDER BY [UnionAll2].[Id] ASC, [UnionAll2].[C1] ASC

我的EntityFramework用户POCO类

    public class User : IdentityUser
    {
        [Index]
        public DateTime Created { get; set; }
        [Index(IsUnique = true), MaxLength(255)]
        public override string Email { get; set; }
        public string Firstname { get; set; }
        public string Lastname { get; set; }
        [Index]
        public GenderType Gender { get; set; }
        [Index]
        public DateTime? Birthdate { get; set; }
        [Index, MaxLength(2)]
        public string Country { get; set; }
        [MaxLength(2)]
        public string Language { get; set; }
        [Index, MaxLength(256)]
        public string Referral { get; set; }
        public string ImageUrl { get; set; }
        [Index]
        public UserIdentityStatus IdentityConfirmed { get; set; }
        [Index]
        public DateTime? Deleted { get; set; }
        public ICollection<Reward> Ads { get; set; }
        public ICollection<Thought> Thoughts { get; set; }
        public ICollection<Achievement> Achievements { get; set; }
        public ICollection<Subscription> Subscriptions { get; set; }
        public DateTime? TutorialShown { get; set; }
        [Index]
        public DateTime? LastActivity { get; set; }
        [Index]
        public DateTime? LastBulkEmail { get; set; }
    }

Answer 1

我想我有解决方案。我做了另一个测试和第二个选项 - 计算列工作的索引。以下是sql代码中的步骤，您可以使用EF注释执行相同的操作。

在表用户上创建计算列作为upper（用户名）：

alter table users将upper_username添加为upper（username）
在该列上创建索引：

在a_upload（upper_username）上创建索引ix2

多数民众赞成。 EF select仍将使用UPPER，但MS SQL优化器应该能够使用此索引，因为它与where子句中的函数具有相同的定义。

以下是我的电脑上的测试结果：

测试sql：从a_upload中选择field001，其中upper（field001）=＆＃39; 10＆＃39;

BEFORE（SCAN意味着引擎必须逐个读取所有记录）

BEFORE

在功能栏上创建索引（SEEK =引擎将使用索引）

enter image description here

不要觉得即使在BEFORE场景中，sql引擎也在使用索引（ix1）。这只是因为我只选择＆＃34; field001＆＃34;并且优化器知道它不仅包含在表中，还包含在索引中。索引的字节数比整个表少。但这并不意味着系统使用索引，它必须为每个选择的每一行计算upper（）。

Answer 2

虽然我不得不用int替换userId guid，但我创建了一个CustomUserStore。在此UserStore中，您只需覆盖FindByNameAsync：

public class CustomUserStore<TUser> : UserStore<TUser, CustomRole, int, CustomUserLogin, CustomUserRole, CustomUserClaim> where TUser : MyUser
{
    public CustomUserStore(MyDbContext context) : base(context) { }

    public override Task<TUser> FindByNameAsync(string userName)
    {
        return this.GetUserAggregateAsync(u => u.UserName.Equals(userName, StringComparison.InvariantCultureIgnoreCase));
    }
}

这导致没有UPPER（）的查询。

Answer 3

是的，这个查询可能就是问题所在。这就是我不喜欢SQL框架的原因。

问题在于：

WHERE 
((UPPER([Extent3].[UserName])) = (UPPER(@p__linq__0)))

右侧是常数，左侧是＆＃34;上部（用户名）＆＃34;是SQL引擎试图找到某个地方。关于简单＆＃34;用户名＆＃34;的索引没用，因为它包含简单的＆＃34;用户名＆＃34;而不是上限（用户名）值。 SQL引擎必须计算所有5百万行的上限（用户名），每次添加新用户，然后找到相应的值。 7秒......

您需要创建此类索引：

create index ix_name on Users(upper(UserName))

这样的索引将由sql引擎自动使用。但是我担心，MS SQL不允许你在没有添加计算列的情况下这样做（并且它对你的目的没用，因为你不能强迫EF使用另一个列作为用户名值）。

另一种选择是强制Identity框架不使用UPPER功能。但我不知道如何。

顺便说一句，我真的很惊讶在这样一个重要的包 - 实体框架中找到这种类型的代码。这＆＃34;搜索索引中的功能值＆＃34;编写高效的sql代码时出现了基本的错误。

还有一条评论：这一切都应该由框架来完成，它负责正确处理＆＃34;用户名＆＃34;柱。这是一个错误，这个建议只是解决方法。

Answer 4

尝试从某些Azure审核工具中获取确切的SQL命令，并将其写入此处的注释。 7秒看起来像索引中的问题（索引ant的访问时间太长，无法将大量数据传输到客户端）。

INSERT命令本身总是很快（如果没有被触发器减慢），并且随着行数的增加不会显着减慢。身份框架可能正在运行一些SELECT（例如重新读取新行......？）。在所有受影响的列上拥有索引是不够的。选择命令只能在每个表上使用一个索引，因此您只需要找到一个索引，但是正确的索引 - 列的正确组合，索引中的列顺序也很重要。所有这些都取决于SQL命令，即尝试执行的Identity引擎。试着找到它，然后我可以帮助你。

如何处理500万用户？ ASP.NET身份

4 个答案: