Je travaille actuellement sur des tests personnels et des points de repère pour comparer le flux de travail et l'efficacité entre utiliser MongoDB et MySQL avec des données d'exemple du monde réel.
Pour configurer mes données dans chaque base de données, je fais plusieurs milliers de boucles et créant des données de manière aléatoire Objets à insérer dans la base de données. P>
Cependant, j'ai des problèmes à l'aide de la classe Mongo dans PHP que je ne peux pas résoudre. Le problème est comme: p>
J'ai une boucle qui crée une nouvelle instance de Mongo et une nouvelle connexion, insère un petit tableau dans une collection, puis ferme la connexion. Cette boucle devrait exécuter 20000 fois. Cependant, il fait toujours échouer autour de la boucle de 16300nd (avec une min de 16200 et max de 16350, je dirais après quelques courses) lorsqu'il tente de créer l'instance / faire une connexion. P>
Le code La boucle est inférieure à: p> get_random_user_data () renvoie simplement un tableau associatif simple. P> L'erreur que je reçois est: p> MongoDB Support enabled
Version 1.2.0-
Directive Local Value Master Value
mongo.allow_empty_keys 0 0
mongo.allow_persistent 1 1
mongo.auto_reconnect 1 1
mongo.chunk_size 262144 262144
mongo.cmd $ $
mongo.default_host localhost localhost
mongo.default_port 27017 27017
mongo.long_as_object 0 0
mongo.native_long 0 0
mongo.no_id 0 0
mongo.utf8 1 1
3 Réponses :
Je confirme que c'est aussi le même comportement du pilote Ruby. J'ai répliqué un cas similaire avec Ruby Mongo, qui insère 20000 enregistrements en ouvrant / fermant l'instance de Mongo à chaque fois. Et il reste sur l'échec entre 14110 et 14200.
Ceci est le message d'erreur P>
require 'mongo'
def load_test
start = Time.now
puts 'starting at :' + start.to_s
20000.times do |i|
begin
puts i
doc = {"name" => "MongoDB", "type" => "database", "count" => 1,"info" => {"x" => 203, "y" => '102'}}
con = Mongo::Connection.new("localhost")
db = con['bulktest']
coll = db['test']
coll.insert(doc)
con.close
con,db,coll=nil,nil,nil
rescue Exception => e
puts e.message
puts e.backtrace.inspect
throw e
end
end
stop = Time.now
puts 'stoping at :' + stop.to_s
puts 'elapsed time is ' + (stop-start).to_s + ' seconds'
end
Votre référence n'a pas de sens. Ne gardez pas la connexion ouverte / proche. Vous devez réutiliser la connexion persistée au lieu d'ouvrir / fermer à chaque fois. Si vous ouvrez et fermez rapidement la prise, vous aurez trop de prises dans l'état chronométré qui utilise encore des descripteurs de fichier
Cela a du sens. Toute l'idée est de comparer le temps nécessaire pour ouvrir une connexion, faire quelque chose et fermer. C'est à dire. Reproduire une demande rapide des milliers de fois. Pourriez-vous expliquer cet «état d'attente chronométré» plus s'il vous plaît?
Découvrez Stackoverflow.com/questions/1803566/...
Votre système d'exploitation dispose d'un nombre limité de prises de disposition qu'il est disposé à ouvrir. Lorsque vous ouvrez une prise, puis fermez-la, le système d'exploitation ne le remet pas immédiatement dans la piscine «disponible», elle est suspendue pendant un certain temps dans «Time Wait», que NAT mentionne dans sa réponse .
Vous pouvez augmenter le nombre de sockets que votre système d'exploitation s'ouvrira, voir http://www.mongodb.org/display/docs/too+many+Open+files (chaque socket est un "fichier" ouvert).
En outre, vous utilisez une assez ancienne version du pilote, vous pouvez envisager d'envisager une mise à niveau.
Hum ... intéressant. Pourriez-vous réutiliser la connexion? Peut-être que c'est une chose pervec? Que se passe-t-il si vous essayez la même chose, disons, python? Avez-vous grepper la source de MongoDb (et / ou le pilote PHP) pour "erreur inconnue"? Et si vous dormez un peu entre les connexions?
Je ne peux pas vraiment réutiliser la connexion car c'est une chose que je veux inclure dans la référence. Au moment de ce commentaire, quelqu'un a dit qu'ils obtiennent le même problème avec leur pilote de rubis. Pas regardé la source du tout, mais je vais quand j'aurai une chance. Merci pour la réponse. :)
Oui, j'ai compris à propos de la référence, je me demandais simplement si ce sont les nombreuses connexions qui causent le problème (ce qui semble probablement donné la réponse de Rameesh)
Pourriez-vous décrire le but de votre entreprise pour cela s'il vous plaît? Vraiment intéressé d'entendre!