Seite 1 von 1

Gibt es ein Problem mit dem in Python eingeb. HTTP-Server?

Verfasst: Freitag 15. Juni 2007, 09:40
von gerold
Hallo!

Ihr kennt sicher die Codeschnipsel Einfacher XML-RPC Server und Client und Einfacher Threading XML-RPC Server und Client.

Testumgebung: Python 2.4.4; Windows XP Professional;


Neulich wollte ich testen, wie lange es dauert, mit dem einfachen "Threading XMLRPC-Server", einen kleinen (500kb) Datenbankdump von Tirol nach Wien zu übertragen. Wenn die Skripte lokal ausgeführt werden, dann funktioniert alles wie gewünscht.

Zuerst wollte ich einfach nur die oben genannten Skripte ausprobieren, um die Verbindung zu testen. Dafür habe ich mich mit meinem Technischen Leiter in Verbindung gesetzt und ihn gebeten, auf seinem Computer das Serverskript auszuführen.

Noch schnell ein Ping (um sicher zu gehen) an den Computer geschickt. --> 30ms damit kann ich gut leben.

Das Serverskript wurde in Wien gestartet und ich startete das Clientskript von Tirol aus. Und jetzt kommt's: Es dauerte bei jedem Test um die fünf bis sechs Sekunden, bis ich eine Antwort vom Serverskript sah.

Auch in Wien sah man erst nach fünf oder sechs Sekunden eine Reaktion auf dem Computer. Dann dachte ich mir. Vielleicht liegt es an dem Skript selber, also habe ich veranlasst, dass zum Testen folgender, einfacher CGI-Server gestartet wird.

Code: Alles auswählen

#!/usr/bin/python
# -*- coding: iso-8859-1 -*-

from BaseHTTPServer import HTTPServer
from CGIHTTPServer import CGIHTTPRequestHandler

server = HTTPServer(("", 8888), CGIHTTPRequestHandler)

print "Der Server horcht auf Port 8888"
server.serve_forever()
Im Browser habe ich dann "http://<ip_von_wien>:8080/" eingegeben. Auch dieser Versuch endete erst nach fünf Sekunden Wartezeit. Auch nach mehrmaligen Versuchen --> fünf Sekunden.

Dann ließ ich in Wien auf dem gleichen Computer den Apachen installieren. Dieser horchte auf Port 8080. Und siehe da. Es gab keine Verzögerung, bis ich etwas vom Apachen zu sehen bekahm.

Was ist da los? Warum gibt es diese Verzögerung, bei der Verwendung des eingebauten HTTP-Servers???
Bei Karrigell-Websites habe ich von diesem Verhalten auch schon gehört -- aber nur selten.

Kann es sein, dass der eingebaute HTTP-Server Probleme mit Windows hat?

Ich machte noch einen Versuch. Ich schrieb ein kleines CherryPy-Skript. Eines, das aus dem CherryPy-Server einen XMLRPC-Server macht.

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: iso-8859-15 -*-

import cherrypy
from cherrypy._cptools import XMLRPCController


class Root(XMLRPCController):

    def xmlrpctest(self, text):
        return {"text": text}
    xmlrpctest.exposed = True


def main():
    cherrypy.quickstart(Root())


if __name__ == "__main__":
    main()
Dieses wurde wieder in Wien ausgeführt und von Tirol aus aufgerufen. --> keine Verzögerung. Vielleicht greift CherryPy intern NICHT auf den eingebauten HTTP-Server zu. Aber das habe ich nicht kontrolliert.

Weiß jemand, warum und weshalb und überhaupt? Weiß jemand einen Workarround, um den eingebauten HTTP-Server doch nutzbar zu machen?

lg
Gerold
:-)

Verfasst: Freitag 15. Juni 2007, 09:44
von mitsuhiko
Ich nutze kein Windows und hatte bis jetzt auch keine Probleme mit dem Ding. Hast du mal getestet ob wsgiref das gleiche Problem hat?

Verfasst: Freitag 15. Juni 2007, 10:26
von gerold
blackbird hat geschrieben:Ich nutze kein Windows und hatte bis jetzt auch keine Probleme mit dem Ding. Hast du mal getestet ob wsgiref das gleiche Problem hat?
Hallo blackbird!

Ich habe mir den Ordner "wsgiref" vom Python 2.5 geholt und in den Python24\Lib-Ordner kopiert.

Danach habe ich das erste Beispiel von deiner Seite http://lucumr.pocoo.org/articles/gettin ... -with-wsgi geholt. "localhost" raus geschmissen und mit genauen Anweisungen nach Wien geschickt. In Wien wurde alles vorbereitet und das Skript gestartet. Lange Rede, kurzer Sinn: wsgiref liefert mir das Ergebnis erst nach zehn Sekunden zurück.

Ich habe nachgesehen. wsgiref verwendet auch den HTTPServer und den BaseHTTPRequestHandler.

lg
Gerold
:-)

Verfasst: Freitag 15. Juni 2007, 10:55
von gerold
Hallo!

Soeben habe ich alle Tests mit Python 2.5 (Clientseite und Serverseite) wiederholt. Keine Verbesserung der Reaktionszeit.

mfg
Gerold
:-)

Verfasst: Freitag 15. Juni 2007, 11:09
von EnTeQuAk
Also ich bin mir sicher, das es am Python HTTP-Server liegt.

CherryPy's Webserver verwendet den nicht: http://svn.cherrypy.org/trunk/cherrypy/ ... _init__.py

Was deine Aussage über die CherryPy XML-RPC Applicaktion erklärt.


Warumd as so ist.. keine Ahnung. Jedenfalls muss da irgentwas nicht ganz rund laufen.


MfG EnTeQuAk

Verfasst: Freitag 15. Juni 2007, 12:25
von mitsuhiko
Also wenn wsgiref die gleichen Spompanadln macht, dann ist es zumindest nicht der threading mixin. Was sagt google?

Verfasst: Freitag 15. Juni 2007, 14:04
von gerold
blackbird hat geschrieben:Was sagt google?
Hallo blackbird!

Zu meiner Schande muss ich zugeben, dass ich bis jetzt noch gar nicht gesucht habe. Danke für deinen Schupser. ;-)

Also hier habe ich schon mal einen Hinweis. http://trac.edgewall.org/ticket/3481 Ich muss nur noch mal genauer d'rüber lesen. Vielleicht ist die Lösung ja schon gefunden.

lg
Gerold
:-)

Verfasst: Freitag 15. Juni 2007, 14:24
von gerold
Hallo!

Vielleicht liegt es wirklich daran, dass im Modul "BaseHTTPServer" bei jedem Request der "fqdn" abgefragt wird: ``return socket.getfqdn(host).

Das hier könnte evt. die Lösung sein:

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: utf-8 -*-
"""
Einfacher XMLRPC-Server
"""

from SimpleXMLRPCServer import SimpleXMLRPCServer
from SimpleXMLRPCServer import SimpleXMLRPCRequestHandler
from random import randint

class SimpleXMLRPCRequestHandler_(SimpleXMLRPCRequestHandler):
    def address_string(self):
        # Disable reverse name lookups
        return self.client_address[:2][0]

class XmlrpcHandler:
    def get_random_int(self, from_int, to_int):
        return randint(from_int, to_int)

server = SimpleXMLRPCServer(("", 50505), SimpleXMLRPCRequestHandler_)
server.register_instance(XmlrpcHandler())
print "Der XMLRPC-Server horcht auf Port 50505."
print "Er kann mit STRG+C oder STRG+PAUSE beendet werden."
server.serve_forever()
Aber heute ist niemand mehr in Wien, der das mit mir testen könnte.

lg
Gerold
:-)

Verfasst: Freitag 15. Juni 2007, 17:49
von Sr4l
Wenn du mal einen Test Tirol und einem Ort mitte in Deutschland (Nord Hessen; ganzes Stück über Frankfurt am Main) machen willst bin ich immer dafür zuhaben. Sag einfach Kontakt Möglichkeit. IRC ICQ ....

XP Pro SP2 und Ubuntu möglich ;-)

Verfasst: Freitag 15. Juni 2007, 19:12
von gerold
Sr4l hat geschrieben:immer dafür zuhaben
Hallo Sr4l!

Danke für das Angebot, aber ich habe es nicht mehr eilig. Und ich würde es ja sowiso am Montag doch noch einmal mit Wien testen. :-)

lg
Gerold
:-)

Verfasst: Freitag 15. Juni 2007, 19:28
von Sr4l
Schreib aber bitte dann mal Bericht ob und wie es dann ging.

Weil bisher hatte ich immer nur Linux Server im Einsatz.
Könnte sich ja (Gott bewahre) ändern. :-)

Verfasst: Freitag 15. Juni 2007, 21:28
von gerold
Sr4l hat geschrieben:Schreib aber bitte dann mal Bericht ob und wie es dann ging.
Mach' ich.

Verfasst: Mittwoch 20. Juni 2007, 10:46
von gerold
gerold hat geschrieben:Vielleicht liegt es wirklich daran, dass im Modul "BaseHTTPServer" bei jedem Request der "fqdn" abgefragt wird: ``return socket.getfqdn(host).
Hallo!

Endlich habe ich wieder so viel Stimme, dass ich mich mit Wien kurzschließen konnte. (ich war total heiser und konnte kaum einen Ton raus bringen)

Der Test ist positiv verlaufen. Das hier http://www.python-forum.de/post-70950.html#70950 ist die Lösung. ``socket.getfqdn`` braucht zu lange und bremst damit das Programm aus.

mfg
Gerold
:-)

PS: Vielleicht könnte das jemand bitte den Python-Entwicklern mitteilen. Denn das ist ein Problem, das sich sehr negativ auf das Ansehen von Python auswirken kann. Hier wird implizit etwas gemacht, was niemandem etwas bringt.

Verfasst: Mittwoch 20. Juni 2007, 14:55
von Damaskus
Hallo Gerold,
ich verwende inziwschen seit über einem halben Jahr den XMLRPC Server / Client und verschick damit Pakete mit ca 700kb und hab bisher noch keine Problemem gehabt.

Allerdings hab ich nur mit XP, Vista 64 Bit und Python 2.5 getestet.
Wobei die Strecke von Nürnberg nach Freudenstadt nicht unbedingt weit ist.

Gruß
Damaskus

Verfasst: Mittwoch 20. Juni 2007, 15:37
von gerold
Damaskus hat geschrieben:Allerdings hab ich nur mit XP, Vista 64 Bit und Python 2.5 getestet. Wobei die Strecke von Nürnberg nach Freudenstadt nicht unbedingt weit ist.
Hallo Damaskus!

Das hat nichts mit der Strecke zu tun, sondern damit, wie lange ``socket.getfqdn()`` (im Server) braucht, um den Namen des Clients aus seiner IP-Adresse aufzulösen. Das Auflösen des Namens kann unter Umständen über mehrere DNS-Server laufen, oder erst über ein Timeout gestoppt werden. Das hängt mit der Konfiguration des verwendeten Netzes zusammen.

Da nicht jeder Computer im Internet ist und einen gültigen Domainnamen hat, finde ich es nicht richtig, dass ``socket.getfqdn()`` implizit aufgerufen wird.

lg
Gerold
:-)