architekturfrage

[keppla]

Hallo Forum!

Ich bin gerade dabei, eine Art "serviceorienterte Architektur" auf einem Linuxsystem zu planen.
Dazu würde ich für verschiedene Aufgaben "Services" auf dem Server laufen lassen, an die Anfragen gestellt werden bzw die sich gegenseitig Anfragen stellen.
Leider wird das ganze keine reine Pythonumgebung sein, sondern es müsste sich in ein bestehendes System aus php/apache/mysql einfügen.
Anfragen könnten aus cronjobs, httprequests über den Apachen, Php-scripts, etc gestartet werden.

Ich bräuchte also eine Möglichkeit zur Prozesskommunikation (mal abstrakt gesprochen), die einerseits kompatibel ist (zu php und perl), andererseits einigermaßen effizient.
Netzwerkfähigkeit brauche ich gar keine, kommunikation von aussen wird in form von Httprequests an PHP-scripte kommen.

kann mir da jemand etwas empfehlen? oder ist das ganze an sich schon zu bescheuert, um empfehlungen auszusprechen?

[BlackJack]

XML-RPC oder JSON-RPC dürften alle beteiligten "Parteien" anbieten/verarbeiten können würde ich sagen.

[keppla]

XML-RPC oder JSON-RPC dürften alle beteiligten "Parteien" anbieten/verarbeiten können würde ich sagen.

danke für die antwort!

die ewig blöde frage nach der performance zuerst
hast du erfahrung mit sowas, was geschwindigkeiten angeht? ich denke da insbesondere an eine situation, das innerhalb einer iteration eine "remote procedure" x-mal aufgerufen wird, und jedesmal hin und her-geparsed werden muss. kann man das vernachlässigen? (würde mich sehr freuen) oder lässt sich soetwas praktisch vielleicht immer umgehen?

nun die frage nach dem medium:
da ich ja keine netzwerkfunktionalität brauche, gibt es da schnellere kommunikationswege? oder ist die "abkürzung", die das OS macht, wenn ich über 'localhost' gehe, schon hinreichend gut?

[gerold]

performance

Hi keppla!

Lass dir nichts einreden. Auch wenn XMLRPC oder JSONRPC nicht die Schnellsten sind. Für deine Zwecke sind sie sicher schnell genug. Du willst ja sicher nicht tausende Anfragen in wenigen Sekunden durchlaufen lassen, oder?

mfg
Gerold

[keppla]

Lass dir nichts einreden.

das schlimme ist, der einwang kam von mir. die c-freaks scheinen mich gut konditioniert zu haben

Auch wenn XMLRPC oder JSONRPC nicht die Schnellsten sind. Für deine Zwecke sind sie sicher schnell genug. Du willst ja sicher nicht tausende Anfragen in wenigen Sekunden durchlaufen lassen, oder?

Schwer zu sagen. Das ding hat ein Webinterface, was einer überschaubaren Anzahl (<500) Benutzern zur Verfügung steht. Eine einzelne Anfrage wird sicher keine 1000 Anfragen verursachen, aber alle zusammengenommen...
wie gesagt: ich habe da leider keine Erfahrung.
Einerseits denke ich mir ja, langsamer als dieses dämliche PHP-geparse bei jedem seitenaufruf wirds schon nicht sein, andererseits wäre es extrem übel, wenn ich das ganze dann fertig habe, und es für die Mülltonne produziert wäre, weil es nicht skaliert (oh man, ich klinge wie ein schlipsträger).

[gerold]

Schwer zu sagen. Das ding hat ein Webinterface, was einer überschaubaren Anzahl (<500) Benutzern zur Verfügung steht. Eine einzelne Anfrage wird sicher keine 1000 Anfragen verursachen, aber alle zusammengenommen...
wie gesagt: ich habe da leider keine Erfahrung.

Hi keppla!

Du sagst es --> "Du hast keine Erfahrung damit!" Wir können es auch nicht wissen. Du weißt es erst dann, wenn es so weit ist und du dein Programm testen kannst.

Wenn du beim Programmieren von Anfang an hauptsächlich auf Performance achtest, dann wird dich das sehr viel Zeit kosten.

Wenn du zuerst darauf achtest, dass dein Programm funktioniert, dann kostet dich das viel weniger Zeit.

Wenn du später drauf kommst, dass es auch ohne Optimierungen funktioniert, dann sparst du dir die ganze Optimiererei und damit viel Zeit. Wenn du später drauf kommst, dass das Programm zu langsam ist, dann hast du ein fertiges Programm, das du mit einem Profiler durchlaufen lassen kannst. So findest du in wenigen Minuten heraus, wo am meisten Zeit verbraten wird und kannst dort mit der Optimierung anfangen. Dann wieder ein Test, dann wieder profilen, dann wieder optimieren, bis es passt. Auch dann wenn du viel optimieren musst, bis die Geschwindigkeit passt, hast du immer noch weniger Zeit verbraten, als wenn du von Anfang an auf Optimierung geachtet hast. Denn dann hättest du alles Optimiert und nicht nur das was nötig ist.

Es geht ja noch weiter. Die Einbindung von XMLRPC ist so einfach, dass du damit kaum Zeit vergeudest. Auch wenn (obwohl ich es nicht glaube) du später statt XMLRPC etwas anderes implementieren willst, dann hat dich der Ausflug über XMLRPC kaum Zeit gekostet. Das ist ja nicht so, dass du das groß programmieren musst, wie es bei der LowLevel-Socketprogrammierung so der Fall wäre. XMLRPC bindest du ein, gibst die Funktionen bekannt, die aufgerufen werden können und fertig.

lg
Gerold

[gerold]

Nachtrag:

http://www.python-forum.de/topic-5478.html

lg
Gerold

[keppla]

Du sagst es --> "Du hast keine Erfahrung damit!" Wir können es auch nicht wissen. Du weißt es erst dann, wenn es so weit ist und du dein Programm testen kannst.

Es könnte ja sein, das jemand schonmal was ähnliches gemacht hat und sagen kann "ja, geht"

[first make it work, then make it quick]

Dem stimme ich zu, und ich hatte auch sicher nicht vor, in performanceparanoiamanier "mächtige einzeiler" zu schreiben, damit es ach so schnell wird. Ich habe halt nur die Befürchtung, dass ich irgendwann feststellen könnte, das alles optimieren nicht helfen könnte, deshalb die Fragerei.

Ich glaube, ich mache mich mal an ein paar (überflüssige) Benchmarks, um meine paranoia zu besiegen.

[Leonidas]

Für deine Paranoia werfe ich noch CORBA und Ice rein, die beide auch von anderen Porgrammiersprachen als Python unterstützt werden.