Richtige Programmiersprache für folgende Anwendung gesucht

[shoa66]

Hey zusammen,

hab da eine kleine Frage an Personen, die schon sehr viel mit verschiedenen Programmiersprachen gearbeitet haben und einen großen Überblick über die Performance der jeweiligen Operationen im Vergleich haben (ich hoffe da findet sich wer).

Es geht um folgende Anwendung, bei der wirklich jede ms an Durchlaufzeit/Performance zählt:

1. Daten werden per GET Befehl von einer Website geholt
2. Daten werden geparst
3. Strings werden (in einem Array) verglichen
4. Ein POST Request wird zurück an die Website gesendet

Bei Punkt 1. bis Punkt 3. sollten sich die meisten Sprachen vermutlich nicht viel nehmen, auch wenn da auch schon jede ms zählt, aber gerade bei Punkt 4 erwarte ich ein paar Unterschiede.

Ich bedanke mich im Voraus für jegliche qualifizierte Hilfe

 

[HominiLupus]

1 und 4 sind rein vom Netzwerk bestimmt und die Programmiersprache hat keinerlei Auswirkungen.
2 und 3 können langsam sein je nach dem wieviele MB,GB,TB bearbeitet werden müssen.

 

[DaZpoon]

Auf jeden Fall würde ich für soetwas auf eine Skriptsprache setzen, denn wenn sich auf der WebSeite mal was kleines ändern sollte muss man nicht erst umständlich das gesamte Programm neu übersetzen.

Aus meiner Erfahrung eignet sich Python prima für soetwas, es gibt auch sehr gute Module für HTTP Requests. Aufgrund der Übersetzung in Binärcode bleibt Python auch halbwegs schnell (bzgl. deiner Array-Operationen).

 

[X23^Piracy]

Hi,

das ist ein Fall für: http://de.wikipedia.org/wiki/JavaScript_Object_Notation

Gruß

 

[HominiLupus]

das ist ein Fall für: http://de.wikipedia.org/wiki/JavaScript_Object_Notation

Das ist es natürlich nicht. Er bekommt die Daten von einer Webseite und muss sie nehmen wie sie sind. Vielleicht sind sie in JSON Format aber eher nicht. Dann muss er ein POST machen, wieder rein im Format welches die Webseite verlangt. Er kann also nur JSON nutzen wenn die Webseite es sowieso benutzt.
Und für seine eigene Bearbeitung ist JSON natürlich total ungeeignet weil es ein Serialisierungsformat zum Transport ist.

 

[OpamitKruecke]

Würde dafür persönlich PHP einsetzen und fürs parsen der Daten sowas wie Perl,tcl oder C++.

 

[shoa66]

Hatte ich vergessen zu erwähnen, die Daten kommen tatsächlich in JSON Paketen an.

 

[Daaron]

WIE eilig hast du's denn wirklich?
Wie schon gesagt, 1 & 4 sind überall gleich, weil hier das Netzwerk limitiert, sonst nichts. Ob das initialisieren der Requests bei PHP 0.002ms länger dauert als bei C, ändert gar nichts, wenn der Request selbst 30ms läuft.

Wenn du es wirklich brutal eilig hast, dann nimm C. Nichts ist schneller. Wenn du es nicht ganz so eilig hast, dann könntest du auf Java setzen. Am Ende tut es aber auch PHP mit aktivem OpCode-Cache. Oder du verwendest PHP hinter ner HipHop Virtual Machine. HpHpVM ist bis zu 6x so schnell wie pures PHP und nicht nennenswert langsamer als C.

Wie viele TByte an Daten willst du hier schaufeln, wie komplex sind deine Operationen? Wie viel Anteil an jedem Durchlauf haben die Schritte 2&3 tatsächlich? Deine Requests in 1&4 werden z.B. ausschließlich von der Signallaufzeit des Netzes sowie der Geschwindigkeit der Webseite abhängen (also sinngemäß von der Time to First Byte). TtFB ist selbst auf flinken Servern mit flinker Implementierung und nem guten Netzwerkanschluss oftmals irgendwo bei 30-50ms, schließlich muss bei deinem GET-Request der Server ja sicherlich noch mit seiner Datenbank reden, er muss die Query Results verarbeiten,.... und bei deinem POST muss er deine Daten verifizieren und einen Schreib-Query an die DB feuern, nebst Aktualisierung des Index.
Wenn also am Ende je 50ms in Schritt 1&4 anstehen, wie viel macht es da tatsächlich aus, wenn du in Schritt 2&3 durch eine hochgradig optimierte Sprache je 1-2ms einsparst?

 

[HominiLupus]

Wenn du es wirklich brutal eilig hast, dann nimm C. Nichts ist schneller.

Ahem! x86 (oder welche CPU ISA auch immer) Assembler

 

[ice-breaker]

Du wirst nur selten besseren Assembler-Code schreiben als ein guter C-Compiler produziert.

 

[Daaron]

Na ja, theoretisch hat er ja Recht. Reiner Maschinencode ist unschlagbar, wenn er optimal geschrieben ist.... aber den Scheiß kann dann auch keiner mehr lesen, geschweige denn bearbeiten.

Ich will mal sehen, wie du einen JSON-Parser in ASM schreibst. Das wäre doch mal spaßig. Für C gibts wenigstens JSON-Libs, PHP kann JSON sowieso,...

 

[shoa66]

WIE eilig hast du's denn wirklich?
Wie schon gesagt, 1 & 4 sind überall gleich, weil hier das Netzwerk limitiert, sonst nichts. Ob das initialisieren der Requests bei PHP 0.002ms länger dauert als bei C, ändert gar nichts, wenn der Request selbst 30ms läuft.

Sehr eilig, da wirklich jede noch so kleine Einsparung zählt. Die Netzwerkseite ist schon optimiert (Server im selben RZ wie die Website bzw. das CDN, Latenz bei <1 ms).

Wenn du es wirklich brutal eilig hast, dann nimm C. Nichts ist schneller. Wenn du es nicht ganz so eilig hast, dann könntest du auf Java setzen. Am Ende tut es aber auch PHP mit aktivem OpCode-Cache. Oder du verwendest PHP hinter ner HipHop Virtual Machine. HpHpVM ist bis zu 6x so schnell wie pures PHP und nicht nennenswert langsamer als C.

Hatte mal recherchiert und gesehen, dass es da einige optimierte C Compiler gibt, die sehr auf Geschwindigkeit getrimmt wurden. Kannst du da evtl. einen konkreten empfehlen?

Wie viele TByte an Daten willst du hier schaufeln, wie komplex sind deine Operationen? Wie viel Anteil an jedem Durchlauf haben die Schritte 2&3 tatsächlich?

~55kB pro 0,4 Sekunden und pro Thread (insgesamt 4 Threads parallel).

Wenn also am Ende je 50ms in Schritt 1&4 anstehen, wie viel macht es da tatsächlich aus, wenn du in Schritt 2&3 durch eine hochgradig optimierte Sprache je 1-2ms einsparst?

Schon klar, aber es geht darum andere Clients bzw. Programme mit selbiger Funktionalität zu schlagen und irgendwo muss man sich ja differenzieren. Ein guter Server ist natürlich Pflicht und auch schon vorhanden (siehe oben).

Daher hatte ich gehofft, dass man beim POST Request evtl. auch noch etwas optimieren könnte (je nach Sprache).

 

[carom]

Sehr eilig, da wirklich jede noch so kleine Einsparung zählt.

Na dann kommst du um C/++ oder vergleichbar nicht drumherum, aber das...

~55kB pro 0,4 Sekunden und pro Thread (insgesamt 4 Threads parallel).

... passt nicht ganz mit dieser hier Anforderung zusammen, denn das bekommst du auch mit anderen Hochsprachen hin. Sind diese Anforderungen fix oder kommt da noch mehr mit der Zeit? Nebenbei gesagt habe ich nichts gegen PHP, aber sobald das Wort Threading fällt, würde ich eher von PHP absehen.

 

[Daaron]

http://php.net/manual/de/book.pthreads.php

 

[captmcneil]

Du wirst nur selten besseren Assembler-Code schreiben als ein guter C-Compiler produziert.

Das selbe trifft auch auf C++ zu. Die wenigsten Entwickler werden, ohne aktiv zu optimieren, in C++ messbar schnelleren Code schreiben als zB in Java. Man kann es tun, aber nicht ohne Trade-Off (aka Code wird unwartbarer/fehleranfälliger).

Ich bin immer ein strikter Gegner, eine Sprache/Technologie nur aus Performancegründen zu verwenden, wenn man sich nicht sicher ist, diese Performance auch wirklich zu brauchen.

Insbesondere im Web, wo es erstmal ganz andere Flaschenhälse gibt, bevor ich überhaupt anfange, über die Anwendungsperformance nachzudenken:
- Serverantwort-Zeit/Ping
- Leitungskapazität
- IO-Performance von dem ganzen Webserver etc. drumrum
- HTTP per se ist Klartext, daher relativ groß, daher schonmal grundlegend ineffizienter als Dein Programm auf dem Server
- mit HTTPS muss Deine CPU noch mehr tun
- JSON-Daten sind auch größer als ein Binärformat, dazu muss man sich dann noch überlegen ob sich ein GZIP lohnt

... usw. Also wenn zB die Datenmenge zu groß ist, sind die Limitierungen der Protokolle/Austauschformate vermutlich eher Dein Problem, bzw. Deine Lösung. Such Dir also lieber eine Technologie, die Dich solche Dinge einfach implementieren/austauschen lässt.

tl;dr: Im Web wird zu 90% Dein Performance-Problem nicht die Server-Programmiersprache sein.

 

[ice-breaker]

Das selbe trifft auch auf C++ zu. Die wenigsten Entwickler werden, ohne aktiv zu optimieren, in C++ messbar schnelleren Code schreiben als zB in Java. Man kann es tun, aber nicht ohne Trade-Off (aka Code wird unwartbarer/fehleranfälliger).

Das stimmt schon, aber der Vergleich ist doch schon sehr extrem. C++ hat es da eben von Natur aus einfacher, da nicht alles geprüft wird (z.B. ArrayIndexOfBound) und nicht mittendrin mal der GC seinen Rappel bekommt und nen vollen Durchlauf machen muss.
Java findet ja sogar im High Performance Trading Einsatz, also machbar ist es auf jedenfall damit sehr schnelle Software zu erstellen, es ist eben immer nur eine Sache wie gut die Entwickler und die angedachte Architektur ist, die Sprache ist nachher zweitrangig.

Aber ich gebe dir da schon Recht, die Performance wird seltenst das Problem und hier sicherlich auch nicht.

Vermutlich wird hier das Problem fernab der Performance eher die Zuverlässigkeit der Software, darf nie ausfallen usw. Da wäre mal ein Blick auf Erlang sehr angebracht, es gibt kaum besseres, wenn man wirklich Software bauen will, die auch die gröbsten Programmierfehler überlebt und es gibt auf Grund des Actor-Modells keine Threading-Fehler, das ist schonmal ein großerer Plus-Punkt, so nen Threading-Fehler durch eine fehlerhafte Synchronisierung ist schnell eingebaut und tritt dann nur alle 2 Wochen auf und ist dementsprechend schwer zu lokalisieren.

 

[carom]

http://php.net/manual/de/book.pthreads.php

Vorweg: Um nicht jemanden auf den Schlips zu treten, wiederhole ich mich gerne nochmal - PHP ist super.

... aber nicht in diesem Kontext.

Die Threading-Features aus pthreads sind rudimentär, aber darüber kann ich hinwegsehen. Es ist jedoch kein Jahr her, da wurde auf der Projektseite noch zur Vorsicht geraten, es war explizit von "Experiment" die Rede (nicht experimentell, sondern wirklich Experiment), von Limitierungen und von subject to change. Und zumindest damals war wenig transparent, was an PHP überhaupt threadsafe ist und was nicht (und damit meine ich nicht Datenstrukturen o.ä., sondern die Runtime selbst). Des Weiteren sind multithreaded Anwendungen so schon schwer genug zu Debuggen - die Natur einer Skriptsprache macht das eher noch komplizierter.

Es gibt Technologien, die in diesem Bereich schon ein, zwei Jahrzehnte oder mehr an Reife besitzen und im Gegensatz zu PHP Threading-Feaures als Kernelement besitzen. Und davon abgesehen: die Aufgabenstellung des TS lässt langläufige Prozesse vermuten, und dafür wurde PHP nunmal wirklich nicht gemacht, sondern eher für das Gegenteil. Das Problem lässt sich natürlich in PHP lösen, aber die "right tool for the job"-Frage im Hinblick auf den Titel des Threads würde ich kaum mit PHP beantworten.

 

[benneq]

~55kB pro 0,4 Sekunden und pro Thread (insgesamt 4 Threads parallel).

Das sind ja ganze 550kb pro Sekunde. Das JSON Parsen ist also quasi ein feuchter Pups im Wind für eine aktuelle CPU. Jetzt kommt's stark drauf an, was du mit den Daten anstellen willst. RegExp Matching, etc.

Falls der Rechner nicht ausreichen sollte, kannst du natürlich auch mit einer Queue arbeiten (z.B. ActiveMQ oder RabbitMQ) und lässt dann mehrere Rechner die Jobs bearbeiten.
Das Vorgehen wäre quasi:
HTTP Request unbearbeitet in die Queue schieben, und dann holt sich jeder Consumer seine Aufgaben wenn er gerade nichts zu tun hat. Das skaliert unglaublich gut, aber ist nur nötig, wenn ein einzelner Rechner die Aufgabe nicht packen sollte.



Der Einfachheit halber würde ich auch zu Java raten, bevor dann irgendwo Speicherlecks im C(++) Code auftreten. Dazu dann Apache HttpClient und Jackson als JSON Parser. Und man kann auch direkt loslegen.

http://www.mkyong.com/java/how-to-send-http-request-getpost-in-java/
http://www.mkyong.com/java/how-to-convert-java-object-to-from-json-jackson/

mehr braucht's nicht

 

[yule0]

Ich würde dafür Go nehmen. Macht Spaß und ist schnell.

 

[VikingGe]

Du wirst nur selten besseren Assembler-Code schreiben als ein guter C-Compiler produziert.

Wenn man a) seine CPU-Architektur kennt und b) das richtige Anwendungsgebiet wählt (mit Vektor-Streaming haben praktisch alle Compiler so ihre Probleme, besonders GCC produziert häufig furchtbaren Code), ist das gar kein Problem. Bei reinem Integer-Code... würde ich es eher lassen, zumal x86 einfach ein furchtbares und inkonsequentes Instruction Set hat (MUL/IMUL-Problematik, zum Beispiel).

Man kann es tun, aber nicht ohne Trade-Off (aka Code wird unwartbarer/fehleranfälliger).

Bei Java gehen die Probleme schon los, wenn man ein Rechteck kopieren möchte - etwas, was jeder normale Mensch einfach als Stack-Objekt durch die Gegend schieben würde. C++ ist keine einfache und schon gar keine einsteigerfreundliche Sprache und man fliegt hin und wieder gewaltig auf die Nase, aber schneller Code lässt sich da meiner Erfahrung nach doch deutlich eleganter formulieren als in Java.


Trotzdem würde ich mir im konkreten Fall überlegen, ob es nicht sinnvoller wäre, auf eine Scriptsprache wie z.B. Python zu setzen. String-Parsing macht generell wenig Spaß, aber gerade bei Sachen wie regulären Ausdrücken (so diese benötigt werden) kann man davon ausgehen, dass a) recht viel Rechenzeit ohnehin im Matching verbraten wird - Regex-Matching hat lineare Laufzeit - aber auch, dass die entsprechenden Funktionen bereits gut optimiert sind. Der Overhead durch deinen eigenen Code wäre in dem Fall zu vernachlässigen und diese Sprachen bieten alle schon selbst Möglichkeiten, soetwas zu machen, ohne, dass man da mit Third Party-Libraries rumhantieren muss.

Kommt also jetzt wirklich darauf an, was genau du vorhast und wie viel Code du letztenendes selbst schreiben musst. Software optimieren nervt, und dein Code wird nicht dadurch schneller, dass du ihn in C++ schreibst - du musst die Sprache schon beherrschen, damit da wirklich effizienter Code bei heraus kommt (Aber: das ist auch häufig mit sauberem Code möglich), und solltest an den richtigen Stellen auch darauf achten, die CPU effektiv auszunutzen. Es bringt zum Beispiel gar nichts, eine hochoptimierte Funktion zu schreiben, wenn sie im Programm selbst ständig durch die Speicherbandbreite gebremst wird, weil die zu bearbeitenden Datenpakete nicht mehr in den Cache passen.