asp-classic - for - submit asp classic
Thread Sleep en Classic ASP? (11)
var shell = Server.CreateObject("WScript.Shell");
shell.run("CHOICE /C:AB /D:A /T:1 > NUL", 1, true);
Estoy revisando una aplicación antigua que está escrita en ASP / VbScript clásico.
Tiene una función para enviar un correo electrónico a los miembros de la aplicación, pero debido a que la lista de miembros es bastante grande, el servidor rechaza los nuevos correos electrónicos después de que se envían los primeros cien o más.
He escrito un código para enviar correos electrónicos en ráfagas de 20, pero esto todavía no funciona. Creo que quizás hacer que duerma por un segundo entre ráfagas podría funcionar correctamente.
Sin embargo, parece que no puedo encontrar un método de tipo Thread.Sleep en VbScript.
¿Hay alguno?
Esto parece un buen truco:
http://www.ehow.com/how_2001270_sleep-asp-using-ado.html
El truco es crear un objeto de conexión ADO y luego tratar de conectarse a un servidor inexistente. Esto se bloqueará durante la configuración de tiempo de espera del objeto de conexión.
No que yo sepa. Tendrá que usar algún código externo escrito en la clase VB o lo que sea para hacerlo.
O ocupado, espera (gak).
Sabes, este es uno de esos momentos en los que creo que configurar una cola privada de MSMQ podría ser una buena cosa. Coloque los correos electrónicos que desea enviar en la cola y haga que un servicio .NET recientemente desarrollado realice el envío. ¡Esto liberará su aplicación ASP.NET y le permitirá administrar su envío centralmente!
Tenga en cuenta que IIS tiene un valor predeterminado de tiempo de espera de ejecución de script de ASP predeterminado de 90 segundos, por lo que la ejecución de scripts grandes que envían volúmenes de correo electrónico de esta manera agotarán el tiempo de espera a menos que cambie el tiempo de espera de ASP.
también hay un buen hta hack que debería funcionar. Busque la función de sueño sintético A aquí: http://www.mvps.org/scripting/rube/index.htm
Esta rutina espera cualquier cantidad de tiempo y no usa CPU:
Function asp_Wait(nMilliseconds) Dim oShell '''' VBS: Set oShell= Wscript.CreateObject("WScript.Shell") '''' ASP: Set oShell= Server.CreateObject("WScript.Shell") Call oShell.run("ping 1.1.1.1 -n 1 -w " & nMilliseconds,1,TRUE) '''' Option TRUE: Wait until ping is complete '''' 1000 milli-second wait is 1 second End Function
¿Estás usando CDO? Como esto está etiquetado como ASP clásico, supongo que sí.
Si es así si puedes usar
myMail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/sendusing") = 1 ''(que se envía mediante el pickup)
en lugar de
myMail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/sendusing") = 2 ''(que se envía usando el puerto)
Es más confiable porque escribe el correo electrónico en el archivo (normalmente C: / inetpub / mailroot / pickup) y el servidor SMTP de IIS verifica si la carpeta contiene correo nuevo y volverá a intentarlo si falla la primera vez. El truco es que tienes que configurar SMTP dentro del complemento IIS.
Puedes usar :
<html>
<head>
<title>Sleep</title>
</head>
<body>
<%
function Sleep(seconds)
set oShell = CreateObject("Wscript.Shell")
cmd = "%COMSPEC% /c timeout " & seconds & " /nobreak"
oShell.Run cmd,0,1
End function
Sleep(5)
response.write("End")
%>
</body>
</html>
La respuesta es no usar el servidor para esperar, usar el cliente. Puede escribir un javascript que siga llamando a Send () cada segundo usando setInterval hasta que la cola esté vacía. Use una llamada Ajax para enviar un correo electrónico usando un script del lado del servidor. Luego, al regresar la llamada ajax, también puede indicar en la página html que se ha enviado un correo electrónico.
Perdón por que esta respuesta no esté estrictamente relacionada con la pregunta, pero al tratar de responder una pregunta, se amplió mucho para obtener comentarios.
@shahka, la diferencia es que, cuando intenta conectarse a un DB, el código entra en un "estado de espera" (como una devolución de llamada), por lo que no se utiliza el tiempo de CPU. No importa lo que esté haciendo SESSION o THREAD, importa lo que ELCP / Core esté haciendo.
Por ejemplo, busque una CPU anterior no multi-core. Configure su muestra para que duerma durante 10 segundos, luego corra durante 2-5 segundos más o menos, luego vuelva a dormir por 10. Haga eso unas 20,000 veces. Mientras se está ejecutando, intente y use el cuadro, vea qué tan receptivo es. Mover las ventanas, ver el uso de la CPU, etc.
ESO te da un ejemplo de lo que le está sucediendo al servidor web de este hombre. No responde, porque el programador de hilos tenderá a "favorecer" a la CPU / núcleo que NO está "centrifugada" (como lo llamamos). Por lo tanto, TODAS las solicitudes web, las operaciones del sistema operativo, etc. se realizarán en el otro núcleo, lo que hará que se sobrecarguen, dándoles la sensación de que también se han "activado".
Ahora, tienes momentos en los que puedes apretar una CPU y no importará. Pero, en todos mis años de programación, nunca me pareció necesario escribir un ciclo tan estricto (a propósito). Algunos de ellos vuelven a hacer las cosas de la manera correcta y de la manera incorrecta. Hacer algo de la manera incorrecta a menudo FUNCIONARÁ, pero eso no significa que funcione correctamente.
Si quiere un buen ejemplo de esto, vaya y elija casi cualquier virus en el planeta, y analícelo. Encontrarás que para hacer daño, ellos (los escritores de virus) a menudo tienen que hacer las cosas de la manera "incorrecta". Claro, hace el trabajo, pero también rompe el virus, digamos, una versión de idioma diferente de Windows, o bloquea toda la máquina anulando su propósito, etc.
Greg Hewgill fue uno de mis primeros maestros sobre este tipo de cosas, y como trabajé con él durante muchos años, y lo apoyé, y más tarde controlé su software, aprendí mucho de él, en el mismo sentido que yo. tratando de decirte por qué tu muestra de código no es buena. estrictamente hablando, el código está bien. Funciona. Está bien escrito. Pero no FUNCIONA correctamente y tiene efectos secundarios adversos que otros programadores que no están maduros y que podrían estar leyendo en busca de conocimiento no entienden completamente. POR ESO NO RECOMIENDO SU MUESTRA.