Pagina 2 di 7 primaprima 1 2 3 4 ... ultimoultimo
Visualizzazione dei risultati da 11 a 20 su 68
  1. #11
    Originariamente inviato da andr3a
    stando a quanto scritto non c'e' un minor carico di lavoro ... e se le richieste si accodano non vedo dove sia il problema .

    Poi se ho capito bene pconnect cerca la risorsa per un solo utente, ovvero se sono in multitask sul browser e faccio piu' operazioni contemporaneamente allora e solo allora ho dei vantaggi ... ma se siamo 2 utenti contemporanei a fare la stessa operazione viene creato un nuovo pconnect e i 'problemi' di limiti che ne derivano ... diciamo che dopo aver letto quanto scritto in quella pagina penso che l'ideale sia strutturare tutto in modo tale da connettersi e fare query nel minor tempo possibile o in meno righe possibili, cosi' la connessione resta occupata poco e il resto delle operazioni vengono gestite dal server.
    si riferisce, come dice bubu, agli utenti della connessione ^^

    Quindi tanto codice dove ci pare ma query e connessione, disconnessione raggruppate nel minor numero di linee possibili, questo forse e' un buon metodo ma potrei sbagliarmi ... in sqlite ho letto che con popen ad esempio bisognerebbe fare sempre le transazioni perche' passare la connessione in lettura e/o scrittura non e' molto sicuro, che sia piu' pesante per il server come per il db anche la gestione di pconnect ?
    non conosco sqlite, non so nemmeno se c'è autenticazione quindi non posso rispondere ^^
    ma per pconnect, a test e conti fatti, è meglio usarlo in generale xche

    1° E' veloce quando connect
    2° ha tutti in vantaggi di connect
    3° Se la pagina web chiude la connessione e un'altra la riapre la connessione esiste già e quindi php non si deve connettere e non deve aggiungere di nuovo la risorsa al suo elenco di risorse

    e poi tanti altri vantaggi\motivi vari e preferenziali miei personali
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  2. #12
    Originariamente inviato da bubu77
    Andrea per utenti io credo che si intenda utenti di mysql, quindi il tuo sito avra il solito utente per tutti

    aspe' ... fermi tutti ... mysql non accetta un utente alla volta, usa lo stesso user e pwd per accedere ma questo non significa che accede uno alla volta, altrimenti le connessioni simultanee e limiti massimi su queste non esisterebbero ... giusto ??? :master:


    ... e se e' cosi' ogni accesso in db crea un nuovo pconnect ... quindi e' riferito al navigante, non al navigato ... o non c'ho capito niente ???
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  3. #13
    Lo stesso link postato da Fabio, ma in italiano.

    http://it.php.net/manual/it/features...onnections.php


    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  4. #14
    Originariamente inviato da piero.mac
    Lo stesso link postato da Fabio, ma in italiano.

    http://it.php.net/manual/it/features...onnections.php

    e allora ho capito bene ... infatti:
    Questo significa che quando lo stesso client effettua una seconda richiesta al server, esso potrà essere servito da un diverso processo figlio rispetto a quello della prima volta. In questa situazione, usare una connessione persistente, permette di stabilire una e una sola connessione al database SQL per ogni processo figlio, poiché ciascun processo figlio necessita di collegarsi al database SQL solo la prima volta che richiama una pagina che ne fa uso. Quando viene richamata un'altra pagina che necessita di una connessione al server SQL, essa può riutilizzare la connessione che lo stesso processo figlio aveva stabilito in precedenza.

    ... e ancora ...
    Per esempio, se si hanno 20 diversi processi figlio che eseguono uno script che crea una connessione persistente al server SQL server, si avranno 20 diverse connessioni al server SQL, una per ogni figlio.

    per concludere con:
    Si fa notare, tuttavia, che questo può avere degli svantaggi se si fa uso di un database che ha un limite al numero di connessioni, minore rispetto al numero delle connessioni persistenti dei procesi figlio. Se per esempio di usa un database con 16 connessioni simultanee, e durante un periodo di intensa attività del web server, 17 processi figlio cercano di collegarsi, uno non sarà in grado di farlo. Se nei vostri script ci sono bug che non permettono alle connessioni di chiudersi in maniera regolare (come ad esempio un loop infinito), un database con sole 16 connessioni diventerà rapidamente saturo.

    20 utenti che non fanno una mazza ma persistono sul sito ( non chiudendo la connessione ) ... occupano 20 connessioni e se il limite e' 21 entra un solo altro utente , non di piu' ... mentre se per ogni pagina creo e chiudo la connessione, la situazione in cui simultaneamente piu' di 21 utenti accedano al database e' molto piu' improbabile ... giusto ?

    Se ho capito bene, ma ho grossi dubbi in merito , rimango fedele a _connect e _close , piuttosto che _pconnect
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  5. #15
    Vorrei anche sottolineare per chi usa esclusivamente _pconnect....

    Sommario importante. Le connessioni persistenti sono state pensate per avere una mappatura uno-a-uno con le connessioni di tipo normale. Ciò significa che si dovrebbe sempre essere in grado di cambiare una connessione persistente con una connessione non-persistente, e che questo non dovrebbe cambiare il modo in cui lo script si comporta. Può (e probabilmente succederà) cambiare l'efficienza dello script, ma non il suo comportamento!
    ed anche '"avvertimento", che vi lascio al piacere della lettura direttamente sul manuale ....


    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  6. #16
    Originariamente inviato da andr3a
    aspe' ... fermi tutti ... mysql non accetta un utente alla volta, usa lo stesso user e pwd per accedere ma questo non significa che accede uno alla volta, altrimenti le connessioni simultanee e limiti massimi su queste non esisterebbero ... giusto ??? :master:


    ... e se e' cosi' ogni accesso in db crea un nuovo pconnect ... quindi e' riferito al navigante, non al navigato ... o non c'ho capito niente ???
    :rollo: :rollo:

    antré

    non si riferisce al navigante...ma allo script
    una pconnect una connessione...punto

    se hai 3 script che usano pconnect...e questi partono tutti e 3 insieme succederà che verranno create 3 connessioni persistenti...se poi il secondo si disconnette...e poi si riconnette un'altro, quindi un'altra pagina web, allora questo utilizza la seconda connessione

    stessa cosa succederebbe con le connessioni normali
    ma tenendo conto che il limite delle connessioni persistenti, di default, e nessun sysadmin lo modifica xche neanche lo sa che esistono, è uguale al numero di connessioni globale, se puoi fare 1000 connessioni normali ne potrai fare 1000 persistenti, con il vantaggio che usando le persistenti se già c'è una connessione aperta, libera, allora verrà usata quella
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

  7. #17
    Originariamente inviato da daniele_dll
    con il vantaggio che usando le persistenti se già c'è una connessione aperta, libera, allora verrà usata quella
    e se ce n'e' una bloccata allora si bloccano tutti


    danie' ... leggi bene che secondo me non e' cosi' vantaggioso come sembra usare pconnect ... anzi, mi sembra che in piu' punti si ribadisca che non e' una dritta ... io resto della mia idea, adesso ho le idee piu' chiare e proprio per questo non usero' mai piu' pconnect



    [editato]
    Originariamente inviato da daniele_dll
    stessa cosa succederebbe con le connessioni normali
    no, proprio perche' se io non sto facendo niente non occupo una connessione ... apro , faccio, chiudo ... non e' uguale di apro , faccio e resto aperto ... occupo inutilmente una connessione senza averne alcun bisogno, sto limitando il numero totale di utenti che potrebbero, mentre cazzeggio, fare altro ... quindi non e' la stessa cosa
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  8. #18
    non so se come test e' affidabile ma ...
    codice:
    $h = 'localhost';
    $u = 'root';
    $p = '';
    $c = Array();
    for( $a = 0; $a < 10000; $a++ ) {
    	$c[$a] = &mysql_connect( $h, $u, $p ) or die( $a.' - '.mysql_error() );
    }
    for( $a = 0; $a < 10000; $a++ ) {
    	mysql_close( $c[$a] ) or die( $a.' - '.mysql_error() );
    }
    contro
    codice:
    $h = 'localhost';
    $u = 'root';
    $p = '';
    $c = Array();
    for( $a = 0; $a < 10000; $a++ ) {
    	$c[$a] = &mysql_pconnect( $h, $u, $p ) or die( $a.' - '.mysql_error() );
    }
    tempi quadruplicati per il pconnect ...

    editato
    .. perche' il pconnect crea una nuova connessione ogni volta ... un nuovo resource ... mentre connect no ... ora c'e' qualcosa che mi sfugge o sto' benedetto pconnect fa tutt altro che verificare se c'e' gia' una connessione ??? :master:
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  9. #19
    Originariamente inviato da daniele_dll
    .....
    ma tenendo conto che il limite delle connessioni persistenti, di default, e nessun sysadmin lo modifica xche neanche lo sa che esistono, è uguale al numero di connessioni globale, se puoi fare 1000 connessioni normali ne potrai fare 1000 persistenti, con il vantaggio che usando le persistenti se già c'è una connessione aperta, libera, allora verrà usata quella
    Ci pensa apache di default....
    #
    # KeepAlive: Whether or not to allow persistent connections (more than
    # one request per connection). Set to "Off" to deactivate.
    #
    KeepAlive On

    #
    # MaxKeepAliveRequests: The maximum number of requests to allow
    # during a persistent connection. Set to 0 to allow an unlimited amount.
    # We recommend you leave this number high, for maximum performance.
    #
    MaxKeepAliveRequests 100

    #
    # KeepAliveTimeout: Number of seconds to wait for the next request from the
    # same client on the same connection.
    #
    KeepAliveTimeout 15
    Nello script bisognerebbe prevedere che se non si puo' accedere a pconnect di poter usare la connessione tradizionale. Ottimizzare si, ma non penalizzare lo script per poter ottimizzare. O la cosa non avrebbe senso. Dire allo user se non riesci ora prova piu' tardi... non sa di ottimizzazione ma di pressapochismo.

    In pratica se il server non e' dedicato e per un picco di traffico le pconnect venissero configurate tutte dallo stesso user (leggi script), per gli altri ci sarebbe solo povera ciccia in attesa di un restart del server mysql.


    Il silenzio è spesso la cosa migliore. Pensa ... è gratis.

  10. #20
    Originariamente inviato da andr3a
    non so se come test e' affidabile ma ...
    codice:
    $h = 'localhost';
    $u = 'root';
    $p = '';
    $c = Array();
    for( $a = 0; $a < 10000; $a++ ) {
    	$c[$a] = &mysql_connect( $h, $u, $p ) or die( $a.' - '.mysql_error() );
    }
    for( $a = 0; $a < 10000; $a++ ) {
    	mysql_close( $c[$a] ) or die( $a.' - '.mysql_error() );
    }
    contro
    codice:
    $h = 'localhost';
    $u = 'root';
    $p = '';
    $c = Array();
    for( $a = 0; $a < 10000; $a++ ) {
    	$c[$a] = &mysql_pconnect( $h, $u, $p ) or die( $a.' - '.mysql_error() );
    }
    tempi quadruplicati per il pconnect ...

    editato
    .. perche' il pconnect crea una nuova connessione ogni volta ... un nuovo resource ... mentre connect no ... ora c'e' qualcosa che mi sfugge o sto' benedetto pconnect fa tutt altro che verificare se c'e' gia' una connessione ??? :master:
    antré...hai vagamente, da qualche parte letto quello che ho detto? come fai a fare un test di questo tipo se poco su ti ho parlato di script

    grazie...è NORMALISSIMO cosi...non c'è DUBBIO
    ma tu dovresti farlo con uno script che parte e chiude

    o usando close, se è lo stesso, ma questo non so dirlo
    The fastest Redis alternative ... cachegrand! https://github.com/danielealbano/cachegrand

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.