utenti e query

[Blacksun83]

Salve , mi serve un consiglio diretto all'efficienza.
Lavoro su un applicazione php/mysql e l'interrogativo che mi turba da parecchio è questo.

nell'applicazione ogni visitatore che entra nel sito fa ricerche ( quindi esegue query al db ) per non parlare del fatto che per motivi di sicurezza ho costruito le sessioni in modo che vengano salvate nel db (quindi altre query)...

il problema che mi sorge e che se ci sono parecchi utenti collegati ci sarà una sorta di polling verso il db che rallenterà la mia applicazione.

La domanda è
secondo voi conviene salvare il resource id di ogni connessione (quindi utente) e dove (cookie ? session ? ) ? oppure fare altro....
Il problema è che in teoria non chiudo mai una connessione perche da quel che so il collo di bottiglia si crea aprendo e chiudendo connessioni al db .

ah la connessioni vengo gestite da due classi ConnectToDB e ConfigDB , connect estende config , connect crea la connessione config ha solo i parametri ....

non so se sono riuscito ad essere chiaro ....

[alcio74]

La connessione al DB, a prescindere che tu possa usare mysql_close, viene chiusa ad ogni chiusura di script, quindi mi viene spontaneo dirti che il collo di bottiglia, comunque lo avresti (se è questa la tua preoccupazione).

Però, ricordati che i DB sono nati per sopportare una grossa mole di connessioni, quindi mi viene da dire che, salvo tu non abbia una serie di connessioni simultanee tipo facebook, forse grosse perdite di performace non le noterai nemmeno.

Non riesco a capire una cosa però: cosa intendi con

per non parlare del fatto che per motivi di sicurezza ho costruito le sessioni in modo che vengano salvate nel db

[Blacksun83]

innanzitutto grazie,

cmq l'applicazione si è tipo facebook e le sessioni di php sono gestite nel db nn ricordo come si chiama di preciso la funzione mi sa set_session_handler e poi rinomini write read etc etc

tornando al problema se creo una connessione per un utente è utile per nn avere troppe connessioni aperte mantenere il resource id?

[alcio74]

Secondo me, dovresti sfruttare le sessioni per quello che sono, e non creare degli ibridi mostruosi.
Ora ho poco tempo per risponderti perché sto uscendo.
Fai un UP che ti rispondo con comodo domani.

[Dascos]

Possibile soluzione per le sessioni...tabella in memoria!
molto più veloce di una tabella su disco, unico "svantaggio" è che se riavvii il server mysql, perdi i dati, ma essendo sessioni, quindi destinate di suo a decadimento, non c'è problema!

Riguardo ai connection id ecc, il problema si può risolvere (limitare) con le persistent connection. Il db va comunque ottimizzato sia a livello tabelle che a livello server, se la mole di query è elevata.
Riesci a mettere qui le statistiche di MySql cos' che possiamo valutare meglio?
Per intenderci...queste:

Traffico  	ø all'ora
Ricevuti 	109 GiB 	57 MiB
Spediti 	15 TiB 	7,871 MiB
Totale 	15 TiB 	7,928 MiB

Connessioni 	ø all'ora 	%
max. connessioni contemporanee 	86 	--- 	---
Tentativi falliti 	1 	0,51 m 	0,00%
Fallito 	32 k 	16,41 	0,84%
Totale 	3,840 k 	1,952,24 	100,00%


Query delle Statistiche: Dall'avvio, 342,381,098 query sono state effettuate sul server.
Totale 	ø all'ora 	ø al minuto 	ø al secondo
342 M 	174,05 k 	2,90 k 	48,35


Tipo di Query 	ø all'ora 	%
admin commands 	20 M 	10,01 k 	5,82%
assign to keycache 	0 	0,00 	0,00%
alter db 	0 	0,00 	0,00%
alter db upgrade 	0 	0,00 	0,00%
alter event 	0 	0,00 	0,00%
alter function 	0 	0,00 	0,00%
alter procedure 	0 	0,00 	0,00%
alter server 	0 	0,00 	0,00%
alter table 	32 	0,02 	0,00%
alter tablespace 	0 	0,00 	0,00%
analyze 	0 	0,00 	0,00%
backup table 	0 	0,00 	0,00%
begin 	0 	0,00 	0,00%
binlog 	0 	0,00 	0,00%
call procedure 	0 	0,00 	0,00%
change db 	23 M 	11,67 k 	6,78%
change master 	0 	0,00 	0,00%
check 	5,248 	2,67 	0,00%
checksum 	0 	0,00 	0,00%
commit 	6 	3,05 m 	0,00%
create db 	2 	1,02 m 	0,00%
create event 	0 	0,00 	0,00%
create function 	0 	0,00 	0,00%
create index 	0 	0,00 	0,00%
create procedure 	0 	0,00 	0,00%
create server 	0 	0,00 	0,00%
create table 	1,491 	0,76 	0,00%
create trigger 	0 	0,00 	0,00%
create udf 	0 	0,00 	0,00%
create user 	0 	0,00 	0,00%
create view 	0 	0,00 	0,00%
delete 	18 M 	9,079,92 	5,28%
delete multi 	0 	0,00 	0,00%
do 	0 	0,00 	0,00%
drop db 	1 	0,51 m 	0,00%
drop event 	0 	0,00 	0,00%
drop function 	0 	0,00 	0,00%
drop index 	0 	0,00 	0,00%
drop procedure 	0 	0,00 	0,00%
drop server 	0 	0,00 	0,00%
drop table 	1,491 	0,76 	0,00%
drop trigger 	0 	0,00 	0,00%
drop user 	0 	0,00 	0,00%
drop view 	0 	0,00 	0,00%
empty query 	0 	0,00 	0,00%
flush 	82 	0,04 	0,00%
grant 	0 	0,00 	0,00%
ha close 	0 	0,00 	0,00%
ha open 	0 	0,00 	0,00%
ha read 	0 	0,00 	0,00%
help 	0 	0,00 	0,00%
insert 	5,843 k 	2,970,23 	1,73%
insert select 	3,497 	1,78 	0,00%
install plugin 	0 	0,00 	0,00%
kill 	12 k 	5,85 	0,00%
load 	0 	0,00 	0,00%
load master data 	0 	0,00 	0,00%
load master table 	0 	0,00 	0,00%
lock tables 	1,737 	0,88 	0,00%
optimize 	912 	0,46 	0,00%
preload keys 	0 	0,00 	0,00%
purge 	0 	0,00 	0,00%
purge before date 	0 	0,00 	0,00%
release savepoint 	0 	0,00 	0,00%
rename table 	0 	0,00 	0,00%
rename user 	0 	0,00 	0,00%
repair 	0 	0,00 	0,00%
replace 	3,358 k 	1,707,04 	0,99%
replace select 	0 	0,00 	0,00%
reset 	0 	0,00 	0,00%
Tipo di Query 	ø all'ora 	%
restore table 	0 	0,00 	0,00%
revoke 	0 	0,00 	0,00%
revoke all 	0 	0,00 	0,00%
rollback 	0 	0,00 	0,00%
rollback to savepoint 	0 	0,00 	0,00%
savepoint 	0 	0,00 	0,00%
select 	86 M 	43,62 k 	25,35%
set option 	3,810 k 	1,936,76 	1,13%
show authors 	0 	0,00 	0,00%
show binlog events 	0 	0,00 	0,00%
show binlogs 	37 	0,02 	0,00%
show charsets 	45 	0,02 	0,00%
show collations 	45 	0,02 	0,00%
show column types 	0 	0,00 	0,00%
show contributors 	0 	0,00 	0,00%
show create db 	0 	0,00 	0,00%
show create event 	0 	0,00 	0,00%
show create func 	0 	0,00 	0,00%
show create proc 	0 	0,00 	0,00%
show create table 	53 k 	27,06 	0,02%
show create trigger 	0 	0,00 	0,00%
show databases 	153 	0,08 	0,00%
show engine logs 	0 	0,00 	0,00%
show engine mutex 	0 	0,00 	0,00%
show engine status 	0 	0,00 	0,00%
show events 	0 	0,00 	0,00%
show errors 	0 	0,00 	0,00%
show fields 	50 k 	25,35 	0,01%
show function status 	820 	0,42 	0,00%
show grants 	45 	0,02 	0,00%
show keys 	281 	0,14 	0,00%
show master status 	0 	0,00 	0,00%
show new master 	0 	0,00 	0,00%
show open tables 	0 	0,00 	0,00%
show plugins 	589 	0,30 	0,00%
show privileges 	0 	0,00 	0,00%
show procedure status 	820 	0,42 	0,00%
show processlist 	103 k 	52,60 	0,03%
show profile 	0 	0,00 	0,00%
show profiles 	0 	0,00 	0,00%
show slave hosts 	0 	0,00 	0,00%
show slave status 	0 	0,00 	0,00%
show status 	1 	0,51 m 	0,00%
show storage engines 	0 	0,00 	0,00%
show table status 	49 k 	25,04 	0,01%
show tables 	1,767 	0,90 	0,00%
show triggers 	49 k 	24,80 	0,01%
show variables 	88 	0,04 	0,00%
show warnings 	9 	4,58 m 	0,00%
slave start 	0 	0,00 	0,00%
slave stop 	0 	0,00 	0,00%
stmt close 	0 	0,00 	0,00%
stmt execute 	0 	0,00 	0,00%
stmt fetch 	0 	0,00 	0,00%
stmt prepare 	0 	0,00 	0,00%
stmt reprepare 	0 	0,00 	0,00%
stmt reset 	0 	0,00 	0,00%
stmt send long data 	0 	0,00 	0,00%
truncate 	876 	0,45 	0,00%
uninstall plugin 	0 	0,00 	0,00%
unlock tables 	1,737 	0,88 	0,00%
update 	16 M 	8,354,90 	4,85%
update multi 	496 k 	251,98 	0,15%
xa commit 	0 	0,00 	0,00%
xa end 	0 	0,00 	0,00%
xa prepare 	0 	0,00 	0,00%
xa recover 	0 	0,00 	0,00%
xa rollback 	0 	0,00 	0,00%
xa start 	0 	0,00 	0,00%

[Blacksun83]

grazie della risposta,

1. nn so come stamparti le statistiche ( forse dal db manager ?)

2. per le sessioni tempo fa leggevo un libro su php e chiaramente colsi il fatto sostanziale che è piu veloce scrivere nel db che su file inoltre nn c'e problema (nel ipotesi quasi impossibile ) di concorrenza cmq sia ho chiesto al mio host server se mi abilitavano apc (alternative php cache) ma niente.

quindi il punto è se utilizzo le connessioni persistenti può migliorare la situazione? oppure conviene salvare su file come fa normalmente ma quanto meno cambiando il path di destinazione...

per l'ottimizzazione per il momento nn c'e ne bisogno a parte che e vuoto ... ma piu o meno è fatto benino ci sono poche ridondanze...

[Dascos]

Originariamente inviato da Blacksun83
grazie della risposta,

1. nn so come stamparti le statistiche ( forse dal db manager ?)

2. per le sessioni tempo fa leggevo un libro su php e chiaramente colsi il fatto sostanziale che è piu veloce scrivere nel db che su file inoltre nn c'e problema (nel ipotesi quasi impossibile ) di concorrenza cmq sia ho chiesto al mio host server se mi abilitavano apc (alternative php cache) ma niente.

quindi il punto è se utilizzo le connessioni persistenti può migliorare la situazione? oppure conviene salvare su file come fa normalmente ma quanto meno cambiando il path di destinazione...

per l'ottimizzazione per il momento nn c'e ne bisogno a parte che e vuoto ... ma piu o meno è fatto benino ci sono poche ridondanze...

Se hai i permessi e ovviamente stai usando phpmyadmin, lo si fa da "Stato".
Riguardo le sessioni, apc e simili servono solo per il caching opcode php, non c'entrano nulla con le sessioni savlate sul db...per meglio dire...dipende da cosa intendi tu per sessioni.
Sessioni php per "tracciare" i dati o sessioni db per "tracciare" un utente.
Tu quali intendi?

[Blacksun83]

Originariamente inviato da Dascos
Se hai i permessi e ovviamente stai usando phpmyadmin, lo si fa da "Stato".
Riguardo le sessioni, apc e simili servono solo per il caching opcode php, non c'entrano nulla con le sessioni savlate sul db...per meglio dire...dipende da cosa intendi tu per sessioni.
Sessioni php per "tracciare" i dati o sessioni db per "tracciare" un utente.
Tu quali intendi?

ciao

per me le sessioni sono utente con dati non ho capito la differenza che tu dici,
io eseguo query per recuperare dati e per passarli da pagina a pagina utilizzo le sessioni ...
cmq sia con si possono memorizzare dati in sessione anche con apc credimi non è il massimo in sicurezza ma penso che sia molto efficiente ...tra l'altro si parla che questo modulo sarà integrato con la versione di php 6 ...