-
PHP auf dem Weg zum Application-Server
Autor: Golem.de 12.02.02 - 09:59
Ein Entwicklerteam um Derick Rethans hat jetzt eine erste Beta-Version der Vulcan Logic Script Running Magic (SRM) 0.6 für PHP veröffentlicht. Damit wird es möglich, einige der für Scriptsprachen typischen Probleme zu umgehen, die das verbindungslose HTTP-Protokoll mit sich bringt. Verschiedene Instanzen eines Scripts können so auf die gleichen Variablen, Objekte und Datenbankverbindungen zugreifen.
https://www.golem.de/0202/18233.html
-
Re: PHP auf dem Weg zum Application-Server
Autor: ingolf 12.02.02 - 12:11
an Autor:
bitte bei dem Link ein "/" löschen...
CU Ingolf -
Re: PHP auf dem Weg zum Application-Server
Autor: kaja 12.02.02 - 12:56
Die Homepage von SRM sagt aber auch, das SRM im Remotemodus sehr viel langsamer ist... :/
-
Re: Remote-Modus langsam
Autor: Geek 12.02.02 - 13:59
kaja schrieb:
> Die Homepage von SRM sagt aber auch, das SRM im
> Remotemodus sehr viel langsamer ist... :/
Ja, aber das liegt ja nicht an SRM, sondern an den verwendeten Sockets. Und eine Verbindung zu einem anderen Rechner ist nunmal etwas mehr Aufwand als lokal. Das gilt auch für andere Applikationen.
Schau mal beispielsweise ins MySQL-Handbuch, da steht das Gleiche. Allein durch die verwendung von TCP/IP sinkt die Performance um ein paar wenige Prozent.
Doch das kann man sicherlich verscherzen, denn die Architektur erlaubt dann ja ien Problemlose Lastverteilung seitens der Front-End-Server und ist noch immer schneller als wenn man so etwas über einen DB-Server abwickeln würde. -
Re: PHP auf dem Weg zum Application-Server
Autor: Derick Rethans 12.02.02 - 14:18
(Sorry to answer in English, but writing German is too hard for me :)
The problem with TCP/IP sockets is that they are much slower than UNIX domain sockets, there is little we can do about that. But we are going to rewrite the network layer anyways, and will pay attention to the performance of socket communication when we do this.
regards,
Derick -
Re: PHP auf dem Weg zum Application-Server
Autor: Jenny 12.02.02 - 16:53
Ähmm...
Ein Application Server ist VIEL mehr als nur eine Ansammlung von Variablen. PHP ist eine simple Scriptsprache, mehr nicht.
Wenn Application weite Variablen schon ausreichen um eine Script Sprache zum Application Server zu veredeln, dann ist ASP seit Version 1.0 (anno 1997) ein Application Server, denn bei ASP sind Application Scope Variablen und Objekte schon immer dabei gewesen.
Ein simples Application("variablenname") = "Wert" reicht schon völlig aus. Ohne Socket Probleme, ohne extra DLL, ohne sonstwas.
Wiedermal ein Fall wo sich PHP grossartig hervorstellt und mit unglaublicher Kraftanstrengung was bastelt, was anderswo nur noch gähnen auslösst...
Jenny -
Re: PHP auf dem Weg zum Application-Server
Autor: Derick Rethans 12.02.02 - 19:22
Hello Jenny,
sorry to write in English, although I can read German just fine, writing is anoter sport.
Jenny schrieb:
>
> Ähmm...
>
> Ein Application Server ist VIEL mehr als nur
> eine Ansammlung von Variablen. PHP ist eine
> simple Scriptsprache, mehr nicht.
>
> Wenn Application weite Variablen schon
> ausreichen um eine Script Sprache zum
> Application Server zu veredeln, dann ist ASP
> seit Version 1.0 (anno 1997) ein Application
> Server, denn bei ASP sind Application Scope
> Variablen und Objekte schon immer dabei gewesen.
>
> Ein simples Application("variablenname") =
> "Wert" reicht schon völlig aus. Ohne Socket
> Probleme, ohne extra DLL, ohne sonstwas.
erm, from where did you get that SRM (or an
Application server) only a collection of variables
is? The article, and also the SRM homepage, show
much more possibilities as only persistent (or
applicationlevel) variables. I'd recommend that you
read the following URL, which describes SRM's
feature: http://www.vl-srm.net/doc/user.features.php
If you ahve any further questions, feel free to mail
the SRM mailinglist ( http://www.vl-srm.net/doc/support.php#support.free )
regards,
Derick -
Re: PHP auf dem Weg zum Application-Server
Autor: Markus Brüderl 13.02.02 - 07:52
Na ja, fragt sich nur was der standard-PHP Nutzer davon haben wird...
..ich denke kaum jemand, der PHP bisher benutzt wird in die Lage versetzt werden, einen Application Server nutzen zu dürfen, da ja kaum auf die neueren PHP Versionen auf den Webservern aktualisiert wird.
Und eine Firma, die sich einen vernünftigen Server leisten kann wird wiederum nicht PHP verwenden...
...hauptsache PHP bleibt das was es bisher war....eine einfache, weit verbreitete serverseitige Skriptsprache, die jeder schnell anwenden kann... -
Re: PHP auf dem Weg zum Application-Server
Autor: Björn Schotte 13.02.02 - 09:31
Jenny schrieb:
> Ein Application Server ist VIEL mehr als nur
> eine Ansammlung von Variablen.
Stimmt. Aber vielleicht magst du uns noch erzählen, was denn nun genau einen Application Server ausmacht? Immer dann, wenn ich mit Managern oder IT-Entscheidern spreche, haben diese zum einen Schwierigkeiten, den Begriff "ApplicationServer" genau zu definieren, und zum anderen kommt es oft vor, dass sich die Vorstellungen, was denn nun ein ApplicationServer genau können soll, sehr stark unterscheiden.
Um Aufklärung dankbar, Björn.
PS: es hülfe eventuell auch, sich der Bedeutung von "etwas ist *auf dem Weg* zum ..." bewußt zu werden. -
Re: PHP auf dem Weg zum Application-Server
Autor: Lee 13.02.02 - 11:12
Ein Applikation Server ist im Grunde ein Container für persistente Objekte bzw. Programme.
In sofern kann man schon SRM als Applikation Server bezeichnen. Eben so wie Zope, Midgard.
Ein echter Applikation Server bietet aber ein komplettes Framework wie beans, object caching, O/R Mapping, load balancing, Session management,....
Und noch was: HTTP hat auf einem Applikation Server nichts zu suchen. -
Re: PHP auf dem Weg zum Application-Server
Autor: Jenny 14.02.02 - 14:58
Da wär ich vorsichtig !
Der ATG Dynamo (im Gegensatz zu PHP ein echter Application Server) hat nen HTTP Demon intigriert und ist zweifelsohne auf professionellem Level.
Jenny -
Re: PHP auf dem Weg zum Application-Server
Autor: korrekteur 22.10.05 - 13:14
ingolf schrieb:
> bitte bei dem Link ein "/" löschen...
Wieso? Stimmt doch so: http://foo.bar/
Ein / kommt immer ans Ende wenn keine Datei am Ende steht.