Lösung für ein nicht-existentes Problem

[titrat]

Die Speed des Webservers ist bei heutigen CPUs und bei den heutigen Webanwendungen in keiner Weise ein schwierig zu lösendes Problem mehr.
99,99% der CPU-Zeit gehen nicht im Webserver drauf, sondern in der Datenbank und in der eigentlichen Webanwendung, die in Java, C# oder auch PHP programmiert ist.

Dieses eine Promille aber zu optimieren, womöglich auf Kosten der Sicherheit und des Komforts, ist wenig hilfreich.

Selbst die Sicherheit ist heute kaum mehr Thema, weder Apache noch IIS fielen in den letzten Jahren durch großartige ständige Lücken auf, zumindest ist kaum zu erwarten, das ein Nischenprojekt hier besser sein wird.

Daher halte ich die aufgewendete Zeit für NOCH EINEN Webserver für eher verschwendet denn gut verwendet.

Interessanter sind Entwicklungen, wie sie google mit dem experimentellen neuen http-Protokoll anstößt.
Aber natürlich darf jeder da arbeiten, wo er möchte - gut finden muss ich das aber nicht.

[Abcdefghijklmnopqrstuvwxzy]

> Interessanter sind Entwicklungen, wie sie google mit dem
> experimentellen neuen http-Protokoll anstößt.

Gibt es da einen Link oder einen Namen zu? Bei googlelabs ist nichts zu finden.

[katzenpisse]

titrat schrieb:
--------------------------------------------------------------------------------
> Die Speed des Webservers ist bei heutigen CPUs und bei den heutigen
> Webanwendungen in keiner Weise ein schwierig zu lösendes Problem mehr.
> 99,99% der CPU-Zeit gehen nicht im Webserver drauf, sondern in der
> Datenbank und in der eigentlichen Webanwendung, die in Java, C# oder auch
> PHP programmiert ist.

Un die Welt ist schwar/weiß.

[Ritter von NI]

Wenn wir mir einer funktionierenden Lösung immer zufrieden wären würden wir heute noch die Programme mit dem Locher in Papier stanzen. Warum etwas neues? Das funktioniert doch

[LX]

Konkurrenz ist gut, weil diese Ansporn und Anregungen für die Weiterentwicklung gleichermaßen gibt.

Gruß, LX

[immer_diese_unreflektierten_behauptungen]

titrat schrieb:
--------------------------------------------------------------------------------

> Dieses eine Promille aber zu optimieren, womöglich auf Kosten der
> Sicherheit und des Komforts, ist wenig hilfreich.

Dieser Webserver ist dank seiner WebAdministration viel komfortabler zu bedienen als Apache und Lighty ...

[rednose-paindeer]

in großen static umgebungen, bilder auslieferung, static content etc. wo Millionen von Requests auf hunderte oder tausende Server verteilt werden ist es sehr wohl entscheidend, wieviele Requests ein Server handeln kann. Wenn ein Server 10% mehr Requests verarbeiten kann, spare ich mir bei 1000 Stück die Anschaffung weiterer 100 um dieselbe Last abzuwickeln. Das ist dann wohl schon ein eher großer Posten, der da zum Tragen kommt, was Anschaffung, Betrieb und Wartung angeht.

[sergnit5]

Dito. Bitte mal über den eigenen Anwendungsbereich hinausdenken.

[testtest]

Was ich intressant finde.
Zukünftig ist auch Content-Caching im Cherokee Server vorgesehen.
Dadurch könnte ich evtl. meinen vorgelagerten Varnish abschaffen.
Auch soll es in einem späteren Release möglich sein, einen Cherokee Cluster zentral zu administrieren (tribe).

[fsadfsafasfasfasfsa]

titrat schrieb:
--------------------------------------------------------------------------------
> Die Speed des Webservers ist bei heutigen CPUs und bei den heutigen
> Webanwendungen in keiner Weise ein schwierig zu lösendes Problem mehr.
> 99,99% der CPU-Zeit gehen nicht im Webserver drauf, sondern in der
> Datenbank und in der eigentlichen Webanwendung, die in Java, C# oder auch
> PHP programmiert ist.
>
> Dieses eine Promille aber zu optimieren, womöglich auf Kosten der
> Sicherheit und des Komforts, ist wenig hilfreich.


bwahahaha. Das ist Unsinn und trifft nur zu, wenn du wenig Load hast. Das Problem "x Anfragen pro Sekunde" schafft der Webserver, ist eines der größten Probleme für größere Websites - und liegt noch VOR der Applikation. Was bringt dir dein "99% der Zeit geht bei der App drauf", wenn die Anfrage vom Webserver nicht mehr zügig oder gar nicht abgearbeitet wird? Eben. Nix. *rolleyes*

[proprietäres protokoll]

Vielleicht meint er folgendes:

Web Sockets statt XMLHttpRequest
Eine bidirektionale Kommunikation zwischen Browser und Server sollen die sogenannten Web Sockets erlauben, die Google nun in einer Entwicklerversion von Chrome und Webkit integriert hat. Die Spezifikation der Web Sockets ist Teil des von der WHAT WG entwickelten Standardentwurfs Web Applications 1.0.
10.12.2009, Original-Link: http://www.golem.de/0912/71783.html


Ihr redet von Formel-1-Autos (high-hit-Sites) und der tägliche Stau auf den Normalo-Sites interessiert Euch nicht.
Miese ineffiziente PHP-Systeme oder die Nachfolger und Nachfolgeprogger von formmail.pl ...

Früher hat mein "Ex-Boss" immer Scripte "angeschleppt" und immer mehr Schnickschnack in die Seite eingebaut und die haben dann die Performance runtergezogen. "Danke".
Loads von 50-80 u.ä. gabs dann auch schon mal... .

Cache is King. Die SQL-Anfragen zu cachen (mysql konnte das damals noch nicht) hat 2/3 der Einfragen eingespart. Die Leute suchen ja doch oft nach denselben Dingen.
D.h. der SQL-Server hatte nur noch 1/3 zu arbeiten. Sowas rentiert auch.

Webserver oder Proxies die statischen Content wie die 100 Gifs, .css-Dateien und .js-Dateien pro geladener Webseite vorhalten und als .gz vorhalten, interessieren hier oft kaum jemanden.
Webseiten-Optimierung wird von der Mehrheit mit 5 Besuchern pro Tag nicht gebraucht.
Und echte high-hit-Profis reden normalerweise nicht.

Und wegen der WebKonfiguration:
Und Config-Files sind in csv oder ini oder xml oder ähnlich einfache Formate. Frontends sind für kleine Änderungen ok. Aber ich will meine COnfigs kommentieren können.
Und Overlaying macht ja keiner: standard-config und danach überlädt man Einträge mit anderen Dateien die mit dem web-frontend erzeugt wurden. Das kennt man doch von .openssh und eigentlich allen Systemen die /etc/foobar/... laden und dann mit $HOME/.foobar/... überladen.
Dann kann man auch mal einzelne Änderungen auf 100 verschiedene Kundenserver uppen.
Oder man hält die Configs zentral und verteilt die bei Bedarf an Änderungen. Dafür sollte das Config-Tool dann halt unabhängig von einem echten Cherokee benutzbar sein.
Trotzdem wäre es besser, wenn man AUCH immer per Hand editieren kann. sendmail.cf ist halt KEIN Vorbild.

[titrat]

fsadfsafasfasfasfsa schrieb:
--------------------------------------------------------------------------------

> > Dieses eine Promille aber zu optimieren, womöglich auf Kosten der
> > Sicherheit und des Komforts, ist wenig hilfreich.
>
> bwahahaha. Das ist Unsinn und trifft nur zu, wenn du wenig Load hast. Das
> Problem "x Anfragen pro Sekunde" schafft der Webserver, ist eines der
> größten Probleme für größere Websites - und liegt noch VOR der Applikation.
> Was bringt dir dein "99% der Zeit geht bei der App drauf", wenn die Anfrage
> vom Webserver nicht mehr zügig oder gar nicht abgearbeitet wird? Eben. Nix.
> *rolleyes*

99,99% der für einen Request benötigten Zeit gehen in Datenbank und Applikationen verloren, der eigentlich Webserver benötigt nur 0,01% der gesamten CPU-Zeit, die von Anfrage bis zur Auslieferung reicht.

Die PHP-Skripte und Datenbank etc. werden durch Cherokee sicher nicht beschleunigt. Das ist wie bei einem LKW alle Energie in die Gewichtsoptimierung des Handbremshebels zu stecken - anstelle Motor und andere Faktoren zu betrachten.