sessione e istanze

[giuseppe500]

ciao.
Non so se è il forum giusto ,comunque provo.
1)la sessione in un sito php è comune a tutti gli utenti che sono collegati al sito(come credo) o ogni utente che si collega ha la sua?
perchè vorrei salvare dei dati relativi ad ogni utente come da domanda successiva.
2)Sto creando un web service rest con symfony 2 e vorrei memorizzare degli oggetti relativi ad ogni utente(specifici di ogni utente)per non fare tutte le volte una query, gli elementi non sono tanti ma sono richiesti tantissime volte nella mia applicazione e pensavo di usare un array in una variabile membro nella classe controller (MVC) senza caricare il db.
3)se per ogni utente si crea un istanza dell'applicazione allora magari avere una variabile membro con i dati su cui voglio creare una spece di cache puo funzionare, ogni utente ha la sua variabile, ma se non è cosi?come posso fare?
4)So che è una domanda un po campata per aria , ma quanti utenti puo' reggere un applicazione php e quali possono essere le cause di un crollo di prestazioni a seguito di un carico alto.
e cos' è che si imballa ? la banda , il db ?
insomma è un po che programmo in php ma mi sono accorto non conosco le basi(e non voglio piu farne senza).

scusate la domanda per molti di voi banale ma non so le basi di cio che accade dietro le quinte.

grazie.
ciao.

ciao.

[cavicchiandrea]

ciao.
Non so se è il forum giusto ,comunque provo.
1)la sessione in un sito php è comune a tutti gli utenti che sono collegati al sito(come credo) o ogni utente che si collega ha la sua?
perchè vorrei salvare dei dati relativi ad ogni utente come da domanda successiva.

Ogni uno ha la sua, altrimenti come faresti a distinguerli

2)Sto creando un web service rest con symfony 2 e vorrei memorizzare degli oggetti relativi ad ogni utente(specifici di ogni utente)per non fare tutte le volte una query, gli elementi non sono tanti ma sono richiesti tantissime volte nella mia applicazione e pensavo di usare un array in una variabile membro nella classe controller (MVC) senza caricare il db.

Non ho capito se è una domanda

3)se per ogni utente si crea un istanza dell'applicazione allora magari avere una variabile membro con i dati su cui voglio creare una spece di cache puo funzionare, ogni utente ha la sua variabile, ma se non è cosi?come posso fare?

Non ho capito e forse e legata a MVC che non conosco

4)So che è una domanda un po campata per aria , ma quanti utenti puo' reggere un applicazione php e quali possono essere le cause di un crollo di prestazioni a seguito di un carico alto.
e cos' è che si imballa ? la banda , il db ?

Credo sia impossibile dirlo troppe variabili

insomma è un po che programmo in php ma mi sono accorto non conosco le basi(e non voglio piu farne senza).

scusate la domanda per molti di voi banale ma non so le basi di cio che accade dietro le quinte.

A questo proposito se fossi in te prima acquisirei le conoscenze adeguate poi svilupperei visto che ci sono molte richieste da gestire (prima studio e divento medico poi curo i malati non il contrario altrimenti faccio solo danni)

[giuseppe500]

grazie per la prima risposta, solo andrea, che ho gia letto dei libri su php ma non ho mai trovato come funzionino le cose realmente , cosa che invece secondo me puo essere molto utile per capire problemi o per definire l'architettura di un applicazione

[cavicchiandrea]

Se i libri non ti "soddisfano" più lo step superiore è passare ad un corso

[Santino83_02]

2)Sto creando un web service rest con symfony 2 e vorrei memorizzare degli oggetti relativi ad ogni utente(specifici di ogni utente)per non fare tutte le volte una query, gli elementi non sono tanti ma sono richiesti tantissime volte nella mia applicazione e pensavo di usare un array in una variabile membro nella classe controller (MVC) senza caricare il db.

I webservices sono stateless, di che sessione staresti parlando? cmq la query per capire se la sessione esiste nel db (se vuoi usare una sessione, cosa abbastanza estranea ai rest) la devi fare

3)se per ogni utente si crea un istanza dell'applicazione allora magari avere una variabile membro con i dati su cui voglio creare una spece di cache puo funzionare, ogni utente ha la sua variabile, ma se non è cosi?come posso fare?

"si crea un'istanza dell'applicazione"???????? ma che è una domanda del funzionamento di apache/php ? cmq no non è così.. nulla ti vieta di usare meccanismi ci cache cmq

4)So che è una domanda un po campata per aria , ma quanti utenti puo' reggere un applicazione php e quali possono essere le cause di un crollo di prestazioni a seguito di un carico alto.
e cos' è che si imballa ? la banda , il db ?
insomma è un po che programmo in php ma mi sono accorto non conosco le basi(e non voglio piu farne senza).

ci sono tutta una serie di fattori che incidono sul carico dell'applicazione, ad esempio l'uso delle risorse (disco/database/files/etc), l'uso o meno di cache, l'uso o meno di CDN, potenza del server, condivisione delle risorse del server, come è programmata l'applicazione, com'è ottimizzato il database, etc etc etc... Per sapere con precisione a quanti utenti può rispondere la tua app dovresti fare degli stress test ( sul sito di apache ci sono dei tools per fare delle simulazioni, ad esempio)

[cronenborg]

Se può servirti ti porto la mia esperienza in merito:
tempo fa decisi di cambiare metodo di storing delle sessioni php dal default a un sistema più flessibile.
Così trovai un workaround (che incollo) per storare le sessioni in una directory del server accessibile ai miei script.
Questa soluzione mi dava alcuni vantaggi:
- occupa meno risorse di un DB
- i files di sessione creati sono accessibili agli script php

di seguito il codice php per effettuare questa operazione e poi il seguito della storia:

$cookieExpireTime = 60*60*24*7; // 7 giorni
session_set_cookie_params($cookieExpireTime,'/','.nomedominio.com');
$Lifetime = $cookieExpireTime;
$Separator = (strstr(strtoupper(substr(PHP_OS, 0, 3)), "WIN")) ? "\\" : "/";
$DirectoryPath = dirname(__FILE__) . "{$Separator}SessionData";
is_dir($DirectoryPath) or mkdir($DirectoryPath, 0755);
if (ini_get("session.use_trans_sid")==true){
    ini_set("url_rewriter.tags","");
    ini_set("session.use_trans_sid",false);
}

ini_set("session.gc_maxlifetime",$Lifetime);
ini_set("session.gc_divisor", "2");
ini_set("session.gc_probability", "1");
ini_set("session.cookie_lifetime", "0");
ini_set("session.save_path", $DirectoryPath);
define("SESSION_DATA_PATH",$DirectoryPath);
define("COOKIE_EXPIRE_TIME",$cookieExpireTime);
if (isset($_COOKIE["PHPSESSID"]))
    {
        session_id($_COOKIE["PHPSESSID"]);
    }
session_start(); 

Lo script crea una directory SessioData nello stesso percorso del file php dove si trova questo script.
E la popola dei files di sessione generati da php. Ovvero riscrive le direttive di gestione delle sessioni di php forzandone la scrittura sulla directory indicata.
Inoltre gestisce il tempo di expiring delle sessioni facendo fare a php (inteso come eseguibile) tutto il lavoro di scrittura/modifica/cancellazione dei files di sessione, così come farebbe normalmente nella sua directory di default.

Questo workaround però si rivelò efficace solo per siti medio/piccoli o comunque in cui si creasse una sessione solo per un sottoinsieme molto piccolo degli utenti totali, ovvero solo per chi fosse loggato o in qualche modo avesse effettuato delle operazioni da storare.

Infatti in siti con migliaia di utenti contemporanei, tutti loggati, il sistema si rivelò fallace! Infatti il tempo di accesso alla directory SessionData diveniva sempre più alto all'aumentare degli utenti, soprattutto se il tempo di expiring delle sessioni era impostato nell'ordine di giorni.

Quindi alla fine ritornai sui miei passi capendo che php gestisce già in maniera più che ottimale le sessioni, quindi non serviva affatto gestire in proprio tutti quei files, ma bastava semplicemente far fare tutto a lui, eventualmente installando memcached per ottenere performances migliori.

Scusate la prolissità.

[giuseppe500]

Se può servirti ti porto la mia esperienza in merito:
tempo fa decisi di cambiare metodo di storing delle sessioni php dal default a un sistema più flessibile.
Così trovai un workaround (che incollo) per storare le sessioni in una directory del server accessibile ai miei script.
Questa soluzione mi dava alcuni vantaggi:
- occupa meno risorse di un DB
- i files di sessione creati sono accessibili agli script php

di seguito il codice php per effettuare questa operazione e poi il seguito della storia:

$cookieExpireTime = 60*60*24*7; // 7 giorni
session_set_cookie_params($cookieExpireTime,'/','.nomedominio.com');
$Lifetime = $cookieExpireTime;
$Separator = (strstr(strtoupper(substr(PHP_OS, 0, 3)), "WIN")) ? "\\" : "/";
$DirectoryPath = dirname(__FILE__) . "{$Separator}SessionData";
is_dir($DirectoryPath) or mkdir($DirectoryPath, 0755);
if (ini_get("session.use_trans_sid")==true){
    ini_set("url_rewriter.tags","");
    ini_set("session.use_trans_sid",false);
}

ini_set("session.gc_maxlifetime",$Lifetime);
ini_set("session.gc_divisor", "2");
ini_set("session.gc_probability", "1");
ini_set("session.cookie_lifetime", "0");
ini_set("session.save_path", $DirectoryPath);
define("SESSION_DATA_PATH",$DirectoryPath);
define("COOKIE_EXPIRE_TIME",$cookieExpireTime);
if (isset($_COOKIE["PHPSESSID"]))
    {
        session_id($_COOKIE["PHPSESSID"]);
    }
session_start(); 

Lo script crea una directory SessioData nello stesso percorso del file php dove si trova questo script.
E la popola dei files di sessione generati da php. Ovvero riscrive le direttive di gestione delle sessioni di php forzandone la scrittura sulla directory indicata.
Inoltre gestisce il tempo di expiring delle sessioni facendo fare a php (inteso come eseguibile) tutto il lavoro di scrittura/modifica/cancellazione dei files di sessione, così come farebbe normalmente nella sua directory di default.

Questo workaround però si rivelò efficace solo per siti medio/piccoli o comunque in cui si creasse una sessione solo per un sottoinsieme molto piccolo degli utenti totali, ovvero solo per chi fosse loggato o in qualche modo avesse effettuato delle operazioni da storare.

Infatti in siti con migliaia di utenti contemporanei, tutti loggati, il sistema si rivelò fallace! Infatti il tempo di accesso alla directory SessionData diveniva sempre più alto all'aumentare degli utenti, soprattutto se il tempo di expiring delle sessioni era impostato nell'ordine di giorni.

Quindi alla fine ritornai sui miei passi capendo che php gestisce già in maniera più che ottimale le sessioni, quindi non serviva affatto gestire in proprio tutti quei files, ma bastava semplicemente far fare tutto a lui, eventualmente installando memcached per ottenere performances migliori.

Scusate la prolissità.

ti ringrazio, credo di aver capito l'antifona.

[giuseppe500]

grazie anche a
Santino83_02

[Santino83_02]

grazie anche a
Santino83_02

che onore anche col link al profilo