Timeout Expired

Uso esta:

[assembly: AssemblyVersion("2.0.0.0")]

¿dónde consigo la 3.1?

Gracias.

"Maxi" escribió:

Hola, estas usando la version 3.1 del DAAB?

Otra cosa, fijate el consumo de red, que velocidad y equipos tiene esa red?


Salu2
Maxi


"hpmig" escribió en el mensaje
news:
> Saludos.
>
> 1. Utilizo exclusivamente stored procedures, tanto de consulta, como de
> actualización. Para "llamarlos", hago uso de Data Access Application Block
> (DAAB), en su versión p/.NET Framework 1.1 (mi apl. la desarrollé en C#
> 2003).
>
> 2. Tanto el servidor de SQL, como mi aplicación, "corren" en el mismo
> equipo: W2K Server con SP 4, 2 procesadores Xeon 2.4Ghz (HT - es decir,
> están
> disponibles 4 procesadores), 3GB RAM. El SQL Server tiene instalado el SP
> 3a
> ( Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05
> Copyright (c) 1988-2003 Microsoft Corporation Standard Edition on Windows
> NT
> 5.0 (Build 2195: Service Pack 4) ).
>
> 3. ¿cómo puedo medir el ancho de banda?
>
> Gracias.
>
> "MAXI" escribió:
>
>> Hola, mmm, para mi lo que estas teniendo es un alto consumo de ancho de
>> banda hacia el servidor de datos :(
>>
>> Probar lo del pool es simple, sacalo de la cadena de conexion y probamos
>>
>> Preguntas:
>>
>> 1) Estas usando Sp' o envias consultas desde la aplicacion?
>> 2) Tenes los service Pack instalados del Sqlserver y el SO?
>> 3) Podes medir el ancho de banda en que consumo esta?
>>
>> Empecemos por aca y vayamos descartando temas ;)
>>
>> Un abrazo
>>
>>
>>
>>
>> Maxi
>>
>> Buenos Aires - Argentina
>> Desarrollador .NET 3 Estrellas
>> Microsoft User Group (MUG)
>>
>> "hpmig" escribió en el mensaje
>> news:
>> > Mil gracias por responder. Te ampliaré un poco más el escenario: este
>> > módulo
>> > de ACD, forma parte de una solución CTI que se conecta, vía socket
>> > TCP/IP,
>> > a
>> > un servidor (Switch telefónico) que le envía paquetes con la
>> > información
>> > de
>> > la llamada arribante. El ACD con esta info. consulta al serv. de SQL
>> > para,
>> > también mediante un paq. vía red, indicarle al Switch cómo tratar la
>> > llamada.
>> > Cuando tuve que finalizar la aplicación, que es multithread (una thread
>> > para
>> > mensajes de entrada y otra para los de salida), había procesado
>> > alrededor
>> > de
>> > 25 millones de mensajes de entrada y unos 12 millones de salida. En un
>> > estimado, de los 25 millones de entrada, un 70% necesitan consultar la
>> > base
>> > de datos. Estoy utilizando la librería DAAB para .NET 1.1, es decir,
>> > cierro
>> > conexiones después de toda actividad. Claro, el pool mantiene, se
>> > supone,
>> > cierto número de conexiones "dormidas". Cuando inhabilito el pool,
>> > cierra
>> > perfectamente, ahora sí, la conexión que uso. Aumentar el timeout no me
>> > sería
>> > útil, pues cuando una llamada entra, debo contestarle lo más rápido
>> > posible:
>> > si no le contesto a la llamada en menos de 15 seg. se colgará. ¿Cómo
>> > puedo
>> > saber si es un problema de pool? ¿Porqué después de manejar tantas
>> > consultas,
>> > de manera tan crítica, con un buen desempeño durante 2 semanas,
>> > súbitamente,
>> > cuando menos demandado es, se colapsa el SQL Server? Perdón, no te lo
>> > había
>> > mencionado: se colapsó el servicio de datos, pues mi aplicación se pudo
>> > reiniciar perfectamente, pero ya no se pudo conectar, enviándome el
>> > mismo
>> > mensaje de error.
>> >
>> > "MAXI" wrote:
>> >
>> >> Hola, podria ser un problema de pool, tambien podria ser un problema
>> >> de
>> >> red.
>> >> Probaste con aumentar el Timeout?
>> >>
>> >>
>> >>
>> >> Maxi
>> >>
>> >> Buenos Aires - Argentina
>> >> Desarrollador .NET 3 Estrellas
>> >> Microsoft User Group (MUG)
>> >>
>> >> "HPMig" escribió en el mensaje
>> >> news:
>> >> > Desarrollé una apl. telefónica, en C#, muy demandante (cálculo de
>> >> > ACD)
>> >> > de
>> >> > un
>> >> > call center que recibe en prom. 9000 llamadas diarias. Su desempeño
>> >> > parece
>> >> > ser bueno en cuanto a uso de memoria y tiempo de proc. Sin embargo,
>> >> > después
>> >> > de un periodo de dos semanas obtengo el siguiente error: "Timeout
>> >> > expired.
>> >> > The timeout period elapsed prior to completion of the operation or
>> >> > the
>> >> > server
>> >> > is not responding". Lo extraño es que ocurrió alrededor de las 3:00
>> >> > am,
>> >> > cuando el tráfico de llamadas es muy bajo. En mi cadena de conexión
>> >> > no
>> >> > inhabilito el "pool", dejo el default de 100 conexiones, ni el
>> >> > timeout
>> >> > (30
>> >> > s). ¿podría ser un problema del pool?
>> >>
>> >>
>> >>
>>
>>
>>

Afectuosos saludos Eladio, y muchas gracias por tu interés.

Fíjate que no estuve en sitio durante la falla, pero mis archivos de
bitácora (log) me indicaron todo lo que ya mencioné. La aplicación la tenemos
funcionando en Tijuana, Méx. y yo radico en Méx. D. F., y en una de las
visitas que hicimos al cliente, también se colapsó un SQL Server y mandaba el
mismo error, y noté que algunas aplicaciones que usaban el "pool" tenían
muchas conexiones. El modelo que usamos en nuestras aplicaciones es:
asíncrono a la entrada, síncrono a la salida. Es decir, yo recibo las
peticiones (mensajes) de manera asíncrona y las encolo (las "seralizo"... las
sincronizo pues), haciendo que una a la vez sea enviada a SQL Server. Me
atrevería a decirte que necesito sólo una conexión para toda la operación:
¿porqué el "pool" necesita, y mantiene, tantas conexiones "vivas"?

"Eladio Rincón" escribió:

ah si? y que pasaba? no se liberaban las conexiones? crecían indefinidamente
los SPIDs en sysprocesses?

Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"Maxi" wrote in message
news:
> Hola, sip, tienes razon!! pero me ha pasado algo parecido con el DAAB en
> unas pruebas que hice :(
>
>
> Salu2
> Maxi
>
>
> "Eladio Rincón" escribió en el mensaje
> news:
> > Hola Maxi,
> >
> > aquí hay un artículo interesante sobre pooling:
> > http://www.netveloper.com/contenido.aspx?IDA&IDAP=0&IDC9&IDP=0
> >
> > de todas formas, el pooling no debe ser problema porque mientras la
> > conexión
> > está en el pool no existe comunicación entre cliente y servidor; consume
> > recursos en el servidor (mantener una conexión abierta), y en el cliente
> > (mantener el objeto connection en memoria)
> >
> > Eladio Rincón
> > SQL Server MVP
> >
> > Solid Quality Learning (http://www.solidqualitylearning.com)
> > "Comparte lo que sabes, aprende lo que no sepas", FGG
> >
> > Consulte el histórico del grupo en Google
> > http://groups.google.com/groups?gro....sqlserver
> >
> > ¿Te interesa participar en las reuniones
> > del grupo de Usuarios de SQL-Server y .NET
> > Se harán en levante de España, (Alicante o Murcia)?
> >
> > "MAXI" wrote in message
> > news:#
> >> Hola, mmm, para mi lo que estas teniendo es un alto consumo de ancho de
> >> banda hacia el servidor de datos :(
> >>
> >> Probar lo del pool es simple, sacalo de la cadena de conexion y
probamos
> >>
> >> Preguntas:
> >>
> >> 1) Estas usando Sp' o envias consultas desde la aplicacion?
> >> 2) Tenes los service Pack instalados del Sqlserver y el SO?
> >> 3) Podes medir el ancho de banda en que consumo esta?
> >>
> >> Empecemos por aca y vayamos descartando temas ;)
> >>
> >> Un abrazo
> >>
> >>
> >>
> >>
> >> Maxi
> >>
> >> Buenos Aires - Argentina
> >> Desarrollador .NET 3 Estrellas
> >> Microsoft User Group (MUG)
> >>
> >> "hpmig" escribió en el mensaje
> >> news:
> >> > Mil gracias por responder. Te ampliaré un poco más el escenario: este
> >> > módulo
> >> > de ACD, forma parte de una solución CTI que se conecta, vía socket
> > TCP/IP,
> >> > a
> >> > un servidor (Switch telefónico) que le envía paquetes con la
> >> > información
> >> > de
> >> > la llamada arribante. El ACD con esta info. consulta al serv. de SQL
> > para,
> >> > también mediante un paq. vía red, indicarle al Switch cómo tratar la
> >> > llamada.
> >> > Cuando tuve que finalizar la aplicación, que es multithread (una
thread
> >> > para
> >> > mensajes de entrada y otra para los de salida), había procesado
> > alrededor
> >> > de
> >> > 25 millones de mensajes de entrada y unos 12 millones de salida. En
un
> >> > estimado, de los 25 millones de entrada, un 70% necesitan consultar
la
> >> > base
> >> > de datos. Estoy utilizando la librería DAAB para .NET 1.1, es decir,
> >> > cierro
> >> > conexiones después de toda actividad. Claro, el pool mantiene, se
> > supone,
> >> > cierto número de conexiones "dormidas". Cuando inhabilito el pool,
> > cierra
> >> > perfectamente, ahora sí, la conexión que uso. Aumentar el timeout no
me
> >> > sería
> >> > útil, pues cuando una llamada entra, debo contestarle lo más rápido
> >> > posible:
> >> > si no le contesto a la llamada en menos de 15 seg. se colgará. ¿Cómo
> > puedo
> >> > saber si es un problema de pool? ¿Porqué después de manejar tantas
> >> > consultas,
> >> > de manera tan crítica, con un buen desempeño durante 2 semanas,
> >> > súbitamente,
> >> > cuando menos demandado es, se colapsa el SQL Server? Perdón, no te lo
> >> > había
> >> > mencionado: se colapsó el servicio de datos, pues mi aplicación se
pudo
> >> > reiniciar perfectamente, pero ya no se pudo conectar, enviándome el
> > mismo
> >> > mensaje de error.
> >> >
> >> > "MAXI" wrote:
> >> >
> >> >> Hola, podria ser un problema de pool, tambien podria ser un problema
> >> >> de
> >> >> red.
> >> >> Probaste con aumentar el Timeout?
> >> >>
> >> >>
> >> >>
> >> >> Maxi
> >> >>
> >> >> Buenos Aires - Argentina
> >> >> Desarrollador .NET 3 Estrellas
> >> >> Microsoft User Group (MUG)
> >> >>
> >> >> "HPMig" escribió en el mensaje
> >> >> news:
> >> >> > Desarrollé una apl. telefónica, en C#, muy demandante (cálculo de
> > ACD)
> >> >> > de
> >> >> > un
> >> >> > call center que recibe en prom. 9000 llamadas diarias. Su
desempeño
> >> >> > parece
> >> >> > ser bueno en cuanto a uso de memoria y tiempo de proc. Sin
embargo,
> >> >> > después
> >> >> > de un periodo de dos semanas obtengo el siguiente error: "Timeout
> >> >> > expired.
> >> >> > The timeout period elapsed prior to completion of the operation or
> > the
> >> >> > server
> >> >> > is not responding". Lo extraño es que ocurrió alrededor de las
3:00
> > am,
> >> >> > cuando el tráfico de llamadas es muy bajo. En mi cadena de
conexión
> > no
> >> >> > inhabilito el "pool", dejo el default de 100 conexiones, ni el
> > timeout
> >> >> > (30
> >> >> > s). ¿podría ser un problema del pool?
> >> >>
> >> >>
> >> >>
> >>
> >>
> >
> >
>
>

la puedes conseguir aquí:
http://www.gotdotnet.com/workspaces...ce.aspx?idÂ0d12b0-af52-402b-9b7c-aaeb21d1f431

Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"hpmig" wrote in message
news:

Uso esta:

[assembly: AssemblyVersion("2.0.0.0")]

¿dónde consigo la 3.1?

Gracias.

"Maxi" escribió:

> Hola, estas usando la version 3.1 del DAAB?
>
> Otra cosa, fijate el consumo de red, que velocidad y equipos tiene esa

red?

>
>
> Salu2
> Maxi
>
>
> "hpmig" escribió en el mensaje
> news:
> > Saludos.
> >
> > 1. Utilizo exclusivamente stored procedures, tanto de consulta, como

de

> > actualización. Para "llamarlos", hago uso de Data Access Application

Block

> > (DAAB), en su versión p/.NET Framework 1.1 (mi apl. la desarrollé en

C#

> > 2003).
> >
> > 2. Tanto el servidor de SQL, como mi aplicación, "corren" en el mismo
> > equipo: W2K Server con SP 4, 2 procesadores Xeon 2.4Ghz (HT - es

decir,

> > están
> > disponibles 4 procesadores), 3GB RAM. El SQL Server tiene instalado el

SP

> > 3a
> > ( Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002

14:22:05

> > Copyright (c) 1988-2003 Microsoft Corporation Standard Edition on

Windows

> > NT
> > 5.0 (Build 2195: Service Pack 4) ).
> >
> > 3. ¿cómo puedo medir el ancho de banda?
> >
> > Gracias.
> >
> > "MAXI" escribió:
> >
> >> Hola, mmm, para mi lo que estas teniendo es un alto consumo de ancho

de

> >> banda hacia el servidor de datos :(
> >>
> >> Probar lo del pool es simple, sacalo de la cadena de conexion y

probamos

> >>
> >> Preguntas:
> >>
> >> 1) Estas usando Sp' o envias consultas desde la aplicacion?
> >> 2) Tenes los service Pack instalados del Sqlserver y el SO?
> >> 3) Podes medir el ancho de banda en que consumo esta?
> >>
> >> Empecemos por aca y vayamos descartando temas ;)
> >>
> >> Un abrazo
> >>
> >>
> >>
> >>
> >> Maxi
> >>
> >> Buenos Aires - Argentina
> >> Desarrollador .NET 3 Estrellas
> >> Microsoft User Group (MUG)
> >>
> >> "hpmig" escribió en el mensaje
> >> news:
> >> > Mil gracias por responder. Te ampliaré un poco más el escenario:

este

> >> > módulo
> >> > de ACD, forma parte de una solución CTI que se conecta, vía socket
> >> > TCP/IP,
> >> > a
> >> > un servidor (Switch telefónico) que le envía paquetes con la
> >> > información
> >> > de
> >> > la llamada arribante. El ACD con esta info. consulta al serv. de

SQL

> >> > para,
> >> > también mediante un paq. vía red, indicarle al Switch cómo tratar

la

> >> > llamada.
> >> > Cuando tuve que finalizar la aplicación, que es multithread (una

thread

> >> > para
> >> > mensajes de entrada y otra para los de salida), había procesado
> >> > alrededor
> >> > de
> >> > 25 millones de mensajes de entrada y unos 12 millones de salida. En

un

> >> > estimado, de los 25 millones de entrada, un 70% necesitan consultar

la

> >> > base
> >> > de datos. Estoy utilizando la librería DAAB para .NET 1.1, es

decir,

> >> > cierro
> >> > conexiones después de toda actividad. Claro, el pool mantiene, se
> >> > supone,
> >> > cierto número de conexiones "dormidas". Cuando inhabilito el pool,
> >> > cierra
> >> > perfectamente, ahora sí, la conexión que uso. Aumentar el timeout

no me

> >> > sería
> >> > útil, pues cuando una llamada entra, debo contestarle lo más rápido
> >> > posible:
> >> > si no le contesto a la llamada en menos de 15 seg. se colgará.

¿Cómo

> >> > puedo
> >> > saber si es un problema de pool? ¿Porqué después de manejar tantas
> >> > consultas,
> >> > de manera tan crítica, con un buen desempeño durante 2 semanas,
> >> > súbitamente,
> >> > cuando menos demandado es, se colapsa el SQL Server? Perdón, no te

lo

> >> > había
> >> > mencionado: se colapsó el servicio de datos, pues mi aplicación se

pudo

> >> > reiniciar perfectamente, pero ya no se pudo conectar, enviándome el
> >> > mismo
> >> > mensaje de error.
> >> >
> >> > "MAXI" wrote:
> >> >
> >> >> Hola, podria ser un problema de pool, tambien podria ser un

problema

> >> >> de
> >> >> red.
> >> >> Probaste con aumentar el Timeout?
> >> >>
> >> >>
> >> >>
> >> >> Maxi
> >> >>
> >> >> Buenos Aires - Argentina
> >> >> Desarrollador .NET 3 Estrellas
> >> >> Microsoft User Group (MUG)
> >> >>
> >> >> "HPMig" escribió en el mensaje
> >> >> news:
> >> >> > Desarrollé una apl. telefónica, en C#, muy demandante (cálculo

de

> >> >> > ACD)
> >> >> > de
> >> >> > un
> >> >> > call center que recibe en prom. 9000 llamadas diarias. Su

desempeño

> >> >> > parece
> >> >> > ser bueno en cuanto a uso de memoria y tiempo de proc. Sin

embargo,

> >> >> > después
> >> >> > de un periodo de dos semanas obtengo el siguiente error:

"Timeout

> >> >> > expired.
> >> >> > The timeout period elapsed prior to completion of the operation

or

> >> >> > the
> >> >> > server
> >> >> > is not responding". Lo extraño es que ocurrió alrededor de las

3:00

> >> >> > am,
> >> >> > cuando el tráfico de llamadas es muy bajo. En mi cadena de

conexión

> >> >> > no
> >> >> > inhabilito el "pool", dejo el default de 100 conexiones, ni el
> >> >> > timeout
> >> >> > (30
> >> >> > s). ¿podría ser un problema del pool?
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>

Hola,

lo que hace pooling es que una vez recibido el evento close de objeto
connection, en lugar de cerrar realmente la conexión con el servidor, se
guarda en el pool para su reutilización, de esta forma ADO.NET "engaña" al
servidor no notificandole el cierre de la conexión (para que la mantenga
viva); el artículo un par de mensajes más arriba te puede ayudar a entender
pooling.

Si el sintoma que comenta Maxi es correcto, cuando la aplicación cliente
pasa del máximo número de conexiones permitidas en el pool, los intentos de
conexión devloverán un "timeout expired"; para comprobarlo si realmente se
están perdiendo conexiones que no se cierrar de manera adecuad, intentaría
monitorizar en profiler los eventos "Audit login" y "Audit loggoff"

Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"hpmig" wrote in message
news:

Afectuosos saludos Eladio, y muchas gracias por tu interés.

Fíjate que no estuve en sitio durante la falla, pero mis archivos de
bitácora (log) me indicaron todo lo que ya mencioné. La aplicación la

tenemos

funcionando en Tijuana, Méx. y yo radico en Méx. D. F., y en una de las
visitas que hicimos al cliente, también se colapsó un SQL Server y mandaba

el

mismo error, y noté que algunas aplicaciones que usaban el "pool" tenían
muchas conexiones. El modelo que usamos en nuestras aplicaciones es:
asíncrono a la entrada, síncrono a la salida. Es decir, yo recibo las
peticiones (mensajes) de manera asíncrona y las encolo (las "seralizo"...

las

sincronizo pues), haciendo que una a la vez sea enviada a SQL Server. Me
atrevería a decirte que necesito sólo una conexión para toda la operación:
¿porqué el "pool" necesita, y mantiene, tantas conexiones "vivas"?

"Eladio Rincón" escribió:

> ah si? y que pasaba? no se liberaban las conexiones? crecían

indefinidamente

> los SPIDs en sysprocesses?
>
> Eladio Rincón
> SQL Server MVP
>
> Solid Quality Learning (http://www.solidqualitylearning.com)
> "Comparte lo que sabes, aprende lo que no sepas", FGG
>
> Consulte el histórico del grupo en Google
> http://groups.google.com/groups?gro....sqlserver
>
> ¿Te interesa participar en las reuniones
> del grupo de Usuarios de SQL-Server y .NET
> Se harán en levante de España, (Alicante o Murcia)?
>
> "Maxi" wrote in message
> news:
> > Hola, sip, tienes razon!! pero me ha pasado algo parecido con el DAAB

en

> > unas pruebas que hice :(
> >
> >
> > Salu2
> > Maxi
> >
> >
> > "Eladio Rincón" escribió en el mensaje
> > news:
> > > Hola Maxi,
> > >
> > > aquí hay un artículo interesante sobre pooling:
> > > http://www.netveloper.com/contenido.aspx?IDA&IDAP=0&IDC9&IDP=0
> > >
> > > de todas formas, el pooling no debe ser problema porque mientras la
> > > conexión
> > > está en el pool no existe comunicación entre cliente y servidor;

consume

> > > recursos en el servidor (mantener una conexión abierta), y en el

cliente

> > > (mantener el objeto connection en memoria)
> > >
> > > Eladio Rincón
> > > SQL Server MVP
> > >
> > > Solid Quality Learning (http://www.solidqualitylearning.com)
> > > "Comparte lo que sabes, aprende lo que no sepas", FGG
> > >
> > > Consulte el histórico del grupo en Google
> > > http://groups.google.com/groups?gro....sqlserver
> > >
> > > ¿Te interesa participar en las reuniones
> > > del grupo de Usuarios de SQL-Server y .NET
> > > Se harán en levante de España, (Alicante o Murcia)?
> > >
> > > "MAXI" wrote in message
> > > news:#
> > >> Hola, mmm, para mi lo que estas teniendo es un alto consumo de

ancho de

> > >> banda hacia el servidor de datos :(
> > >>
> > >> Probar lo del pool es simple, sacalo de la cadena de conexion y
> probamos
> > >>
> > >> Preguntas:
> > >>
> > >> 1) Estas usando Sp' o envias consultas desde la aplicacion?
> > >> 2) Tenes los service Pack instalados del Sqlserver y el SO?
> > >> 3) Podes medir el ancho de banda en que consumo esta?
> > >>
> > >> Empecemos por aca y vayamos descartando temas ;)
> > >>
> > >> Un abrazo
> > >>
> > >>
> > >>
> > >>
> > >> Maxi
> > >>
> > >> Buenos Aires - Argentina
> > >> Desarrollador .NET 3 Estrellas
> > >> Microsoft User Group (MUG)
> > >>
> > >> "hpmig" escribió en el mensaje
> > >> news:
> > >> > Mil gracias por responder. Te ampliaré un poco más el escenario:

este

> > >> > módulo
> > >> > de ACD, forma parte de una solución CTI que se conecta, vía

socket

> > > TCP/IP,
> > >> > a
> > >> > un servidor (Switch telefónico) que le envía paquetes con la
> > >> > información
> > >> > de
> > >> > la llamada arribante. El ACD con esta info. consulta al serv. de

SQL

> > > para,
> > >> > también mediante un paq. vía red, indicarle al Switch cómo tratar

la

> > >> > llamada.
> > >> > Cuando tuve que finalizar la aplicación, que es multithread (una
> thread
> > >> > para
> > >> > mensajes de entrada y otra para los de salida), había procesado
> > > alrededor
> > >> > de
> > >> > 25 millones de mensajes de entrada y unos 12 millones de salida.

En

> un
> > >> > estimado, de los 25 millones de entrada, un 70% necesitan

consultar

> la
> > >> > base
> > >> > de datos. Estoy utilizando la librería DAAB para .NET 1.1, es

decir,

> > >> > cierro
> > >> > conexiones después de toda actividad. Claro, el pool mantiene, se
> > > supone,
> > >> > cierto número de conexiones "dormidas". Cuando inhabilito el

pool,

> > > cierra
> > >> > perfectamente, ahora sí, la conexión que uso. Aumentar el timeout

no

> me
> > >> > sería
> > >> > útil, pues cuando una llamada entra, debo contestarle lo más

rápido

> > >> > posible:
> > >> > si no le contesto a la llamada en menos de 15 seg. se colgará.

¿Cómo

> > > puedo
> > >> > saber si es un problema de pool? ¿Porqué después de manejar

tantas

> > >> > consultas,
> > >> > de manera tan crítica, con un buen desempeño durante 2 semanas,
> > >> > súbitamente,
> > >> > cuando menos demandado es, se colapsa el SQL Server? Perdón, no

te lo

> > >> > había
> > >> > mencionado: se colapsó el servicio de datos, pues mi aplicación

se

> pudo
> > >> > reiniciar perfectamente, pero ya no se pudo conectar, enviándome

el

> > > mismo
> > >> > mensaje de error.
> > >> >
> > >> > "MAXI" wrote:
> > >> >
> > >> >> Hola, podria ser un problema de pool, tambien podria ser un

problema

> > >> >> de
> > >> >> red.
> > >> >> Probaste con aumentar el Timeout?
> > >> >>
> > >> >>
> > >> >>
> > >> >> Maxi
> > >> >>
> > >> >> Buenos Aires - Argentina
> > >> >> Desarrollador .NET 3 Estrellas
> > >> >> Microsoft User Group (MUG)
> > >> >>
> > >> >> "HPMig" escribió en el mensaje
> > >> >> news:
> > >> >> > Desarrollé una apl. telefónica, en C#, muy demandante (cálculo

de

> > > ACD)
> > >> >> > de
> > >> >> > un
> > >> >> > call center que recibe en prom. 9000 llamadas diarias. Su
> desempeño
> > >> >> > parece
> > >> >> > ser bueno en cuanto a uso de memoria y tiempo de proc. Sin
> embargo,
> > >> >> > después
> > >> >> > de un periodo de dos semanas obtengo el siguiente error:

"Timeout

> > >> >> > expired.
> > >> >> > The timeout period elapsed prior to completion of the

operation or

> > > the
> > >> >> > server
> > >> >> > is not responding". Lo extraño es que ocurrió alrededor de las
> 3:00
> > > am,
> > >> >> > cuando el tráfico de llamadas es muy bajo. En mi cadena de
> conexión
> > > no
> > >> >> > inhabilito el "pool", dejo el default de 100 conexiones, ni el
> > > timeout
> > >> >> > (30
> > >> >> > s). ¿podría ser un problema del pool?
> > >> >>
> > >> >>
> > >> >>
> > >>
> > >>
> > >
> > >
> >
> >
>
>
>

Hola:

Me parece que tu problema radica en los tiempos de respuesta de tu
aplicacion, sumada al hecho de que el ancho de banda no te esta ayudando.

Trabajo en un sitio donde tenemos una estructura parecida a la que
mencionas, y tambien, cada cierto tiempo eramos victimas de caidas de
conexion por timeout.

Hay cinco componentes principales que le dan mayor performance a lo que
estas analizando:

1) El buffer de las placas de red
2) El buffer del server
3) Archivos de paginacion
4) Hilos de Ejecucion
5) Ancho de banda de entrada y de salida

El problema radica en las siguientes combinaciones:

1) El buffer de sistema es menor que el de las placas de red, con lo cual se
generan excesos y los paquetes son descartados.
2) El archivo de paginacion no es capaz de de vaciar el buffer de sistema a
tu aplicacion desde el buffer de las placas con lo cual se encolan paquetes
y esto desemboca a la larga en un timeout.
3) Los hilos de ejecucion si bien se manejan a nivel aplicacion de forma
separada desembocan en un unico buffer de red, con lo cual la prioridad la
da el buffer y no la aplicacion.
4) El ancho de banda de entrada supera al de salida con lo cual los mensajes
se encolan y se desborda alguno de los dos buffers.

Nosotros solucionamos el problema armando un team de 5 placas de red
(tenemos un compaq proliant 1.3 con 2gb de ram). Este team es full
tolerance, con dos placas de reserva. Esto nos garantiza que el server
reciba 100mb extensibles a 200 con la placa de reserva activada y devuelva
200mb llegando hasta 300 con la placa de reserva activada.

No se bien cual es tu configuracion de red, pero nuestro problema lo
resolvimos con esto.

Un abrazo

Roberto


"HPMig" escribió en el mensaje
news:

Desarrollé una apl. telefónica, en C#, muy demandante (cálculo de ACD) de

un

call center que recibe en prom. 9000 llamadas diarias. Su desempeño parece
ser bueno en cuanto a uso de memoria y tiempo de proc. Sin embargo,

después

de un periodo de dos semanas obtengo el siguiente error: "Timeout expired.
The timeout period elapsed prior to completion of the operation or the

server

is not responding". Lo extraño es que ocurrió alrededor de las 3:00 am,
cuando el tráfico de llamadas es muy bajo. En mi cadena de conexión no
inhabilito el "pool", dejo el default de 100 conexiones, ni el timeout (30
s). ¿podría ser un problema del pool?