Uso excesivo de ASP.Net de los controles de usuario

Question

Estoy investigando una aplicación web asp.net que usa ampliamente controles de usuario en cada página. La mayoría de las páginas contienen alrededor de 10-20 controles de usuario. Los controles de usuario parecen ser la representación visual de los objetos de negocio (si tiene sentido), aunque en una granularidad más fina, como cada pestaña de un control de pestaña que tiene su contenido en un control de usuario. El proyecto en sí tiene más de 200 controles de usuario (archivos ascx).

El rendimiento de la aplicación es muy pobre (y el motivo por el que estoy investigando). Cada evento (como un clic o una selección desplegable, etc.) requiere aproximadamente 5 segundos para que la página se cargue (10 segundos mientras está en el estudio visual). La aplicación no tiene uso de Ajax. El rastreo es doloroso ya que las páginas aspx no tienen código en el código subyacente ya que los controles del usuario se encargan de todo esto, por lo que rastrear una página requiere instrucciones de seguimiento en todos los controles de usuario que están en esa página.

De hecho, creo que hacer que cada usuario controle su código comercial y sea reutilizable es una buena idea, pero ¿el uso excesivo de los controles del usuario va a generar un impacto en el rendimiento? ¿Parece esto la estructura de una aplicación asp.net escrita por alguien con un fuerte historial de WinForms?

EDITAR
pensé que debería añadir que no estoy cuestionando el uso de los controles de usuario (o incluso la cantidad), sino simplemente si tener tantos en una página que toda lograr cosas (cada control de usuario se conecta a la base de datos, por ejemplo) generalmente causará problemas de rendimiento ... Por ejemplo, si solo un usuario controla el posback para hacer algo, ¿qué pasa con el procesamiento de todos los demás, algunos son visibles y otros no ... @ David McEwing mencionó que tenía 40 controles de usuario optimizados realizando etc., pero si el desarrollador estaba basado en WinForms o "no estaba familiarizado con asp.net", entonces ¿cómo iban a asegurarse de que cada uno estuviera optimizado ...

EDIT2
Después de obtener un rastreo de instrucción sql, las mismas llamadas de datos se están ejecutando 5-6 veces por llamada de página para cada evento ya que los diferentes controles de usuario requieren datos que no se almacenan comúnmente, p. Ej. cada control de usuario en la pestaña (mencionado anteriormente) hace la misma llamada para llenar un objeto de la base de datos ... Realmente no estoy aquí para acusar a los controles del usuario de ser el problema (¿debo eliminar la pregunta?) como claramente el problema NO son controles de usuario sino con el uso de ellos en este caso particular ... ¡que creo que es excesivo!

Answer 1

10-20 (o incluso cientos) Los controles de usuario por sí solos son más que triviales. La presencia de los controles mismos y la idea de encapsulación definitivamente no son la fuente de sus problemas.

Es imposible decir precisamente cuál es el problema sin llegar a perfilar la aplicación, por supuesto, pero en base a mi experiencia puedo decir esto:

Lo más probable es la aplicación específica de la empresa la lógica dentro de cada control de usuario es pobre. Con las devoluciones de datos tomando todo el tiempo que describa, cada control probablemente mira hacia atrás a su DAL para obtener sus propios datos en cada solicitud. Esto puede ser mitigado por dos cosas:

• hacer controles de usuario seguro de caché de todos sus datos en la primera carga y Nunca volver a cargarla menos que se indique explícitamente (por lo general por un evento de un servicio de nivel inferior)
• Asegúrese de que todos los controles utilicen un conjunto de servicios comunes que puedan reutilizar datos. P.ej. si dos controles necesitan acceder a la lista de clientes, y se están ejecutando en el contexto de la misma sesión de solicitud, eso solo debería requerir una búsqueda en la lista de clientes.

Answer 2

Supongo que no está familiarizado con las aplicaciones que utilizan tantos controles de usuario?

Parece que puede estar llegando a la conclusión de que este aspecto desconocido de la aplicación es la causa del mal rendimiento desconocido. En lugar de hacer suposiciones, por qué no probar una de las siguientes herramientas de perfilado, y averiguar:

• JetBrains' dotTrace
• Red-Gate ANTS
• Automated QA's AQTime

todos estos pueden hacer memoria y CPU de perfiles de ASP Aplicaciones .NET

Answer 3

Creo que uno de los objetivos clave de UserControls es la reutilización de código. Es decir, si la misma funcionalidad ocurre en múltiples páginas web, entonces es mejor crear un UserControl para ella.Esto no solo evita que el desarrollador escriba (o copie y pegue) el mismo código en varias páginas web, sino que también facilita el mantenimiento. Cualquier cambio realizado en UserControl se implementa automáticamente en todas partes donde se usa UserControl. El desarrollador de mantenimiento no tiene que preocuparse por encontrar todos los lugares diferentes que el código necesita cambiar.

No estoy seguro de si un UserControl de un solo uso es tan eficaz. Ellos encapsulan y segregan el código, lo cual es bueno en una página web ocupada.

Puede determinar si sus UserControls se vuelven a utilizar, o muchos de ellos solo se usan una vez.

Answer 4

Estoy de acuerdo con Saunders en hacer algunos perfiles para determinar el impacto que tienen ciertas cosas.

Tenga en cuenta que usted puede conseguir algunas herramientas de pruebas de estrés gratuitas para IIS aquí: http://support.microsoft.com/kb/840671

Diré, sin embargo, que el tener demasiados controles no es probablemente una buena cosa, en mi humilde opinión. Sin saber más, tentativamente diría que 20 es demasiado.

Answer 5

Me pondré firmemente en el grupo de personas que sugieren que no hay un límite estricto para una serie de controles de usuario que se deben utilizar en una página. Parece que el seguimiento de toda la aplicación está en orden aquí en lugar del seguimiento a nivel de página. Es muy posible que un puñado de estos controles esté causando el problema. Diablos, podría ser un solo control causando todo el alboroto. Sin embargo, dado que es imposible hacer una suposición sobre el nivel de uso de recursos que toma el control de usuario "promedio" (si es que existe tal cosa), es igualmente imposible sugerir un límite. De lo contrario, podríamos establecer límites similares a la cantidad de miembros de una clase o la cantidad de procedimientos almacenados en una base de datos.

Ahora, si hablamos de 20 controles de usuario complejos que cada uno recupera sus propios datos con cada actualización y cada uno con un conjunto de subcontroles que usan ViewState, sea necesario o no, entonces sí, eso es un problema. Aún así, tiene más que ver con el diseño general que con demasiados controles.Si, por otro lado, han creado un control de usuario común para actuar como nada más que el compuesto de una etiqueta a la izquierda de un cuadro de texto (o tal vez incluso cada combinación de etiqueta + control accionable por el usuario) y han rociado este control a lo largo de la aplicación, me imagino que obtendrías un montón de estos en una página y no veo por qué eso necesariamente dañaría algo.