Timeout Expired

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?

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, 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?

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?
>>
>>
>>

igual te sirve esto:
http://www.bandwidthplace.com/speedtest/

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:

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?
> >>
> >>
> >>
>
>
>