2013-05-15 22 views
5

Il mio team di sviluppo ha difficoltà ad accedere a un database MongoDB remoto dai loro ambienti di sviluppo locali.Timeout dati intestazione MongoDB PHP

Il server di sviluppo remoto di Ubuntu esegue la versione più recente di MongoDB e PHP 5.3 con il v1.3.7 mongo-php-driver costruito per PHP 5.3. mongodb.conf è quasi vuoto tranne per l'impostazione di base del percorso. Al momento non ci sono frammenti o set di repliche.

Tutti i membri del team utilizzano OSX 10.8, PHP 5.3 e hanno il driver mongo-php-v1.3.7 creato per PHP 5.3. Alcuni membri del team usano XAMPP, altri utilizzano lo stack AMP AMP incorporato. Testiamo su tutti i principali browser desktop.

Ogni volta che una pagina deve prendere i dati da Mongo, iniziamo chiamando questa funzione di collegamento:

public static function connect($server, $db) 
{ 
    $connection = new MongoClient(
     "mongodb://{$server}:27017", 
     array(
      "connectTimeoutMS" => 20000, 
      "socketTimeoutMS" => 20000 
     ) 
    ); 

    return $connection->$db; 
} 

Tuttavia, quasi il 30% del caricamento della pagina stanno vivendo il seguente errore:

Failed to connect to: www.development-server.com:27017: send_package: error reading from socket: Timed out waiting for header data

Sembra che una grande parte di questi errori si verifichi quando si aggiorna una pagina, piuttosto che navigare in una nuova pagina, ma è più una supposizione che un fatto. Ho controllato il file php.ini di tutti e ho confermato che è impostato default_socket_timeout = 60.

Il server di sviluppo ospita anche una copia del sito, ma non ha mai generato l'errore, presumibilmente dal momento che sta chiamando localhost solo per arrivarci. Quando ho installato MongoDB localmente, anche gli errori sono andati via.

Questo sembra essere un problema di timeout, ma non riesco a trovare ulteriori impostazioni, parametri o configurazioni per regolare il periodo di scadenza. Ci sono?

+0

E 'possibile verificare, durante tali problemi, la connessione accettata dal processo mongod. Puoi controllare questo nei registri mongo. Il log sarà simile a: "Gio 16 Maggio 06:31:47 [initandlisten] connessione accettata da 127.0.0.1:49621 # 35 (2 connessioni ora aperte)" Allo stesso modo si otterrà una linea di registro se la connessione si sta chiudendo.Voglio controllare se la connessione è onorata da mongoDB o non raggiunge quella casella. –

+0

Lo vedo nei log; quando inizialmente carico una pagina per la prima volta vedo la connessione 'Mer 15 maggio 21: 59: 25.001 [initandlisten] connessione accettata da ip_address: 50238 # 411 (20 connessioni ora aperte)' quindi tutti i successivi caricamenti di pagina non effettuano alcuna registrazione e le pagine si caricano bene. Ad un certo punto casuale la pagina non riesce a caricare e vedo 'Mer 15 maggio 21: 59: 44.914 [conn401] end connection ip_address: 49819 (19 connessioni ora aperte)'. Alcune volte vedo una seconda connessione accettare senza una connessione di fine, il caricamento della pagina seguente fallirà e mostrerà la connessione finale. – andvari101

risposta

0

provare collegare senza il porto di connessione o impostare

array( "connectTimeoutMS" => -1, "socketTimeoutMS" => -1 )

(timeout infinito)

+0

L'impostazione dei timeout su infinito (o anche molto molto grande) sembra funzionare, ma le richieste richiederanno un minuto o più. – andvari101

1

La risposta da @hernan_arg mi ha fatto pensare a un'altra possibilità. Invece di fare affidamento sul tentativo di connessione one-and-only per avere successo (che sembra durare per sempre), è accettabile attaccare la connessione in un ciclo fino a quando non riesce?

public static function connect($server, $db) 
{ 
    $connection = null; 

    try { 
     $connection = new MongoClient("mongodb://{$server}"); 
    } catch (MongoConnectionException $e) { 
     return self::connect(); 
     exit; 
    } 

    return $connection->$db; 
} 

registrazione indica che quando la connessione non riescono, non riesce rapidamente e il loop stabilirà una nuova connessione in maniera molto più puntuale rispetto al timeout infinito fa. Supponendo che il database diventi irraggiungibile presumo di poter fare affidamento sul timeout dell'esecuzione PHP per terminare il processo.

0

La versione 1.4.1 del driver risolve alcuni problemi di stabilità su reti instabili.

Supponendo che si stia parlando con un replicaset, il driver scarterà i server che sono irragionevolmente lenti - piuttosto che ritentare di connettersi a loro il driver lo inserirà nella lista nera per alcuni secondi senza generare queste eccezioni alla connessione (supponendo che possiamo connettersi ad almeno un server)