Si vous connaissez Response.Flush et Response.Clear, vous n'avez pas à attendre comme ça. Chaque fois qu'une page HTML est générée, Response.write est utilisé pour renvoyer immédiatement un message indiquant que l'enregistrement de la base de données a généré du HTML. Lorsqu'un programmeur écrit une page HTML statique générée à partir d'une page ASP, si un grand nombre de pages sont générées en même temps, il doit avoir rencontré un long processus d'attente où la barre de progression en bas du navigateur affiche 3%, 6 %, 10%, etc. qui augmentent lentement. Pendant ce processus d'attente, vous ne savez pas quel enregistrement a été généré sur la page, vous ne pouvez donc qu'attendre les yeux grands ouverts.
Si vous connaissez Response.Flush et Response.Clear, vous n'avez pas à attendre comme ça. Chaque fois qu'une page HTML est générée, Response.write est utilisé pour renvoyer immédiatement un message indiquant que l'enregistrement de la base de données a généré du HTML.
De cette façon, lorsqu'un grand nombre de pages sont générées en même temps, vous n'êtes plus seul à regarder une page vierge mais simplement étourdi par la barre de progression qui change lentement en bas du navigateur. Vous pouvez toujours savoir laquelle. L'enregistrement de la base de données a été généré Même en cas d'accident, tel qu'un crash, une panne de courant, etc., vous connaîtrez la date à laquelle la prochaine génération doit être enregistrée et redémarrée pour générer du HTML. N'est-ce pas génial ? C'est une barre de progression et plus spécifique.
Haha, ne vous inquiétez pas, regardons d'abord la signification de Response.Flush et Response.Clear.
La méthode Flush de l'objet Response envoie immédiatement la sortie dans le tampon. Cette méthode provoquera une erreur d’exécution si Response.Buffer n’est pas défini sur TRUE. Syntaxe : Response.Flush ; Remarque : Si la méthode Flush est appelée sur une page ASP, le serveur répondra à la requête keep-alive sur la page. Appliqué aux objets Response.
Concernant Buffer, voici une introduction. Buffer se traduit littéralement de l'anglais par zone tampon. Ici, nous l'appelons tampon car ce n'est pas seulement un nom, mais aussi un verbe.
Le tampon est un endroit où une série de données est stockée. Les données obtenues par le client peuvent être sorties directement du résultat de l'exécution du programme ou sorties du tampon. Mais il y a une différence de vitesse entre ces deux méthodes : sur le web, lorsqu'un programme ASP n'est pas demandé plusieurs fois, il n'y a fondamentalement aucune différence entre les deux, du moins on ne la sent pas. Mais lorsque de nombreuses personnes demandent un programme asp, la vitesse est différente. S'il n'y a pas de tampon, alors le résultat obtenu par chaque client qui demande le programme ASP est le résultat obtenu en exécutant le programme ASP une fois. Si le programme ASP est mis en mémoire tampon à l'avance, le résultat obtenu par chaque client est le résultat mis en mémoire tampon. Le résultat de la zone n'est pas le résultat d'une exécution unique du programme. Par exemple, 1 000 utilisateurs accèdent à une page ASP en même temps. Si le programme ASP n'est pas mis en mémoire tampon, le programme sera exécuté mille fois, ce qui augmentera la charge sur le serveur et entraînera une ouverture plus lente du client ; le programme ASP est mis en mémoire tampon, alors le résultat sera différent. Chaque client obtient les données directement à partir du tampon et le serveur n'augmentera pas le nombre d'exécutions du programme en raison de l'accès accru, donc la vitesse à laquelle le client ouvre la page sera plus lent que dans le cas précédent. C'est l'avantage de Buffer.
Concernant Response.clear, la méthode Clear supprime toutes les sorties HTML dans le tampon. Mais la méthode Clear supprime uniquement le corps de la réponse et non les en-têtes de réponse. Vous pouvez utiliser cette méthode pour gérer les conditions d'erreur. Notez que cette méthode provoquera une erreur d’exécution si Response.Buffer n’est pas défini sur TRUE. Syntaxe : Response.Clear ; appliqué aux objets Response.
Eh bien, si vous souhaitez obtenir l'effet d'une sortie immédiate, ajoutez simplement Response.Flush et Response.Clear après les informations d'invite de sortie souhaitées dans le corps de la boucle. comme:
<%
pour i=1 à 2000
pour i1=1 à 3000
'' Boucle vide, prolongeant chaque temps d'exécution
suivant
Réponse.écrire i&)
Réponse.Flush
Réponse.Effacer
suivant
%>
Après avoir exécuté l'instruction asp ci-dessus, vous constaterez que la sortie est sortie une par une. Si vous l'exécutez une fois, elle sera sortie une fois.
Mais j'ai vu quelqu'un sur Internet dire cela à plusieurs reprises, nous constatons que même si nous utilisons Response.Flush(), les informations précédentes ne sont pas envoyées au client pour affichage. On nous présente toujours un écran blanc. Après des tests répétés, je suis arrivé à une conclusion : le contenu du vidage doit être d'au moins 256 octets. Autrement dit, seulement si la compilation génère au moins 256 octets de données, les informations peuvent être envoyées au client et affichées après l'exécution de Response.Flush().
Il est étrange que l'instruction que j'ai donnée ci-dessus ait effectivement pour effet d'afficher un par un et ne génère pas 256 octets à l'avance. Vous pouvez enregistrer l'instruction ci-dessus dans le Bloc-notes et l'exécuter pour voir, l'effet est affiché ligne par ligne. Les opinions que j’ai énumérées représentent uniquement les opinions personnelles de flymorn et ne peuvent pas être utilisées à d’autres fins.
Si vous avez vraiment besoin de générer 256 octets au préalable, vous pouvez le faire :
<%
faible Liji
pour i=1 à 256
liji=liji&<!--Générer d'abord 256 caractères-WWW.PIAOYI.ORG-->
si len(liji)>=256 alors quittez pour
suivant
%>
Si vous avez des points de vue différents ou des résultats de tests différents, n'hésitez pas à en discuter avec moi.