Newsgroup: it.comp.www.asp
Titolo: Mantenere valori durante la navigazione e risparmiare sulle risorse del server

Ciao
vorrei il vostro parere su cosa "succhia" meno risorse per mantenere dei
dati durante la navigazione.
Non so se è maglio usare un cookie di 1 giorno di durata o una variabile di
sessione (20 min.), o usare il file global.asa o che altro?
Dovrei memorizzare semplici dati: nome, cognome, qualche stringa...non
molto.
Io per ora stò impostando sulle variabili di sessione spero di aver
azzaccato...anche perchè riguarda una intranet di pubblicazione, ma comunque
sono curioso di sapere cosa "succhia" meno se qualche d'uno sa
delucidarmi...
Grazie e Ciao Alen

Meno risorse, allora utilizza i cookies.
Se li usi senza data di scadenza si ocmportano come le variabil idi
sessione, con l'unica differenza che appena l'utente chiude il navigatore
spariscono e che ad ogni richiesta di pagina vengono trasmessi dal client al
server.
Le sessioni risiedendo sul server invece occupano risorse di questo, fino
anche a 20 minuti (dipende dal timeout impostato) dopo che l'utente si
čdisconnesso.
Se ospiti il sito su una server farm, nel caso un server vada giů, le
varibili di sessione spariscono e non si "trasmettono" da un server
all'altro (anche se in qualche modo č possibile impostare un discorso del
genere)
INsomma per farla breve intermini di risorse sarebbe preferibile utilizzare
i cookies, in termini di sicurezza, con i cookies ci vuole un pň di
accortezza dato che c'č sempre scambio da client a server del loro
contenuto.
--
:: Fate i bravi e non clonate le pecore!
:: Distractly yours... 
man...@ufologia.net

 azzaccato...anche perchè riguarda una intranet di pubblicazione, ma
stai utilizzando il sistema peggiore... cioe' quello che consuma piu'
risorse in assoluto...
alternative:
cookies (consigliato) se non metti la data di scadenza risiede nella memoria
del client
file (un po' lento per recuperare i dati)
database (prestazionale per recuperare i dati)
cookies + database (salvi nel cookies l'id dove sono i dati della
sessione...)
ciao
--
Lino Mari [mod - it.economia.e-commerce]
http://www.ebow.it
 - e-business on web!
http://www.dev2dev.it
 - La rete ha connesso nuove particelle - d2D004
I veri problemi della vita saranno sicuramente cose che non t'erano mai
passate per la mente.

 del client
Questa storia dei cookies come migliore soluzione non mi piace.
Effettivamente non ha nessuna incidenza sul server, ma riesci a prevedere
tutto quello che può seccedere lato client?
IE6 ha una gestione (finalmente!) molto completa dei cookies, io, per
esempio,
ho scelto di non far salvare i cookies ai vari siti che visito. Ho salvato
solo i cookies
di quei tre-quattro siti di cui mi interessa mantenere i dati, il resto:
blocco totale!
Ora: è chiaro che nel caso di Alan, trattandosi di una intranet, può
decidere di
imporre il passaggio dei cookies o di richiere di sbloccarli all'utente, ma
in un
sito in rete? I cookies sono la soluzione migliore (se per migliore non
parliamo
di stress del server, quanto di sicurezza della conservazione dei dati)
La mia idea rimane sempre quella della semplicità+sicurezza, cioè quando
si tratta di conservare un ID o un nome... le session (pare che i cookies
utilizzati per queste scavalchino le restrizioni di IE6, vero?) sono più
semplici e sicure.
Semplici, perchè si risparmia in codice da scrivere.
Sicure, perchè non hanno dipendenza dal PC dell'utente e dal suo browser
Ciao
Nixs

 browser
se l'alternativa sono le varibili di sessione non sono d'accordo... secondo
me si puo' utilizzare l'id della sessione per scrivere i dati in un db... ed
e' sicuraemnte la scelta migliore... e magari controllando la scadenza della
sessione per cancellare i record nella tabella...


 Sicure, perchè non hanno dipendenza dal PC dell'utente e dal suo browser
E se con la piattaforma .Net hanno dato anche la possibilità di gestire la
sessione con un Session Server o un DB per gestire anche le Web Farm
qualcosa vorrà dire, o no???
Saluti
Massimo

 sessione per cancellare i record nella tabella...
Con ASP puro posso anche essere d'accordo (a parte dover poi scrivere un
componentino per leggere e scrivere sul DB tutte le volte e che sia
performante, multi thread safe, ecc.ecc.ecc. E non è una cosa banalissima,
altrimenti se lo fai da ASP con un file include diventi vecchio). Con .Net
assolutamente no dato che questo servizio te lo fa già la piattaforma se ti
serve.
Saluti
Massimo

 che io sappia IE6 rifiuta i cookies inviati da siti esterni...
Vedi che allora non conviene usare i cookies?!
Però io non ho problemi con le variabili di sessioni, quindi significa
che IE6 fa differenza tra i cokkies generati dal sistema (sessione)
e quelli inviati dalla pagina.
Nixs

 e quelli inviati dalla pagina.
Molto banalmente non ti accetta cookie che arrivino da dominii diversi da
quelli della pagina (in caso di una pagina singola) o della pagina dove č
stato definito il frameset.
Questo per evitare che eventuali banner presenti sul sito (ed ovviamente
ospitati da un altro dominio) ti mettano dei cookie sulla macchina con lo
scopo di memorizzare dove navighi e cosa guardi.
Quindi un'applicazione ASP fatta bene va senza nessun problema, perň il
problema č che con IE6 disabilitare i Cookie del tutto č facilissimo e
quindi non č assolutamente improbabile che qualcuno piů paranoico della
media lo faccia.
Va detto che un caso del genere, per un'applicazione ASP, distrugge anche la
gestione della sessione. Anche in questo caso .Net credo permetta di ovviare
al problema usando le request (come fa anche JSP, volendo).
Saluti
Massimo


---------------------------
Tra tutte le rispone nel tread, la tua mi ha convinto + delle altre....
non avevo pensato al discorso "BANDA", sicuramente meglio usare un po' di
memoria che tirare il collo alla linea...
TNKS a tutti!

 sessione...)
Cosa intendi? Mi spiegeresti meglio?
TNKS

 Sicure, perchè non hanno dipendenza dal PC dell'utente e dal suo browser
--------------
Nico siamo sulla stessa linea.....e poi comunque sia dato che si tratta di
una intranet di pubblicazione riservata penso che sia più sicuro usare
qualche cosa lato server che lato client...al massimo qualche d'uno
scriverebbe qualche articolo a caso..  : )
TNKS

Direttamente da MSDN
http://msdn.microsoft.com/library/en-us/dnasp/html/asptips.asp
 (25+ ASP Tips
to improve performance)
----------------------------------------------
Tip 6: Using the Session Object Wisely
Now that we've espoused the virtues of caching in Applications and Sessions,
we're going to suggest avoiding the Session object. Sessions have several
pitfalls when used with busy sites, as we'll discuss. By busy, we generally
mean sites requiring hundreds of pages a second or thousands of simultaneous
users. This tip is even more important for sites that must scale
horizontally-that is, those sites that utilize multiple servers to
accommodate load or implement fault tolerance. For smaller sites, such as
intranet sites, the conveniences of Sessions are worth the overhead.
To recap, ASP automatically creates a Session for every user that hits a Web
server. Each Session has about 10 KB of memory overhead (on top of whatever
data is stored in the Session), and slows all requests down a bit. The
Session stays alive until a configurable timeout period, usually 20 minutes.
The biggest issue with Sessions is not performance but scalability. Sessions
don't span Web servers; once a Session is created on one server, its data
stays there. This means that if you use Sessions in a Web farm, you have to
devise a strategy for each user's requests to always be directed to the
server on which the user's Session exists. This is referred to as "sticking"
a user to a Web server. The term "sticky sessions" derives from this.
"Stuck" users will lose their Session state if the Web server crashes, since
Sessions are not persisted to disk.
Strategies for implementing sticky sessions include hardware and software
solutions. Solutions such as Network Load Balancing in Windows 2000 Advanced
Server and Cisco's Local Director can implement sticky sessions, at the cost
of some scalability. These solutions are not perfect. Rolling your own
software solution at this point of time is not recommended (we used to use
ISAPI filters and URL mangling and such).
The Application object doesn't span servers either; if you need to share and
update Application data across the Web farm, you'll need to use a back-end
database. Read-only Application data is still useful in Web farms, however.
Most mission-critical sites will want to deploy at least two Web servers, if
for no other reason than increasing uptime (handling failover and server
maintenance). Therefore, in designing your mission-critical application,
you'll need to either implement "sticky sessions," or simply avoid Sessions,
as well as any other state-management technique that stores user state on
individual Web servers.
If you are not using Sessions, be sure to turn them off. You can do this for
your application through the Internet Services Manager (see the ISM
documentation). If you decide to use Sessions, you can minimize their
performance impact in several ways.
You can move content that doesn't require Sessions (such as Help screens,
visitor areas, and so forth.) into a separate ASP application that has
Sessions turned off. On a page-by-page basis, you can provide a hint to ASP
that you won't need the Session object on a given page; use the following
directive placed at the top your ASP page:
<% @EnableSessionState=False %>
One good reason to use this directive is that Sessions create an interesting
problem with framesets. ASP guarantees that only one request from a Session
will be executing at any time. This insures that if a browser requests
multiple pages for one user, only one ASP request will touch the Session at
a time; this avoids multithreading problems when accessing the Session
object. Unfortunately, as a result, all pages in a frameset will be painted
in a serialized manner, one after another, rather than simultaneously. The
user may have to wait a long time for all of the frames. The moral of the
story: if certain frameset pages have no reliance on the Session, be sure to
tell ASP, using the @EnableSessionState=False directive.
As an alternative to using the Session object, there are many options for
managing Session state. For small amounts of state (less than 4 KB), we
usually recommend using Cookies, QueryString variables, and hidden-form
variables. For larger amounts of data such as shopping carts, a back-end
database is the most appropriate choice. A lot has been written about
state-management techniques in Web server farms. See the Session state
references for more details.
----------------------------------------
Un altro piccolo inconveniente delle sessioni è che comunque hanno un
timeot, che se impostato troppo alto consuma eccessive risorse. Con il
sistema cookies/DB invece il timeout viene impostato a qualunque intervallo,
solo per motivi di sicurezza ma non pregiudica le performance. Ciao


 già la piattaforma se ti serve.
no .NET dipende da cosa intendi... non tutte le cose sono performanti...


 e quelli inviati dalla pagina.
no


> sessione...)
l'ho spiegato in un altro post...
per riassumere: crei una tabella e tracci il record con l'id della
sessione... e includi i campi che ti servono... quando devi andare a pescare
i campi... fai una query con l'id della sessione... tutto qua'... cosi' non
sprechi ne *banda* ne *memoria* che puo' costare anche poco... am perche'
sprecarla a caso?... se tutti facessero cosi' i server starebbero tutti
piegati in 2... soprattuto in hosting economici dove su ogni server girano
anche 1000 domini!


 solo per motivi di sicurezza ma non pregiudica le performance. Ciao
A parte leggere la documentazione (che, per chiarezza, parla di ASP e non di
.Net) hai mai provato ad usare SQL Server per gestire lo stato???
Io sì. E sono tornato ad usare la sessione.
Saluti
Massimo


Moderatore di it.comp.www.asp - .NET MVP
http://www.aspitalia.com/
 Enjoy the .NET community!
http://www.dev2dev.it/
 La rete ha connesso nuove particelle! 

 anche 1000 domini!
Ribadisco: occhio che la licenza di SQL Server costa (e mica poco dato che
devi prendere quella "per processor" visto lo scenario) e che gestire gli
accessi in maniera concorrente nel momento in cui sul DB possono accedere
potenzialmente migliaia di utenti è tutto tranne che facile (se vuoi fare le
cose fatte bene, devi usare qualche tipo di componente scritto bene in C++ e
che giri sotto COM+, altrimenti la scalabilità ti va a rusco). Te lo dico
perchè l'ho fatto, non perchè l'ho sentito dire o letto.
Secondo me, per la mia esperienza, le variabili di sessione ci sono e vanno
usate di default e devi avere degli OTTIMI motivi per non farlo (tipo server
che debbano essere realmente geoscalabili o che, per motivi temporali,
debbano sopportare carichi elevatissimi in periodi brevi, tipo un server che
faccia vedere i risultati online di un gran premio e che quindi ha 2 ore di
carico pesantissimo possibile).
Saluti
Massimo

Attualmente è quello che sto facendo. Nei cookies ho solo una password
random e id utente (non molta banda occupata direi..) nel db ho tutte le
informazioni sulla sessione che recupero istantaneamente, data la semplicità
della query (univoca oltretutto). Poi si parla di una tabella dove sono le
sessioni "attive" non di quella di tutta l'anagrafica.
Mi sembra che funzioni egregiamente..
Se anche servizi Microsoft ad altissimo traffico, come Hotmail utilizzazano
una password random passata sulla querystring invece delle sessioni, ci sarà
un motivo?


 premio e che quindi ha 2 ore di carico pesantissimo possibile).
come dicevo prima bisogna conoscere la situazione... e valutare la soluzione
piu' adatta...


OK provo a fare la tua soluzione...mi hai convinto definitivamente...
**cookies + database (salvi nel cookies l'id dove sono i dati della
sessione...)***
Non sai dove posso trovare qualche articolo in rete o se mi indichi il tuo
vecchio post?
Comunque penso di aver capito.
Per la cronaca uso mySQL!
Grazie a tutti dei commenti! Cosě si che si impara....

Oltre all'ID nei cookies sarebbe bene salvare una password random generata
al momento del login e salvata anche questa nel DB.
LA ricerca nel DB la fai attraverso la coppia ID + RANDOM PWD
