Lambda hat geschrieben:gegen den apache hätte ich nichts
[...]
den webserver wollte ich nun programmieren der einfachheit halber, da ich finde das wsgi fürn anfänger nicht ideal ist
[...]
bei meinem letzten post wollte ich nun wissen wie das möglich ist mehere request in einem thread zu behandeln
Hallo Lambda!
Das sind jetzt fast schon zu viele Fragen auf einem Haufen. Ich hoffe ich verzettle mich nicht beim Antworten...
1.) Der Apache ist ein **sehr schneller** Webserver, der mit vielen gleichzeitigen Anfragen klar kommt und mit der Zeit immer besser wurde. Es wurden Vorkehrungen getroffen, um DOS-Attacken besser zu überstehen, er wurde sicherer und schneller. Es wurden Möglichkeiten geschaffen, Daten im Speicher und auf der Festplatte zu cachen. Sogar als Proxy kann er eingesetzt werden. Der Apache ist, in meinen Augen, der Webserver schlechthin. Auch wenn es einfachere Webserver geben sollte, die evt. auch etwas schneller sind, so ist der Apache als Gesamtpaket sehr ausgereift und kaum zu schlagen.
Wenn du also eine Website auf dem Apachen laufen lassen kannst, dann tu es. Du wirst nicht so schnell etwas Besseres finden.
2.) Man programmiert sich keinen Webserver, nur weil man Python als Skriptsprache für Internetanwendungen einsetzen will. Es gibt viele tausende fertige Lösungen. Ich muss nur wissen, was erwartet wird und schon kann ich dich zu einer erprobten Lösung führen.
Um das Ganze mal zu konkretisieren:
Verwende z.B. Zope und Plone, wenn du ein fertiges Content Management System verwenden willst.
Verwende CGI unter dem Apachen oder mit dem Python-SimpleHTTPServer, um in einfache Seiten ein wenig Dynamik zu bringen. Ich finde sowieso, dass es keinen besseren Einstieg in die Webprogrammierung mit Python gibt, als sich erst mal mit CGI zu befassen. Pfeif zuerst mal auf Geschwindigkeit. Schau erst mal, dass du **irgendetwas** zum Laufen bekommst.
-
http://www.python.org/doc/current/lib/module-cgi.html
- [wiki]CGI[/wiki]
- [wiki]XAMPP mit Python CGI[/wiki]
Dieser CGI-Server
http://www.python-forum.de/post-23648.html#23648 ist schon so programmiert, dass er mit Threads arbeitet. Versuche nicht ihn zu optimieren, bevor du deine Anwendung nicht fertig gestellt hast.
Zum Thema Geschwindigkeit: Der Apache bietet einige Möglichkeiten an, Daten zu cachen. Statischer Content fühlt sich im Memory-Cache ziemlich wohl. Dynamischer Inhalt, kann so eingestellt werden, dass dieser ständig neu erstellt wird, falls das nötig ist, oder sich alle paar Minuten/Stunden/Tage erneuert. Man sollte sich zuerst mal darauf konzentrieren, dass die Anwendung funktioniert und erst dann mit der Geschwindigkeit befassen, wenn man merkt dass etwas zu langsam ist. So spart man sich viele, viele, viele unnötige Programmiertage.
Es gibt da auch noch Karrigell.
http://karrigell.sourceforge.net/
Karrigell ist genau so etwas, was du zu programmieren versuchst. Es ist ein Python-Webserver, der wunderbar mit Python klar kommt. Karrigell ist von sich aus schon nicht langsam. Aber Karrigell kann, wie jeder andere Webserver, **hinter** einem Apachen betrieben werden. Der Apache kümmert sich dann um das Caching und entlastet damit Karrigell. Das ist wirklich schnell. Überhaupt dann, wenn man statischen Content direkt vom Apachen ausliefern lässt. Aber auch das ist erst dann notwendig, wenn man merkt, dass die Website zu langsam wird.
-
http://www.python-forum.de/topic-9077.html
3.) Thema Multithreading mit dem BaseHTTPServer:
Schon das einfachste Programm, das statt dem "SocketServer.TCPServer" den "SocketServer.ThreadingTCPServer" verwendet, arbeitet mit Threads. Du musst dich um fast NICHTS mehr kümmern. Wichtig ist nur, dass du nicht schreibend von mehreren Threads aus auf die gleichen Objekte zugreifst, wenn diese nicht speziell "thread-safe" sind. Wie ich schon erklärte, meine ich damit schreibenden Zugriff auf globale Variablen genau so wie den schreibenden Zugriff auf File-Objekte, usw.
Es ist komplett ungefährlich, wenn du von mehreren Threads aus auf die gleichen Daten "lesend" zugreifst.
Es ist GUT, wenn die einzelnen Requests in einzelnen Threads abgearbeitet werden. Es gibt keinen Grund, weshalb du dich da einmischen solltest. Jeder Job in einem eigenen Thread -- und gut. Versuche nicht erst irgendwelche Jobs wieder in einen Thread zusammenzulegen. Damit drehst du dich nur im Kreis.
Wenn zehn Leute gleichzeitig deine Website ansehen, dann werden nicht alle zehn Leute gleichzeitig auf einen Link klicken. Du kannst also davon ausgehen, dass wenn zehn Leute deine Website ansehen, dass (geschätzt) im Durchschnitt nur zwei gleichzeitige Requests abzuarbeiten sind. Das ist lächerlich wenig. Meine Website schauen sich täglich ca. 100 Leute an. Aber auf einen ganzen Tag verteilt ist das *nichts*. Ich habe es mit 500 bis 3000 Hits am Tag zu tun. Was sind schon 3000 Requests. Bei einem 10-Stunden Tag wären das 5 Requests pro Minute.
Apache: Schnell bei wenigen gleichzeitigen Zugriffen und schnell bei vielen gleichzeitigen Zugriffen.
CGI: Schnell genug bei wenigen gleichzeitigen Zugriffen. Wird langsamer bei mehreren gleichzeitigen Zugriffen.
Karrigell: Schnell bei wenigen gleichzeitigen Zugriffen. Wird langsamer bei mehreren gleichzeitigen Zugriffen.
Erst dann, wenn die Website zu langsam wird -- und nur dann -- solltest du dir Gedanken über die Beschleunigung machen. In den allermeisten Fällen genügt ein wenig Caching.
Edit: Fast hätte ich es vergessen:
HTTP/1.1 sieht als Standard vor, dass der Client eine Verbindung aufbaut und diese so lange offen hält, bis der Webserver im Header "Connection" "close" zurück gibt. Es braucht, meines Wissens, keine zusätzliche Aktion dafür.
Wenn der Server "Connection" "close" nicht zurück gibt, dann wird die Verbindung sowiso vom Server getrennt. Es ist also nicht unbedingt notwendig, sich um "Connection" "close" zu kümmern, aber es ist auch nicht schlecht.
Der Client ist dafür zuständig, die Verbindung aufrecht zu erhalten und die Requests über diese Verbindung zu übergeben. Der Server muss sich nicht besonders darum kümmern. Wenn der Client HTTP/1.1 kann, dann wird er es auch damit versuchen und erst dann auf HTTP/1.0 zurück schalten, wenn der Server nicht korrekt auf die HTTP/1.1-Anfrage reagiert.
Was ich damit sagen will? Dein Server kümmert sich eh schon automatisch um alles. Du musst nichts mehr dazuprogrammieren. Zumindest habe ich es so verstanden und man möge mich ausbessern, falls ich falsch liege.
mfg
Gerold