Pour un serveur qui n'a pas de problème de Ram, ni de memoire virtuelle,
faut il mieux mettre des response.flush de temps en temps dans le code.
A priori :
- cela peut libérér des ressources puisque les code html est évacué avant la
fin d'execution du script
- mais cela peut aussi générer d'avantage de travail pour IIS ( plus
d'actions à réaliser)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
jbongran
Etienne Descure wrote:
Bonjour,
Pour un serveur qui n'a pas de problème de Ram, ni de memoire virtuelle, faut il mieux mettre des response.flush de temps en temps dans le code.
A priori : - cela peut libérér des ressources puisque les code html est évacué avant la fin d'execution du script - mais cela peut aussi générer d'avantage de travail pour IIS ( plus d'actions à réaliser)
Quelle solution est la meilleure selon vous ?
Merci d'avance
Etienne
Une bonne habitude (enfin la mienne;-) est d'utiliser le response.Flush dans les cas suivants : - Dès que l'on sait que l'on ne va pas utiliser server.redirect ou server.Transfert de manière à afficher au moins le titre de la page (ce qui donne aussi une impression de fluidité très agréable pour le client, et évite que ce dernier ne valide plusieurs fois un formulaire parce qu'il ne "se passe rien", bien sûr il ne faut pas compter uniquement la dessus). Pour l'anecdote je me suis retrouvé "en concurrence" avec une appli web tournant sur AS400 (websphere) alors que la mienne tournait sur un petit PIII 500 512 Mo de ram, les temps de chargement étaient identiques à 2 secondes près montre en main. Avant de mesurer la perception était que mon appli devait être deux à trois fois plus rapide. Merci le Response.Flush ;-) - Juste avant de rentrer dans une action qui peut durer longtemps (appel de procédure stockée ou requête sql lourde, ou lecture disque de fichier, ou concaténation de chaines importantes, etc...) - Dans des boucles, si placés judicieusement, cela permet de voir les lignes s'écrire en "temps réél - Juste avant de rentrer dans une portion de code qui peut planter (non je plaisante, mais pour débugger c'est pas mal.) Egalement, partout où cela est possible l'usage de Enable.SessionState False (ou quelque chose dans le genre, pas de IIS sous la main) apparait comme "donnant un peu d'air" au pages concernées Pour la charge, jamais vu l'impact d'utiliser ou pas le buffer...
Etienne Descure wrote:
Bonjour,
Pour un serveur qui n'a pas de problème de Ram, ni de memoire
virtuelle, faut il mieux mettre des response.flush de temps en temps
dans le code.
A priori :
- cela peut libérér des ressources puisque les code html est évacué
avant la fin d'execution du script
- mais cela peut aussi générer d'avantage de travail pour IIS ( plus
d'actions à réaliser)
Quelle solution est la meilleure selon vous ?
Merci d'avance
Etienne
Une bonne habitude (enfin la mienne;-) est d'utiliser le response.Flush dans
les cas suivants :
- Dès que l'on sait que l'on ne va pas utiliser server.redirect ou
server.Transfert de manière à afficher au moins le titre de la page (ce qui
donne aussi une impression de fluidité très agréable pour le client, et
évite que ce dernier ne valide plusieurs fois un formulaire parce qu'il ne
"se passe rien", bien sûr il ne faut pas compter uniquement la dessus). Pour
l'anecdote je me suis retrouvé "en concurrence" avec une appli web tournant
sur AS400 (websphere) alors que la mienne tournait sur un petit PIII 500 512
Mo de ram, les temps de chargement étaient identiques à 2 secondes près
montre en main. Avant de mesurer la perception était que mon appli devait
être deux à trois fois plus rapide. Merci le Response.Flush ;-)
- Juste avant de rentrer dans une action qui peut durer longtemps (appel de
procédure stockée ou requête sql lourde, ou lecture disque de fichier, ou
concaténation de chaines importantes, etc...)
- Dans des boucles, si placés judicieusement, cela permet de voir les lignes
s'écrire en "temps réél
- Juste avant de rentrer dans une portion de code qui peut planter (non je
plaisante, mais pour débugger c'est pas mal.)
Egalement, partout où cela est possible l'usage de Enable.SessionState False (ou quelque chose dans le genre, pas de IIS sous la main) apparait
comme "donnant un peu d'air" au pages concernées
Pour la charge, jamais vu l'impact d'utiliser ou pas le buffer...
Pour un serveur qui n'a pas de problème de Ram, ni de memoire virtuelle, faut il mieux mettre des response.flush de temps en temps dans le code.
A priori : - cela peut libérér des ressources puisque les code html est évacué avant la fin d'execution du script - mais cela peut aussi générer d'avantage de travail pour IIS ( plus d'actions à réaliser)
Quelle solution est la meilleure selon vous ?
Merci d'avance
Etienne
Une bonne habitude (enfin la mienne;-) est d'utiliser le response.Flush dans les cas suivants : - Dès que l'on sait que l'on ne va pas utiliser server.redirect ou server.Transfert de manière à afficher au moins le titre de la page (ce qui donne aussi une impression de fluidité très agréable pour le client, et évite que ce dernier ne valide plusieurs fois un formulaire parce qu'il ne "se passe rien", bien sûr il ne faut pas compter uniquement la dessus). Pour l'anecdote je me suis retrouvé "en concurrence" avec une appli web tournant sur AS400 (websphere) alors que la mienne tournait sur un petit PIII 500 512 Mo de ram, les temps de chargement étaient identiques à 2 secondes près montre en main. Avant de mesurer la perception était que mon appli devait être deux à trois fois plus rapide. Merci le Response.Flush ;-) - Juste avant de rentrer dans une action qui peut durer longtemps (appel de procédure stockée ou requête sql lourde, ou lecture disque de fichier, ou concaténation de chaines importantes, etc...) - Dans des boucles, si placés judicieusement, cela permet de voir les lignes s'écrire en "temps réél - Juste avant de rentrer dans une portion de code qui peut planter (non je plaisante, mais pour débugger c'est pas mal.) Egalement, partout où cela est possible l'usage de Enable.SessionState False (ou quelque chose dans le genre, pas de IIS sous la main) apparait comme "donnant un peu d'air" au pages concernées Pour la charge, jamais vu l'impact d'utiliser ou pas le buffer...
Etienne Descure
Merci
Je ne connais pas Enable.SessionState = False Cela sert à quoi ?
"jbongran" a écrit dans le message de news: 41058930$0$8546$
Etienne Descure wrote: > Bonjour, > > Pour un serveur qui n'a pas de problème de Ram, ni de memoire > virtuelle, faut il mieux mettre des response.flush de temps en temps > dans le code. > > A priori : > - cela peut libérér des ressources puisque les code html est évacué > avant la fin d'execution du script > - mais cela peut aussi générer d'avantage de travail pour IIS ( plus > d'actions à réaliser) > > Quelle solution est la meilleure selon vous ? > > Merci d'avance > > Etienne
Une bonne habitude (enfin la mienne;-) est d'utiliser le response.Flush
dans
les cas suivants : - Dès que l'on sait que l'on ne va pas utiliser server.redirect ou server.Transfert de manière à afficher au moins le titre de la page (ce
qui
donne aussi une impression de fluidité très agréable pour le client, et évite que ce dernier ne valide plusieurs fois un formulaire parce qu'il ne "se passe rien", bien sûr il ne faut pas compter uniquement la dessus).
Pour
l'anecdote je me suis retrouvé "en concurrence" avec une appli web
tournant
sur AS400 (websphere) alors que la mienne tournait sur un petit PIII 500
512
Mo de ram, les temps de chargement étaient identiques à 2 secondes près montre en main. Avant de mesurer la perception était que mon appli devait être deux à trois fois plus rapide. Merci le Response.Flush ;-) - Juste avant de rentrer dans une action qui peut durer longtemps (appel
de
procédure stockée ou requête sql lourde, ou lecture disque de fichier, ou concaténation de chaines importantes, etc...) - Dans des boucles, si placés judicieusement, cela permet de voir les
lignes
s'écrire en "temps réél - Juste avant de rentrer dans une portion de code qui peut planter (non je plaisante, mais pour débugger c'est pas mal.) Egalement, partout où cela est possible l'usage de Enable.SessionState > False (ou quelque chose dans le genre, pas de IIS sous la main) apparait comme "donnant un peu d'air" au pages concernées Pour la charge, jamais vu l'impact d'utiliser ou pas le buffer...
Merci
Je ne connais pas Enable.SessionState = False
Cela sert à quoi ?
"jbongran" <jbongran@free.fr> a écrit dans le message de news:
41058930$0$8546$626a14ce@news.free.fr...
Etienne Descure wrote:
> Bonjour,
>
> Pour un serveur qui n'a pas de problème de Ram, ni de memoire
> virtuelle, faut il mieux mettre des response.flush de temps en temps
> dans le code.
>
> A priori :
> - cela peut libérér des ressources puisque les code html est évacué
> avant la fin d'execution du script
> - mais cela peut aussi générer d'avantage de travail pour IIS ( plus
> d'actions à réaliser)
>
> Quelle solution est la meilleure selon vous ?
>
> Merci d'avance
>
> Etienne
Une bonne habitude (enfin la mienne;-) est d'utiliser le response.Flush
dans
les cas suivants :
- Dès que l'on sait que l'on ne va pas utiliser server.redirect ou
server.Transfert de manière à afficher au moins le titre de la page (ce
qui
donne aussi une impression de fluidité très agréable pour le client, et
évite que ce dernier ne valide plusieurs fois un formulaire parce qu'il ne
"se passe rien", bien sûr il ne faut pas compter uniquement la dessus).
Pour
l'anecdote je me suis retrouvé "en concurrence" avec une appli web
tournant
sur AS400 (websphere) alors que la mienne tournait sur un petit PIII 500
512
Mo de ram, les temps de chargement étaient identiques à 2 secondes près
montre en main. Avant de mesurer la perception était que mon appli devait
être deux à trois fois plus rapide. Merci le Response.Flush ;-)
- Juste avant de rentrer dans une action qui peut durer longtemps (appel
de
procédure stockée ou requête sql lourde, ou lecture disque de fichier, ou
concaténation de chaines importantes, etc...)
- Dans des boucles, si placés judicieusement, cela permet de voir les
lignes
s'écrire en "temps réél
- Juste avant de rentrer dans une portion de code qui peut planter (non je
plaisante, mais pour débugger c'est pas mal.)
Egalement, partout où cela est possible l'usage de Enable.SessionState > False (ou quelque chose dans le genre, pas de IIS sous la main) apparait
comme "donnant un peu d'air" au pages concernées
Pour la charge, jamais vu l'impact d'utiliser ou pas le buffer...
Je ne connais pas Enable.SessionState = False Cela sert à quoi ?
"jbongran" a écrit dans le message de news: 41058930$0$8546$
Etienne Descure wrote: > Bonjour, > > Pour un serveur qui n'a pas de problème de Ram, ni de memoire > virtuelle, faut il mieux mettre des response.flush de temps en temps > dans le code. > > A priori : > - cela peut libérér des ressources puisque les code html est évacué > avant la fin d'execution du script > - mais cela peut aussi générer d'avantage de travail pour IIS ( plus > d'actions à réaliser) > > Quelle solution est la meilleure selon vous ? > > Merci d'avance > > Etienne
Une bonne habitude (enfin la mienne;-) est d'utiliser le response.Flush
dans
les cas suivants : - Dès que l'on sait que l'on ne va pas utiliser server.redirect ou server.Transfert de manière à afficher au moins le titre de la page (ce
qui
donne aussi une impression de fluidité très agréable pour le client, et évite que ce dernier ne valide plusieurs fois un formulaire parce qu'il ne "se passe rien", bien sûr il ne faut pas compter uniquement la dessus).
Pour
l'anecdote je me suis retrouvé "en concurrence" avec une appli web
tournant
sur AS400 (websphere) alors que la mienne tournait sur un petit PIII 500
512
Mo de ram, les temps de chargement étaient identiques à 2 secondes près montre en main. Avant de mesurer la perception était que mon appli devait être deux à trois fois plus rapide. Merci le Response.Flush ;-) - Juste avant de rentrer dans une action qui peut durer longtemps (appel
de
procédure stockée ou requête sql lourde, ou lecture disque de fichier, ou concaténation de chaines importantes, etc...) - Dans des boucles, si placés judicieusement, cela permet de voir les
lignes
s'écrire en "temps réél - Juste avant de rentrer dans une portion de code qui peut planter (non je plaisante, mais pour débugger c'est pas mal.) Egalement, partout où cela est possible l'usage de Enable.SessionState > False (ou quelque chose dans le genre, pas de IIS sous la main) apparait comme "donnant un peu d'air" au pages concernées Pour la charge, jamais vu l'impact d'utiliser ou pas le buffer...
jbongran
"Etienne Descure" <etienne.descure'@photoweb.fr> a écrit dans le message de news:410609d1$0$20148$
Merci
Je ne connais pas Enable.SessionState = False Cela sert à quoi ?
A desactiver l'état de session page par page plutôt que pour tout le site ...
"Etienne Descure" <etienne.descure'@photoweb.fr> a écrit dans le message de
news:410609d1$0$20148$626a14ce@news.free.fr...
Merci
Je ne connais pas Enable.SessionState = False
Cela sert à quoi ?
A desactiver l'état de session page par page plutôt que pour tout le site
...
