DataBind() sur Gridview lent

Question

J'ai une application utilisant un gridview qui est vraiment lent.

Après avoir ajouté le Trace=true pour la page, j'ai cherché où le temps est passé : lors de l'appel de BindData() sur un GridView. Le site GridView est relié à un LinqDataSource .

Voici la sortie de la trace :

GetContact        0.955485090710761        0.000339
  DataBind        0.97438854173692         0.018903
  PopulateStates  6.58986882347249         5.615480

Voici l'exemple de page asp.net

<asp:LinqDataSource ContextTypeName="DAL.BALDataContext" TableName="loc_access_contacts"
    ID="_ldsContact" runat="server" OrderBy="organisation, last_name, first_name">
</asp:LinqDataSource>
<cc1:CustomGridView ID="gvContact" runat="server" DataSourceID="_ldsContact" AutoGenerateColumns="False" Width="100%"
    DataKeyNames="person_id" ForeColor="#333333" GridLines="None" AllowPaging="False"
    AllowSorting="True" BorderStyle="None" ShowFooter="false" CaptionAlign="Top"
    PagerStyle-HorizontalAlign="Left" HeaderStayPolicy="NotStay" SessionKey="Contact.GridView.Columns.SortSettings"
    SaveKey="ContactManagementSortSettings" OnRowCommand="gvContact_RowCommand" OnSorting="gvContact_Sorting">

Dans Code Behind :

Trace.Write("  DataBind");
gvContact.DataBind();

Trace.Write("  PopulateStates");
populateStates(contact);

Le code de la source de données LINQ ressemble à ceci :

public System.Data.Linq.Table<loc_access_contact> loc_access_contacts
{
  get
  {
    return this.GetTable<loc_access_contact>();
  }
}

Le SQL généré à partir de cette propriété est un canonical SELECT <all fields> FROM loc_access_contact .

Et la table loc_access_contact ressemble à :

CREATE TABLE [dbo].[loc_access_contact](
[person_id] [int] IDENTITY(1,1) NOT NULL,
[organisation] [nvarchar](50) NULL,
[last_name] [nvarchar](50) NULL,
[first_name] [nvarchar](50) NULL,
[is_active] [tinyint] NULL,
[state_id] [char](2) NULL,
[postal_code] [nchar](4) NULL,
[town] [nvarchar](50) NOT NULL,
[phone_number] [nvarchar](20) NULL,
[mobile_number] [nvarchar](20) NULL,
[fax_number] [nvarchar](20) NULL,
[email_address] [nvarchar](255) NULL,
[street_name] [nvarchar](255) NULL,
[house_number] [nvarchar](20) NULL,
[postal_box] [nvarchar](20) NULL,
[language] [tinyint] NULL,
CONSTRAINT [PK_person] PRIMARY KEY CLUSTERED 
(
[person_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]

Le tableau contient environ 287 contacts.

Comment se fait-il que le DataBind soit si lent ? Comment puis-je déterminer plus précisément ce qui se passe ?

Answer 1

Si vous utilisez SQL Server, je mettrais une trace sur l'application puis je l'exécuterais à nouveau. Ensuite, je choisirais le SQL réel qui a été exécuté. Exécutez-le directement sur la base de données et voyez si vous pouvez repérer les goulots d'étranglement.

Il semble que tu ramènes toutes les données dans loc_access_contacts donc ça pourrait être le simple volume de données.

Une autre possibilité est le tri. Vous triez par organisation, nom de famille, prénom. Je serais tenté de mettre un index non groupé sur ces colonnes afin de rendre le tri plus efficace. Vérifiez cependant que cette table dispose d'un index clusterisé raisonnable, c'est-à-dire d'une clé primaire.

Bien sûr, je suppose ici que vous avez le contrôle de votre BD, ce qui n'est pas le cas de beaucoup de gens. Dans ce cas (ou honnêtement dans tous les cas), utilisez la pagination dans votre grille. Si vous pouvez utiliser une sorte de pagination sensible côté serveur (c'est à dire en utilisant la fonction Skip y Take opérateurs LINQ), cela améliorera grandement l'efficacité de vos liaisons. Il y aura simplement beaucoup moins de données.