fastcgi: prefork oder threaded? - minspare, maxspare usw...

[jens]

Schade das man da an einem Punkt angelangt ist, wo die Unterschiede zwischen den Linux Distributionen wichtig wird...

[BlackJack]

@jens: Dann binde das in `supervisord` ein und hoffe, dass *das* schon von der Distribution in den Startprozess eingebunden wird.

[Leonidas]

Schade das man da an einem Punkt angelangt ist, wo die Unterschiede zwischen den Linux Distributionen wichtig wird...

Ich würde eh nur systemd unterstützen, macht ja keinen Sinn jedes eigene Ding zu supporten.

[jens]

Überlege Uberspace.de zu nutzten. Dort ist nur fastCGI drin. Wie bei vielen anderen SharedHostern auch (wenn man von mod_Python absieht), siehe: http://wiki.python.de/Python%20Webspace (Hab ich mal wieder ein wenig aktualisert)

Doch mit flup hatte ich ja ehr schlechte Erfahrungen. Wenn man mal nach fastCGI auf im Package Index sucht, findet man schon einige Treffer:

http://pypi.python.org/pypi?%3Aaction=s ... mit=search

Welche Alternativen könnt ihr empfehlen?

EDIT: Hm. Wenn man sich die PyPi Trefferliste genauer ansieht, bleibt eigentlich nur: gevent-fastcgi
* http://pypi.python.org/pypi/gevent-fastcgi/
* https://github.com/momyc/gevent-fastcgi
Das setzt dann auf http://www.gevent.org/ auf. Allerdings finde ich in den sourcen auch noch das:

Code: Alles auswählen

from zope.interface import implements

siehe: https://github.com/momyc/gevent-fastcgi ... gi/base.py

Jemand Erfahrungen mit gevent-fastcgi ?

[Leonidas]

Warum nicht einen der Django-Hoster statt sich wieder irgendwas zusammenhacken müssen? Soviel günstiger kann es gar nicht sein, dass sich der Zeitaufwand für FastCGI lohnt. Habe letzte Woche eine Migration von FastCGI zu mod_wsgi (mit virtualenv) hinter mir, hätte ich schon *wesentlich* früher machen sollen.

[jens]

Warum nicht einen der Django-Hoster ... ?

Welchen z.B.?

[Leonidas]

Warum nicht einen der Django-Hoster ... ?

Welchen z.B.?

PYROX, Django Europe (vormals djangohosting.ch). Wurden auch schon öfters in anderen Threads erwähnt.

[jens]

Bei djangoeurope.com gibt es aber anscheinend auch nur fastCGI, zumindest finde ich es hier:
* https://panel.djangoeurope.com/support/manual-setup/
* https://panel.djangoeurope.com/faq/

Bei Pyrox finde ich recht wenig Information. Außerdem erscheint es mir sehr teuer zu sein. Minimum ist 8.33 € Doch wenn man Speicher/CPU ein wenig hoch dreht, ist man schnell mit wesentlich mehr dabei. Wie viel ich wirklich brauchen werde kann ich auch schlecht abschätzen. Hab z.Z. einen vServer mit 512MB RAM für 5€/Monat.

[Leonidas]

Bei Djangohosting hat es, wenn ich mich richtig erinnere, gereicht einfach irgendeinen Server zu haben, ob man Lighty oder was anderes betreibt war da relativ egal weil das eh hinter einem Proxy hing.

[apollo13]

Bei Pyrox finde ich recht wenig Information. Außerdem erscheint es mir sehr teuer zu sein. Minimum ist 8.33 € Doch wenn man Speicher/CPU ein wenig hoch dreht, ist man schnell mit wesentlich mehr dabei. Wie viel ich wirklich brauchen werde kann ich auch schlecht abschätzen. Hab z.Z. einen vServer mit 512MB RAM für 5€/Monat.

Die 5€ sind aber ohne Wartung, wenn du jetzt im Monat auch nur 10 Minuten damit verbringst Updates einzuspielen bist du preislich über dem was Pyrox will. Es ist halt immer die Frage wie viel deine Zeit wert ist…

[jens]

Ja, klar. Darum geht es mir ja. vServer kostet halt Zeit. Deswegen suche ich, mal wieder, nach Alternativen.

Der bisherige Schwachpunkt bei uberspace ist halt, das "nur" fastCGI verfügbar ist. Wobei ich Jahrelange das mehr oder weniger ohne Probleme genutzt habe. Die Probleme kamen erst auf, nachdem ich versucht habe, die Task Anzahl gering zu halten (Das war der Ursprüngliche Sinn dieses Threads). Doch bei uberspace hat man da kein festes Limit.

[Leonidas]

Wie wärs einfach die Leute bei Uberspace anzuschreiben? Die Webseite vermittelt zumindest den Eindruck, dass man da nicht so wie bei 1&1 erstmal durch ein Meer von Telefonsupport-Drohnen waten muss, sondern recht zeitnah an einen Techniker kommt, mit dem man sowas besprechen kann.

Als Vorteil von mod_wsgi kannst du ihnen ja verkaufen, dass es quasi die Methode ist, wie man Python-Applikationen deployed, zumindest auf Apache. Was es ja ist.

[apollo13]

Wie wärs einfach die Leute bei Uberspace anzuschreiben? Die Webseite vermittelt zumindest den Eindruck, dass man da nicht so wie bei 1&1 erstmal durch ein Meer von Telefonsupport-Drohnen waten muss, sondern recht zeitnah an einen Techniker kommt, mit dem man sowas besprechen kann.

In der Tat, die Frage ist nur wer den Techniker bei sagen wir mal durchschnittlich 3€/Monat zahlt

Als Vorteil von mod_wsgi kannst du ihnen ja verkaufen, dass es quasi die Methode ist, wie man Python-Applikationen deployed, zumindest auf Apache. Was es ja ist.

Für apache ist es defakto Standard, außerdem bietet es einem an die App im Usercontext laufen zu lassen, im Gegensatz zu Plain-FCGI somit sicherer. Und mod_fcgi + suexec hat nen Haufen anderer Probleme (eg LANG nicht durchgereicht somit gehen in manchen Funktionen keine Dateinamen mit Umlauten).

[Leonidas]

Wie wärs einfach die Leute bei Uberspace anzuschreiben? Die Webseite vermittelt zumindest den Eindruck, dass man da nicht so wie bei 1&1 erstmal durch ein Meer von Telefonsupport-Drohnen waten muss, sondern recht zeitnah an einen Techniker kommt, mit dem man sowas besprechen kann.

In der Tat, die Frage ist nur wer den Techniker bei sagen wir mal durchschnittlich 3€/Monat zahlt

Naja, irgendwie muss es über die Masse gehen, ansonsten haben die entweder Idioten die die Technik machen oder sind demnächst pleite.

[jens]

Hab es über twitter gemacht und recht zeitnah eine Antwort bekommen, das der Bedarf nicht gesehen wird: https://twitter.com/ubernauten/status/2 ... 1673780225

Sind wahrscheinlich auch dort 99% php user.

[Leonidas]

Dann mit dem Geldbeutel abstimmen

[jens]

Im uberspace Wiki sehe ich gerade das es über mod_WSGI und auch uWSGI einige Anmerkungen gibt, warum es nicht angeboten wird: https://uberspace.de/dokuwiki/brainstorming#mod_wsgi

Interessant ist dieses:

Wenn nun also dieser „daemon mode“ so ähnlich wie FastCGI ist, fragt sich, warum man dann nicht einfach gleich FastCGI nimmt. Und hier greift die mod_wsgi-Dokumentation dann auch direkt ein und kommentiert, dass mod_wsgi sowieso nicht für „mass virtual hosting arrangements“ gedacht sei und man dort FastCGI nehmen solle

Dazu kommt noch, das anscheinend mod_WSGI nur immer für eine Python Version installiert werden kann.