Discussion :

[phicarre]

J'aurais besoin de conseils de spécialistes.
J'estime le nombre de requêtes Insert dans une base de données mysql à 1000 par secondes (j'ai compté large). Cela suffit-il pour mettre à genoux mysql sans prendre en compte les performances de la machine ?
Y a t'il des astuces pour éviter un goulet d'étranglement ?
J'ai trouvé la notion d'insert delayed et de la queue de taille delayed_queue_size, est-ce la bonne solution ? y en a t'il d'autres plus performantes ?
Merci

[jota5450]

slt...

1000 insert par secondes

ca fais 3 600 000 par heure ...

t´es sur de tes valeurs ?

parce que 1000 insert par secondes... soit1000 connections par secondes ..

[phicarre]

Ce sont des machines (au sens industriel du terme) qui enverraient des trames UDP vers un serveur qui les stockeraient dans une base de données. J'ai compté large ...

[rberthou]

parce que 1000 insert par secondes... soit 1000 connections par secondes

Non pour moi même 3 600 000 inserts cela peut très bien être 1 seule connexion, cela dépend de la manière dont on réalise le traitement.

C'est à mon avis ton traitement (et ta modélisation bien sur) que tu dois optimiser pour que cela passe sans trop de problèmes.

[jota5450]

slt...

wi ... d´accord.. on peut faire 1000 insert avec une seule connection... je voulais juste dire, que 1000 insert par seconde, me parrait enorme..

[rberthou]

Cela est important et en cas de problème de conception cela deviens très rapidement inexploitable.

Personnellement j'ai des traitements qui réalisent 150 000 inserts (et 150 000 lectures) en 2 minutes sans que cela pose problème.

Par contre vérifier quel est la taille max de la table de destination car cela peut poser problème je crois (si elle ne fait que grossir sans être nettoyer régulièrement).

[phicarre]

Tout ça ne m'aide pas tellement ...
Cela me rassure mais ne m'aide pas !

Les machines enverront leur message (moins de 100 octets) sous protocole UDP. Le script de réception écoute à l'infini après avoir créer un socket (stream_socket_server). Jusque là, je pense que PHP peut supporter ?

Après je pensais créer un thread pour chaque source (stream_socket_recvfrom donnant la source).
En TCP c'est plus facile mais en UDP ? Je n'ai pas un socket par source ?

Chaque thread ferait des "insert delayed" ou, pour autant que cela soit plus rapide, écrirait dans un fichier et ferait après N insertion un "load data file" dans une table.

Mes connaissances en PHP étant limitées, c'est pour cela que j'ai soumis cette question ...
Notez qu'un modérateur a déplacé mon message ICI ...

[Sivrît]

1000 c'est somme toute assez peu. Sur ma machine de développement qui tend à swapper j'arrive à des débits de 4400 insertions par secondes soutenus sur plusieurs secondes. Sachant que c'est du InnoDb moyennement dans l'ordre des clefs primaires et bien indexé (ce qui dans ce cas est contre productif), même si mes enregistrements sont petits c'est encouragent.

Le mieux serait encore de faire une maquette. Un script dans n'importe quel langage qui enregistre en base avec plus ou moins de threads des paquets bidons créés à la volée.

[rberthou]

Les machines enverront leur message (moins de 100 octets) sous protocole UDP. Le script de réception écoute à l'infini après avoir créer un socket (stream_socket_server). Jusque là, je pense que PHP peut supporter ?

Perso, je n'ai jamais essayé de faire cela (écouter UDP) en PHP donc la je ne répondrais pas.

Pourquoi ne pas passer plutôt par un programme résident en C/C++, tu n'auras pas de problème pour UDP et dans tous les cas de meilleures performances.

[FrontLine]

Quant on ne connait pas ou trop peu le C/C++, le socket en PHP reste une solution correcte en terme de perf dans le cas où la tache n'est pas gourmande.

Par contre se connecter à Mysql et envoyer des INSERT en boucle, je la tenterais pas trop.
Stocker les INSERT dans un fichier.txt que tu executes à intervalle régulier (1 fois par seconde par exemple) serait peut être une meilleure solution (j'ai jamais testé l'édition de fichier.txt dans un socket).

FrontLine

[phicarre]

Je ne peux pas utiliser C/C++ car toute mon application est faite en PHP. Par la suite je louerais un serveur virtuel chez mon hébergeur qui sera limité à PHP mais avec plus de liberté qu'un serveur mutualisé.
Merci pour ces premières réponses. Si vous avez d'autres conseils ...