Hallo zusammen,
ich habe einen Cache für PHP-Seiten programmiert.
Demo: http://radn.de (mit osCommerce) oder http://auto-werkstatt.com (mit
eigenem Suchmaschinenscript)
Beides läuft mit viel zu kleinen Systemresourcen und wäre ohne Cache zu
langsam.
Wie findet Ihr die Geschwindigkeit?
Gruß
Thomas
..oO(Thomas Stoffregen)
>ich habe einen Cache für PHP-Seiten programmiert.
>Demo: http://radn.de (mit osCommerce) oder http://auto-werkstatt.com (mit
>eigenem Suchmaschinenscript)
>
>Beides läuft mit viel zu kleinen Systemresourcen und wäre ohne Cache zu
>langsam.
>
>Wie findet Ihr die Geschwindigkeit?
Also wenn die nicht-gecachten Seiten tatsächlich die normale Geschwin-
digkeit des Systems widerspiegeln, dann liegen Welten dazwischen. Was
ist das denn für eine lahme Kiste? Und ich dachte schon, meine Skripte
auf meinem lokalen Serverchen (P3@550 MHz, 192 MB) wären langsam ...
Wie willst Du aber auf der Shop-Seite den Cache mit dem Warenkorb
verbinden? Sobald etwas im Warenkorb ist, kannst Du keine gecachten
Seiten mehr ausliefern bzw. müßtest diese vor der Auslieferung noch
modifizieren.
Micha
Thomas Stoffregen schrieb:
> Hallo zusammen,
>
> ich habe einen Cache für PHP-Seiten programmiert.
Es gibt im PEAR Cache und CacheLite.
> Demo: http://radn.de (mit osCommerce) oder http://auto-werkstatt.com (mit
> eigenem Suchmaschinenscript)
>
> Beides läuft mit viel zu kleinen Systemresourcen und wäre ohne Cache zu
> langsam.
Warning:
file_get_contents(http://radn.de/dwshop/default.php?cPath=38 2&noc=2):
failed to open stream: HTTP request failed!
Wir holen uns obwohl auf dem richtigen Server? den Content ueber einen
HTTP Request?
> Wie findet Ihr die Geschwindigkeit?
Da tauchen mehr Fehlermeldungen auf als alles andere.
Gruss
Joerg
--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de
Hallo Micha,
> Also wenn die nicht-gecachten Seiten tatsächlich die normale Geschwin-
> digkeit des Systems widerspiegeln, dann liegen Welten dazwischen.
Ja, das ist die Originalgeschwindigkeit.
> Wie willst Du aber auf der Shop-Seite den Cache mit dem Warenkorb
> verbinden? Sobald etwas im Warenkorb ist, kannst Du keine gecachten
> Seiten mehr ausliefern bzw. müßtest diese vor der Auslieferung noch
> modifizieren.
Der nächste Schritt ist, nur einzelne Tabelleninhalte zu cachen.
Mit Warenkorb kann ich natürlich nicht die komlette Seite cachen.
Gruß
Thomas
Hallo Joerg,
> Es gibt im PEAR Cache und CacheLite.
wenn es danach geht bräuchte man nicht mehr zu programmieren.
Bei Beiden muss aber ins System eingegriffen werden.
auto-werkstatt liegt auf einem 1,- Euro-Webspace. Glaubst Du der Provider
installiert da Extrawünsche?
> > Beides läuft mit viel zu kleinen Systemresourcen und wäre ohne Cache zu
> > langsam.
> Warning:
> file_get_contents(http://radn.de/dwshop/default.php?cPath=38 2&noc=2):
> failed to open stream: HTTP request failed!
Ja, leider passiert das wenn zuviele eine Suche starten. Zum zweiten wird
der Cache gerade aufgebaut und das zieht den Server doch etwas in die Knie.
es sind immerhin über 10.000 Seiten zu cachen.
> Wir holen uns obwohl auf dem richtigen Server? den Content ueber einen
> HTTP Request?
Ja, so kann der Cache auch ausserhalb des gecachten Webspace liegen.
Frag mich nicht nach dem Sinn. :-)
Evtl. Cache als Serviceleistung.
Da sind mit Sicherheit noch einige Dinge drin die verbessert werden müssen.
Spätestens mit dem cachen von Funktionen/Tabellen geht das so sowiso nicht
mehr.
> > Wie findet Ihr die Geschwindigkeit?
> Da tauchen mehr Fehlermeldungen auf als alles andere.
Die würden auch auftauchen wenn 5 Leute gleichzeitig eine Suche starten. Der
Server ist für sowas hoffnungslos überlastet.
Ich habe nur einen kleinen Stratoserver. Für mich reicht er. Zumindest zur
Zeit.
Und zur Demonstration des Caches optimal.
Gruß
Thomas
Thomas Stoffregen schrieb:
> Hallo Joerg,
>
>> Es gibt im PEAR Cache und CacheLite.
> wenn es danach geht bräuchte man nicht mehr zu programmieren.
>
> Bei Beiden muss aber ins System eingegriffen werden.
> auto-werkstatt liegt auf einem 1,- Euro-Webspace. Glaubst Du der Provider
> installiert da Extrawünsche?
PEAR Sachen sind genau so PHP Scripte wie deine und kommen somit auf dem
gleichen Wege auf den Server wie deine.
Gruss
Joerg
--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de
Naja: Auf: http://www.zdnet.de/builder/program/0,39023551,39121387,00.h tm
gefunden:
-------------------------
Für eine Installation von PEAR-Bibliotheken auf der Shared Hosting Site des
Internet-Providers sollte nicht unerwähnt bleiben, dass die meisten der
Shared Hosting Provider, die ihren Kunden PHP nicht zur Verfügung stellen,
auch den Einsatz von PEAR nicht erlauben.
Einschränkungen von Shared Hosts
Normalerweise erfordert die Installation von Ressourcenbibliotheken einen
Hauptbenutzer-, Administrator- oder anderen bevorzugten Berechtigungsstatus.
Shared Hosting Provider sind ganz besonders vorsichtig, wenn es um die
Installation von Bibliotheken geht, denn ein einziger Fehler kann eine ganze
Webfarm zum Erliegen bringen.
------------
Also im Klartext: Normalerweise Root, mindestens aber Shellzugang ist
erforderlich.
Bei meinem Cache werden lediglich ein Verzeichnis mit Schreibrecht für den
Webserver angelegt und zwei PHP-Scripte kopiert.
Danach muß nur eine Configdateien angepasst werden in der die zu cachenden
Querystrings stehen.
Die Einbindung läuft über eine Zeile am Anfang des zu cachenden Scripts:
include("./mycache.php");
Daher habe ich auch die Seite vom eigenen Webspace, per HTTP-Request, in den
Cache geladen.
Sonst hätte ich mindestens zwei Eingriffe in das zu cachende Script machen
müßen.
Eine Seite neu in den Cache laden geht über http://url&noc=1
Der Cache von Pear ist mit Sicherheit besser als meiner.
Die Idee zu diesem Cache hatte ich vor vier Tagen. Wie alt ist der von Pear
und wieviele Leute haben da schon verbessert?
Aber wie will der Pearcache wissen, was ich cachen will und was nicht?
Übrigens ist der Aufbau den Caches vom Shop in den letzten Zügen. Dann
dürften keine Fehler mehr auftreten. Sofern die Seiten aus den Cache kommen.
Die Artikelsuche wird auch gecacht.
Bei über 10.000 gecachten Seiten sind ca. 30 Seiten mit einen Servererror
kaputt gegangen.
Ich finde, daß geht für den Anfang.
Gruß
Thomas
Thomas Stoffregen schrieb:
> Naja: Auf: http://www.zdnet.de/builder/program/0,39023551,39121387,00.h =
tm
> gefunden:
> -------------------------
> Für eine Installation von PEAR-Bibliotheken auf der Shared Hosting Si=
te des
> Internet-Providers sollte nicht unerwähnt bleiben, dass die meisten d=
er
> Shared Hosting Provider, die ihren Kunden PHP nicht zur Verfügung ste=
llen,
> auch den Einsatz von PEAR nicht erlauben.
> Einschränkungen von Shared Hosts
> Normalerweise erfordert die Installation von Ressourcenbibliotheken ein=
en
> Hauptbenutzer-, Administrator- oder anderen bevorzugten Berechtigungsst=
atus.
> Shared Hosting Provider sind ganz besonders vorsichtig, wenn es um die
> Installation von Bibliotheken geht, denn ein einziger Fehler kann eine =
ganze
> Webfarm zum Erliegen bringen.
> ------------
> Also im Klartext: Normalerweise Root, mindestens aber Shellzugang ist
> erforderlich.
Der Passus ist Blödsinn sofern es sich nicht um PECL-Erweiterungen
handelt. Ein Verzeichnis namens PEAR anlegen, Skripte rein -- fertig.
Im schlimmsten Fall (wenn man den Include-Pfad nicht anpassen kann und
man kein eigenes Include-Verzeichnis zur Verfügung hat) kann es
vorkommen, dass man Pfade zum Nachladen weiterer Skripts anpassen muss.
Im deinem Falle reicht es für Cache(Lite), die Dateien PEAR.php,
Cache.php sowie das Verzeichnis Cache auf deinen Webspace zu bringen.
> Aber wie will der Pearcache wissen, was ich cachen will und was nicht?
Lies die Dokumentation. CacheLite chached zB. die Ausgabe von Funktionen
in Abhängigkeit ihrer Argumente.
MfG
Niels
--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------
Thomas Stoffregen wrote:
Hallo,
> Naja: Auf: http://www.zdnet.de/builder/program/0,39023551,39121387,00=
..htm
> gefunden:
> -------------------------
> Für eine Installation von PEAR-Bibliotheken auf der Shared Hosting =
Site
> des Internet-Providers sollte nicht unerwähnt bleiben, dass die mei=
sten
> der Shared Hosting Provider, die ihren Kunden PHP nicht zur Verfügu=
ng
> stellen, auch den Einsatz von PEAR nicht erlauben.
> ------------
> Also im Klartext: Normalerweise Root, mindestens aber Shellzugang ist=
> erforderlich.
Nein, ist es nicht. Wenn man beliebige PHP-Skripts auf den eigenen Web=
space
installieren kann, dann kann man auch PEAR-Klassen installieren, da es=
PHP-Skripts/Klassen sind. Das geht über ein Web-Interface, von der
Shell aus, per PEAR_RemoteInstaller via FTP, einer gtk-GUI oder auch d=
irekt
per eigenen Auspacken und Upload per FTP. Letzteres eventuell mit etwa=
s
zusätzlichen Basteln, je nach PEAR-Klasse. Hilfreich ist es, wenn da=
s
Grundsystem schon vorhanden ist und wenn man den PHP include_path erwe=
itern
kann, z.B. per .htaccess. Ansonsten muss man ihn notfalls zur Laufzeit=
passend mit Hilfe von ini_set() setzen.
=20
Siehe PEAR-Handbuch
http://pear.php.net/manual/de/installation.php
tschuess
[|8:)