Hello,

Actuellement mon robot-moteur de sms envoie tout avec un bête while() suivis de fsockopen() et un petit log mysql.

Le problème c'est que je dépasse pas les 70 requêtes/minutes, ce qui est peu.

L'idée, c'est de faire un mutlithreading, vu que ce robot est executé par cron en line-mode (php5-cli)

Comble, c'est que PHP n'a pas encore voulu nous pondre un mutlithread ce ce nom ..

Phil me propose un framework en python, ca me dérange pas outre mesure, mais je viens déjà de me télécharger une lib de 5Mo, suivis d'une demande de Zope..

Pour un truc si miniature.. c'est abusé

le Java c'est exclu, j'ai pas un Xéon non plus..
Python pur, pourquoi pas.

Idée ?

Tu parlais de xml. Tu fais du XML-RPC ?
Sinon, il y a quoi dans tes requêtes ? Et dans les réponses ?

Attend qu'on résume Tu as un code qui arrive à envoyer 70 requêtes par minute linéairement et tu veux accélérer la cadence en multi-threadant ton code ? Je dirais que c'est une erreur sauf si tu veux tirer profit de plusieurs processeurs Je laisse philfr expliquer pourquoi mais grosso modo, tu va passer plus de temps à swaper entre tes threads qu'autre chose

Moi je veux lui apprendre à se passer des threads

Altar> Si tu attends la réponse à chaque requête avant d'envoyer la suivante, ça peut prendre du temps mais ton CPU ne fout rien entre la requête et la réponse. Il faut donc envoyer en parallèle plein de requêtes et traiter les réponses au fur et à mesure de leur arrivée. Ce que tu peux faire par du multithreading ou par de l'asynchrone...

Alors laisse moi te dire que tu fais du bon boulot J'ai appris à ne plus les utiliser que dans les cas où ils sont utiles et indispensable. Merci pour ça d'ailleurs

Une petite explication ?

Oui mais en multithreading tu va perdre de la puissance cpu utile à forcer de swaper entre tes threads Donc l'asynchrone c'est le bien

J'aurai au moins fait un convaincu sur le site des informaticiens belges...

Sauf que c'est pas toujours applicable dans la vie réelle, tout n'est pas disponible en asynchrone

Ce n'est qu'une question de temps ...
Ou d'effort...

philfr > Bah il n'y a pas de honte à l'admettre Tu avais raison et je te remercie de m'avoir éclairer. On ne peut pas tout faire en asynchrone (quoi que) mais dans 95% des cas, on peut s'en passer et le code n'en ressort que meilleur. Ca demande un peu d'effort mais ça devient vite une habitude

Mais au lieu de fournir des threads en PHP, ils feraient mieux de fournir des libs asynchrones pour les I/O ou XML-RPC ou httpget...

Ce qui ne va pas faire grimper PHP ou ses développeurs dans mon estime

Envoi XML via postdata, récupération du status/error/ID Opérateur.

Altar> c'est le topic sur les threads qui t'a "éclairé" ?
Je demande ça sérieusement, parce que je me bats quotidiennement au boulot pour faire passer le cap aux durs de la programmation structurée "à l'ancienne" qui ont besoin de penser séquentiel mais sont incapables de voir que plusieurs séquences en parallèle, c'est moins prédictible que plusieurs séquences...en séquence.

Alors s'il y a un argument qui t'a flashé, ou une expérience particulière, je suis preneur.

Dans 3 semaines, je fais un exposé à 50 développeurs, tout est bon à prendre

Tu ouvres un socket par requête ? Ou un socket peut servir pour plusieurs requêtes ? Dans ce cas, il y a un identifiant de la requête pour matcher les réponses ?

1 socket = 1 envoi

Exemple d'envoi:



Une réponse:

cauet > Et il est où ton problème ? Un processus mono-threadé peut avoir plusieurs sockets sauf peut-être en php mais en c/c++/python c'est tout à fait possible

exemple:

while() {
fsockopen(handle);...
mysql_query(reponse);...
}

tant que la connexion n'est pas terminée, il ne passe pas à la boucle suivante.. je vois mal le while C++ faire ça (meme si je suis totalement nul en C++)

cauet> Altar a raison. Une rapide recherche (je ne suis pas développeur PHP) me montre que le system call select() est accessible en PHP par socket_select.

Tu envoies donc toutes tes requêtes, chacune sur leur socket, puis tu fais une boucle sur socket_select pour attendre les réponses et les traiter une à une dans l'ordre de leur arrivée...