Sujet: solution threading
16/11/2006 @ 22:21:27: cauet: solution threading
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 .. :kiki:

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é :sad:

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

Idée ? :smile:
16/11/2006 @ 22:26:53: philfr: solution threading
Tu parlais de xml. Tu fais du XML-RPC ?
Sinon, il y a quoi dans tes requêtes ? Et dans les réponses ?
16/11/2006 @ 22:28:08: Altar: solution threading
Attend qu'on résume :itm: 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 :wink: Je laisse philfr expliquer pourquoi mais grosso modo, tu va passer plus de temps à swaper entre tes threads qu'autre chose :itm:
16/11/2006 @ 22:28:40: philfr: solution threading
Moi je veux lui apprendre à se passer des threads :oh:
16/11/2006 @ 22:30:53: philfr: solution threading
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...
16/11/2006 @ 22:31:21: Altar: solution threading
Alors laisse moi te dire que tu fais du bon boulot :wink: J'ai appris à ne plus les utiliser que dans les cas où ils sont utiles et indispensable. Merci pour ça d'ailleurs :oh:
16/11/2006 @ 22:32:07: philfr: solution threading
Une petite explication ?
:write:
16/11/2006 @ 22:32:17: Altar: solution threading
Oui mais en multithreading tu va perdre de la puissance cpu utile à forcer de swaper entre tes threads :wink: Donc l'asynchrone c'est le bien :oh:
16/11/2006 @ 22:37:15: philfr: solution threading
Oui mais en multithreading tu va perdre de la puissance cpu utile à forcer de swaper entre tes threads :wink: Donc l'asynchrone c'est le bien :oh:


J'aurai au moins fait un convaincu sur le site des informaticiens belges... :wink:
16/11/2006 @ 22:38:19: zion: solution threading
Sauf que c'est pas toujours applicable dans la vie réelle, tout n'est pas disponible en asynchrone :petrus:
16/11/2006 @ 22:40:23: philfr: solution threading
Ce n'est qu'une question de temps :oh: ...
Ou d'effort...
16/11/2006 @ 22:40:35: Altar: solution threading
philfr > Bah il n'y a pas de honte à l'admettre :smile: 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 :wink:
16/11/2006 @ 22:42:45: philfr: solution threading
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 :kiki:
16/11/2006 @ 22:49:19: cauet: solution threading
Tu parlais de xml. Tu fais du XML-RPC ?
Sinon, il y a quoi dans tes requêtes ? Et dans les réponses ?


Envoi XML via postdata, récupération du status/error/ID Opérateur.
16/11/2006 @ 22:49:29: philfr: solution threading
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 :grin:
16/11/2006 @ 22:51:55: philfr: solution threading


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


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 ?
16/11/2006 @ 22:55:01: cauet: solution threading

1 socket = 1 envoi :spamafote:

Exemple d'envoi:


<?xml version="1.0" encoding="UTF-8" ?>
<sms>
<login>login</login>
<password>password</password>
<mt>
<msgid>456212879787</msgid>
<contenttype>text</contenttype>
<udh>65283582787687687263</udh>
<content>Perdu pour cette fois</content>
<number>sfr6107129877895462231231</number>
<shortcode>61071</shortcode>
<mcc>208</mcc>
<mnc>01</mnc>
<lastmt>0/1</lastmt>
<wappush>0/1</wappush>
<waptitle>Ringtone</waptitle>
</mt>
</sms>


Une réponse:


<return>
<status>0</status>
<msgid>SMS-MT unique identifier if status = 0 else empty</error>
<error>Description de l’erreur si status = 1</error>
</return>
16/11/2006 @ 22:58:23: Altar: solution threading
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 :ddr555:
16/11/2006 @ 23:03:31: cauet: solution threading
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++)
16/11/2006 @ 23:04:40: philfr: solution threading
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...
Retour