(HTTP) Server mit Qt4

**TheDodger** · 19-12-2010, 11:56

Zitat von anda_skoa

Falls du noch nach einer Qt basierten Templateengine suchst, vielleicht wäre Grantlee das was für dich: http://www.gitorious.org/grantlee/pages/Home

Ciao,
_

Danke für den Tipp!
Schau ich mir gern an.

Momentan versuche ich erstmal Plugins zum fliegen zu bekommen. Aktuell nehme ich dazu meine (mit deiner Hilfe entstandene) Klasse aus dem Jahre 2003 ...

Aber ich glaube, ich komm wohl nicht darum, das ganze nochmal ganz von vorn zu machen ...

[edit]
Ja, so ist es.
Den Plugin-Kram muß ich quasi von NULL auf noch mal entwickeln.
Kann mir jemand Hilfe anbieten?

**anda_skoa** · 19-12-2010, 19:24

Zitat von TheDodger

Den Plugin-Kram muß ich quasi von NULL auf noch mal entwickeln.
Kann mir jemand Hilfe anbieten?

Dazu gibt es mittlerweile offizielle Doku von Nokia/Trolltech:
http://doc.qt.nokia.com/latest/plugins-howto.html

Siehe Sektion "low level API"

Ciao,
_

**TheDodger** · 20-12-2010, 05:11

Zitat von anda_skoa

Dazu gibt es mittlerweile offizielle Doku von Nokia/Trolltech:
http://doc.qt.nokia.com/latest/plugins-howto.html

Siehe Sektion "low level API"

Ja, die hatte ich zwischenzeitlich auch gefunden.
Allerdings war ich gestern wohl nicht mehr voll da (und mein Zwerg wollte mehr Aufmerksamkeit), da hab ich nichts mehr funktionsfähiges hinbekommen.
Wahrscheinlich hab ich mich auch auf der Suche nach einem funktionierenden Codeschnippsel für eine PluginFactory total verrannt

[edit]
Ja, ausgeschlafen und mit anderen Ansätzen gehts dann doch

Hat sich einiges geändert, dass ich erstmal in das alte Hirn bekommen muß

**TheDodger** · 20-12-2010, 08:39

Zitat von TheDodger

Sooo ... ich habe ein kleines Proof-of-Concept am Start.
Ein Programm, welches einen TCP-Port aufreist und dort anfragen entgegen nimmt.
Eine simple GET-Anfrage funktioniert auch.

Ich stellt das mal Online download ...
Vielleicht kann das ja mal jemand gebrauchen / mir Tipps geben / helfen, etc. ...

**zenobic** · 21-12-2010, 17:13

Nur eine Anregung:

In "env" könnte man z.B. session_id's reinlegen.
Zur jeder SessionId, könnte man die zugehörigen Werte serialisiert (z.B. QTScript JSON encoded) in env oder auf dem Filesystem ablegen (Server) sowie Client als Cookie oder Parameter.

Dafür würde ich "env" von einer globalen Konfigdatei entkoppeln,
da es schon readConfiguration gab, habe ich einen kleinen Patch:

http://pastebin.com/7RgDEMGd

(Es muss wenn es dir gefällt, noch die Signatur der 2 Funktionen in der Headerdatei aktualisiert werden).

**TheDodger** · 21-12-2010, 20:31

Zitat von zenobic

Nur eine Anregung:

In "env" könnte man z.B. session_id's reinlegen.
Zur jeder SessionId, könnte man die zugehörigen Werte serialisiert (z.B. QTScript JSON encoded) in env oder auf dem Filesystem ablegen (Server) sowie Client als Cookie oder Parameter.

Dafür würde ich "env" von einer globalen Konfigdatei entkoppeln, da es schon readConfiguration gab, habe ich einen kleinen Patch:

http://pastebin.com/7RgDEMGd

(Es muss wenn es dir gefällt, noch die Signatur der 2 Funktionen in der Headerdatei aktualisiert werden).

Vielen Dank!
Das schau ich mir gleich (oder morgen früh) mal an!

'env' kommt noch aus einem etwas älterem Projekt, da sind unter Garantie völlig Sinnfreie Dinge mit drin.

Sobald der Server mehrere Statische Dateien ausliefern kann, werd ich das mal mit siege stressen.
Ich weiß nämlich überhaupt nicht, ob er mehrere Anfragen parallel abarbeiten kann

In dem Sinne ... wäre es eigentlich sinnvoll, das ganze Ding mit Threads zu realisieren, oder weniger?

[EDIT]
Dann würde das mit den Plugins und QPluginLoader aber nicht mehr so funktionieren, richtig?
So wie ich das ganze verstanden hab, muß ich, beim Einsatz von Threads, die Plugins mit QLibrary laden, auch richtig?

**zenobic** · 21-12-2010, 21:14

Zitat von TheDodger

Vielen Dank!
Sobald der Server mehrere Statische Dateien ausliefern kann, werd ich das mal mit siege stressen.
Ich weiß nämlich überhaupt nicht, ob er mehrere Anfragen parallel abarbeiten kann

In dem Sinne ... wäre es eigentlich sinnvoll, das ganze Ding mit Threads zu realisieren, oder weniger?

Ich konnte es mir nicht verkneifen schon zu benchmarken und muss sagen, mit der Statusseite performt es jetzt schon (auch parallel) gut (es gibt ja auch Projekte die auch weitere Seiten in diesem Stil "hardcoden").

Da sind aber noch einige QT Meldungen die ich mir nicht genauer angesehen habe.

Code:

ab -n 1000 -c 5 http://127.0.0.1:8081/index.html

**TheDodger** · 22-12-2010, 05:51

Zitat von zenobic

Ich konnte es mir nicht verkneifen schon zu benchmarken und muss sagen, mit der Statusseite performt es jetzt schon (auch parallel) gut (es gibt ja auch Projekte die auch weitere Seiten in diesem Stil "hardcoden").

Da sind aber noch einige QT Meldungen die ich mir nicht genauer angesehen habe.

Code:

ab -n 1000 -c 5 http://127.0.0.1:8081/index.html

Ahh, danke!

Du meinst bestimmt dieses hier:

Code:

Object: Cannot create children for a parent that is in a different thread.
(Parent is QUdpSocket(0x2a77470), parent's thread is QThread(0x71a540), current thread is QThread(0x8072d0)
Error: 4

Das sind Debug meldungen, die meine UDP-Debugkonsole empfangen könnte.
Wenn du in der 'Server.pro' das debug aus der config entfernts, sind die Meldungen auch weg.

Aber ab einer bestimmten Zeit liefert er nur noch 0 bytes große Dateien (mit einem 200er) aus.
Das ist dann eher "subobtimal"

**TheDodger** · 22-12-2010, 15:12

Zitat von TheDodger

Aber ab einer bestimmten Zeit liefert er nur noch 0 bytes große Dateien (mit einem 200er) aus.
Das ist dann eher "subobtimal"

Also das ständige öffnen und schließen von Dateien ist dann ja nicht ganz so perfomant, wie es scheint.

Da dachte ich bei mir, dass ich das doch eigentlich über ene QCache-Geschichte abbilden kann. Einmal geladen, dann in den Cache gesteckt und dann nur noch den genutzt ...

Aber QCache scheint ziemlich destruktiv zu sein.
Wenn ich den Inhalt einmal gelesen habe (QCache::take() ) dann ist der Cache wieder leer.
Auch der anderen Seite performat das jetzt auch nicht mehr so toll.
Dafür wird jetzt immer die ganze Datei ausgeliefert.
Sobald ich das mit dem Cache geschnallt hab, bau ich mal ein neues Archiv

**zenobic** · 23-12-2010, 10:58

Zitat von TheDodger

Vielen Dank!
In dem Sinne ... wäre es eigentlich sinnvoll, das ganze Ding mit Threads zu realisieren, oder weniger?

Mit fork ist es nicht nur einfacher, sondern soweit ich weiss auch stabiler, aber eben nicht performanter.
Wobei Performance auch mit I/O auf der Platte zu tun hat und somit die darunterliegenden Lowlevel/Kernelfunktionen eine grosse Rolle spielen.

Zumindest hörte ich, dass ein Apache2 (Standardkonfiguration) mit Threads abstürzen kann,
da ein Thread den Prozess lahm legen kann.
Ein forked Prozess nicht (Apache1 oder Apache2 mit pre-fork modul).

fork() gibt es soweit ich weiss nicht für QT, da es dies nicht plattformübergreifend gibt.

Jetzt ist es doch jeder Request ein Thread oder meinst du multithreaded (QtConcurrent) ?

**TheDodger** · 23-12-2010, 12:28

Zitat von zenobic

Mit fork ist es nicht nur einfacher, sondern soweit ich weiss auch stabiler, aber eben nicht performanter.
Wobei Performance auch mit I/O auf der Platte zu tun hat und somit die darunterliegenden Lowlevel/Kernelfunktionen eine grosse Rolle spielen.

Deswegen wollte ich ja QCache nutzen um die I/O etwas zu entkoppeltn.

Zitat von zenobic

Zumindest hörte ich, dass ein Apache2 (Standardkonfiguration) mit Threads abstürzen kann, da ein Thread den Prozess lahm legen kann.
Ein forked Prozess nicht (Apache1 oder Apache2 mit pre-fork modul).

fork() gibt es soweit ich weiss nicht für QT, da es dies nicht plattformübergreifend gibt.

Jetzt ist es doch jeder Request ein Thread oder meinst du multithreaded (QtConcurrent) ?

Plattformübergreifend interessiert mich in dem Falle nicht die Bohne!

Das Ding soll & wird ausschließlich auf Linux-Systemen laufen ...

Ich habe mit Threadprogrammierung absolut keine Erfahrung :/ bislang waren alle Anwendungen weniger Ressourcenfressend, oder hatten einfach nicht solche Timingprobleme.
Es würde also meine erste Threaded Anwendung werden ... *grussel*

Ich glaube, ich versuche das mit dem Cache (oder buffer, wie mans nennen will) hinzubekommen.
Vielleicht entschärft das ja schon meine Probleme?

**anda_skoa** · 23-12-2010, 12:58

Zitat von TheDodger

Wenn ich den Inhalt einmal gelesen habe (QCache::take() ) dann ist der Cache wieder leer.

Das ist auch die Aufgabe von take()

Zugriff auf ein Element mit QCache:

perator[] oder QCache:

bject()

Analog zum verhalten von Qt3 QDict

Ciao,
_

**TheDodger** · 23-12-2010, 17:54

Zitat von anda_skoa

Das ist auch die Aufgabe von take()

Zugriff auf ein Element mit QCache:

perator[] oder QCache:

bject()

Analog zum verhalten von Qt3 QDict

Ciao,
_

Das erklärt einiges.
Aaaaber ... ich möchte mal zitieren:

Code:

T * QCache::take ( const Key & key )
Takes the object associated with key key out of the cache without deleting it. Returns a pointer to the object taken out, or 0 if the key does not exist in the cache.
The ownership of the returned object is passed to the caller.
See also remove().

Speziell ' Takes the object associated with key key out of the cache without deleting it. ' Das heisst für mich, eben, dass der Cache-Eintrag nicht gelöscht wird.

Mit :

bject() rockt es dann wieder.

Danke!

**anda_skoa** · 24-12-2010, 11:43

Zitat von TheDodger

Speziell ' Takes the object associated with key key out of the cache without deleting it. ' Das heisst für mich, eben, dass der Cache-Eintrag nicht gelöscht wird.

Er wird auch nicht gelöscht, der Pointer auf das Objkt bleibt also gültig. Aber es wird eben aus dem Cache rausgenommen

Ciao,
_