Hallo,
1und1 unterstützt SQLite nicht, zumindest, wenn man phpinfo() aufruft,
steht darin unter 'Command' '--without-sqlite'.
Gibt es nun doch noch eine Möglichkeit SQLite zu nutzen und wie
installiere ich das dann auf meinem shred host?
Hi,
ich denke mal wenn das nicht mit eincompiliert ist dann hast Du
schlechte Karten.
Frag doch mal bei 1&1 warum das nicht mit drin ist und ob die das nicht
noch liefern können.
-Kirsten
Kirsten wrote:
> Frag doch mal bei 1&1 warum das nicht mit drin ist und ob die das nicht=
> noch liefern können.
Vermutung: sie wollen DB-Last und Daten nicht direkt der CPU und
dem Filesystem der Webserver aufbürden sondern auf dedizierten
Datenbankservern halten damit insb. die shared Webserver das machen
können wofür sie eigentlich da sind: Webseiten ausliefern?
--=20
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com
Hartmut Holzgraefe schrieb:
> Kirsten wrote:
>
>> Frag doch mal bei 1&1 warum das nicht mit drin ist und ob die das nicht
>> noch liefern können.
>
>
> Vermutung: sie wollen DB-Last und Daten nicht direkt der CPU und
> dem Filesystem der Webserver aufbürden sondern auf dedizierten
> Datenbankservern halten damit insb. die shared Webserver das machen
> können wofür sie eigentlich da sind: Webseiten ausliefern?
>
Ja und nein. Ich habe nur eine kleine Datenbank, in die online nichts
geschrieben werden muss, sondern die lediglich durch ein php-Skript
ausgelesen wird, damit die Seiten-Navigation richtig funktioniert. Dafür
erscheint mir SQLite wie geschaffen.
Allerdings sieht das "1&1" vollkommen anders. Eine Antwort auf die
Frage, warum SQLite nicht freigeschaltet wurde, lautet: "...wir
betreiben von unseren Webservern getrennte MySQL-Server um die
Antwortszeit von Webseiten mit Skript/SQL-Anfragen zu beschleunigen und
die Server zu entlasten. Wenn man nun SQLite verwenden würde würde die
gesamte Last auf den Webserver fallen und so diesen Vorteil aufheben..."
Nun bleibt mir wohl doch nichts weiter übrig, als mit MySQL arbeiten zu
müssen, obwohl mir das wie mit Kanonen auf Spatzen schießen erscheint.
969 <969@gmx.de> wrote:
> Hartmut Holzgraefe schrieb:
>>
>> Vermutung: sie wollen DB-Last und Daten nicht direkt der CPU und
>> dem Filesystem der Webserver aufbürden sondern auf dedizierten
>> Datenbankservern halten damit insb. die shared Webserver das machen
>> können wofür sie eigentlich da sind: Webseiten ausliefern?
>>
> Ja und nein. Ich habe nur eine kleine Datenbank, in die online nichts
> geschrieben werden muss, sondern die lediglich durch ein php-Skript
> ausgelesen wird, damit die Seiten-Navigation richtig funktioniert. Dafür
> erscheint mir SQLite wie geschaffen.
Mir überhaupt nicht. Navigationselemente genauso wie Bilder und Content
sind *statisch*. Damit ist eine Datenbank zur Speicherung dieser
Objekte vollkommener Overkill. In die Datenbank gehören IMNSHO nur
wirklich dynamische Daten, also z.B. solche, die sich von Seitenaufruf
zu Seitenaufruf ändern.
Design-Sachen kommen am besten in CSS, Navigation macht man man z.B.
mit SSI. Wenn man schon PHP verwendet, tuts auch "include()".
Das Optimum holt man mit einem Offline-Templating-System heraus, wie
z.B. WML - www.thewml.org (nicht zu verwechseln mit WML für wireless).
XL
Axel Schwenke schrieb:
> Mir überhaupt nicht. Navigationselemente genauso wie Bilder und Content
> sind *statisch*.
Seltsame Ansicht. Wie kommst Du auf die Idee, dass die Navigation einer Webseite
und deren Content statische Inhalte seien? Das *kann* der Fall sein, muss aber
nicht. (Achso, Bilder können natürlich auch dynamisch erzeugt werden, bspw bei
Infografiken wie Charts etc)
> Damit ist eine Datenbank zur Speicherung dieser
> Objekte vollkommener Overkill. In die Datenbank gehören IMNSHO nur
> wirklich dynamische Daten, also z.B. solche, die sich von Seitenaufruf
> zu Seitenaufruf ändern.
Was verstehst Du denn überhaupt unter dynamisch und statisch? Wirklich
dynamische Daten, die sich von Seite zu Seite unterscheiden kommen in der Regel
nicht aus der DB, sondern werden on-the-fly im Skript generiert. Für die von Dir
beschriebene Form der Dynamik wäre doch eine DB overkill - einmalig benötigte
Daten werden in einer Datenbank gespeichert?
> Design-Sachen kommen am besten in CSS, Navigation macht man man z.B.
> mit SSI. Wenn man schon PHP verwendet, tuts auch "include()".
Aber nur, wenn es sich auch wirklich um eine statische Navigation handelt.
> Das Optimum holt man mit einem Offline-Templating-System heraus, wie
> z.B. WML - www.thewml.org (nicht zu verwechseln mit WML für wireless).
Ist doch alles irgendwie extrem stark vereinfacht... Es gibt zwar durchaus
Fälle, in denen das das sinnvollere Vorgehen wäre - aber ebene auch unzählige
Fälle, in denen das beschriebene Vorgehen der vielfache overkill wäre.
Ansonsten denke ich mal, dass der Provider sich schon was dabei gedacht hat,
SQLLite nicht zur Verfügung zu stellen, immerhin will er ja für etwas Extrageld
ein größeres Paket mit MySQL verkaufen.
Martin Kurz
> Axel Schwenke schrieb:
>> Navigationselemente genauso wie Bilder und Content
>> sind *statisch*.
>
> Seltsame Ansicht. Wie kommst Du auf die Idee, dass die Navigation einer Webseite
> und deren Content statische Inhalte seien? Das *kann* der Fall sein, muss aber
> nicht.
Irgendwie scheinst du seltsame Ansichten darüber zu haben, was statisch
und was dynamisch ist. Mal abgesehen von Sonderfällen wie Boards, Blogs
und Gästebüchern ist der Inhalt von Webseiten statisch. D.h. er ändert
sich nicht ohne Zutun des Autors.
Die Navigation gar (um Mißverständnisse auszuschließen: die typischen
Menüs und Buttons "Meine Hobbys", "Mein Haustier" etc.) ist vollends
statisch. Selbst wenn der Autor einer Website jeden Tag Änderungen auf
Seiten macht und Seiten hinzufügt oder löscht - die Navigation sollte
bis auf offensichtliche Fälle von neuen oder gelöschten Teilen so
bleiben wie sie ist. Oder möchtest du auf einer Website jeden Tag
suchen, wo sich denn der Link auf eine bestimmte Unterseite heute
versteckt?
>> In die Datenbank gehören IMNSHO nur
>> wirklich dynamische Daten, also z.B. solche, die sich von Seitenaufruf
>> zu Seitenaufruf ändern.
>
> Wirklich
> dynamische Daten, die sich von Seite zu Seite unterscheiden
Nicht "von Seite zu Seite", sondern "von Seitenaufruf zu Seitenaufruf".
Kleiner aber feiner Unterschied.
Wenn zwei Anwender die selbe Seite anschauen und es sollen bestimmte
Dinge verschieden sein; oder wenn eine Seite an bestimmten Stellen
heute abend etwas anderes zeigen soll als morgen früh - dann sind das
dynamische Daten. Und wenn die nicht algorithmisch erzeugt werden
können (wie z.B. "Guten Abend" oder "Guten Morgen" anhand der Uhrzeit)
dann *können* diese Daten aus einer Datenbank stammen. Der Rest drum
herum - in der Regel 50-90% der Seite - sind dennoch statisch.
> kommen in der Regel
> nicht aus der DB, sondern werden on-the-fly im Skript generiert.
Ah ja. Und woher bekommen die Skripte die Daten, aus denen sie eine
HTML-Seite rendern? Vielleicht aus der Datenbank? Und BTW - sind die
Skripte selber eigentlich statisch oder dynamisch? (fgngvfpu)
>> Design-Sachen kommen am besten in CSS, Navigation macht man man z.B.
>> mit SSI. Wenn man schon PHP verwendet, tuts auch "include()".
>> Das Optimum holt man mit einem Offline-Templating-System heraus, wie
>> z.B. WML - www.thewml.org (nicht zu verwechseln mit WML für wireless).
>
> Ist doch alles irgendwie extrem stark vereinfacht...
Kann es sein, daß du noch nie mit einer Website von nennenswertem
Umfang oder mit nennenswert vielen Zugriffen zu tun hattest?
Ich war mal Admin für eine Site mit >1000 Contentseiten und 2 Mio.
Seitenabrufen am Tag. Da lernt man, was funktioniert und was nicht.
Klar, der Taubenzüchterverein in Hintertupfingen braucht keine
besonders skalierbare Website. Da reicht dann auch ein CPU-fressendes
nichtskalierendes Monster wie Mambo oder Typo3, das jedes Fetzelchen
Content bei jedem Zugriff aus der Datenbank klaubt.
Aber bloß weil schlechtes Design manchmal nicht gleich auffällt,
muß man das noch lange nicht als den einzig wahren Weg darstellen.
XL
Axel Schwenke schrieb:
> Martin Kurz
>
>>Axel Schwenke schrieb:
>
>
>>>Navigationselemente genauso wie Bilder und Content
>>>sind *statisch*.
>>
>>Seltsame Ansicht. Wie kommst Du auf die Idee, dass die Navigation einer Webseite
>>und deren Content statische Inhalte seien? Das *kann* der Fall sein, muss aber
>>nicht.
>
>
> Irgendwie scheinst du seltsame Ansichten darüber zu haben, was statisch
> und was dynamisch ist. Mal abgesehen von Sonderfällen wie Boards, Blogs
> und Gästebüchern ist der Inhalt von Webseiten statisch. D.h. er ändert
> sich nicht ohne Zutun des Autors.
>
> Die Navigation gar (um Mißverständnisse auszuschließen: die typischen
> Menüs und Buttons "Meine Hobbys", "Mein Haustier" etc.) ist vollends
> statisch. Selbst wenn der Autor einer Website jeden Tag Änderungen auf
> Seiten macht und Seiten hinzufügt oder löscht - die Navigation sollte
> bis auf offensichtliche Fälle von neuen oder gelöschten Teilen so
> bleiben wie sie ist. Oder möchtest du auf einer Website jeden Tag
> suchen, wo sich denn der Link auf eine bestimmte Unterseite heute
> versteckt?
Nunja, ich spreche von Seiten mit mehr als einem Autor, eher mit mehreren
hundert Autoren. Inwiefern sich der Aufwand eines CMS (oder sonstiger
Programmierung) bei Seiten mit nur einem Autor lohnt, sei mal dahingestellt
(IMHO garnicht).
>>>In die Datenbank gehören IMNSHO nur
>>>wirklich dynamische Daten, also z.B. solche, die sich von Seitenaufruf
>>>zu Seitenaufruf ändern.
>>
>>Wirklich
>>dynamische Daten, die sich von Seite zu Seite unterscheiden
>
>
> Nicht "von Seite zu Seite", sondern "von Seitenaufruf zu Seitenaufruf".
> Kleiner aber feiner Unterschied.
Stimmt natürlich, das meinte ich.
> Wenn zwei Anwender die selbe Seite anschauen und es sollen bestimmte
> Dinge verschieden sein; oder wenn eine Seite an bestimmten Stellen
> heute abend etwas anderes zeigen soll als morgen früh - dann sind das
> dynamische Daten. Und wenn die nicht algorithmisch erzeugt werden
> können (wie z.B. "Guten Abend" oder "Guten Morgen" anhand der Uhrzeit)
> dann *können* diese Daten aus einer Datenbank stammen. Der Rest drum
> herum - in der Regel 50-90% der Seite - sind dennoch statisch.
Also in den Seiten, um die ich mich kümmere, nicht. Statisch ist das Basislayot,
also das Gerüst, in das die vielen verschiedenen Daten einlaufen. Alles andere,
wie Navigation wird generiert und eine kurze Zeit in der Anwendung gecached, da
es sich einfach zu oft ändert (und es einfach zu viele Versionen gäbe, um sie
statisch vorzugenerieren).
>>kommen in der Regel
>>nicht aus der DB, sondern werden on-the-fly im Skript generiert.
>
>
> Ah ja. Und woher bekommen die Skripte die Daten, aus denen sie eine
> HTML-Seite rendern? Vielleicht aus der Datenbank? Und BTW - sind die
> Skripte selber eigentlich statisch oder dynamisch? (fgngvfpu)
Natürlich statisch - geht zwar auch anders, dann wird aber die Fehlersuche doch
unnötig kompliziert :)
>>>Design-Sachen kommen am besten in CSS, Navigation macht man man z.B.
>>>mit SSI. Wenn man schon PHP verwendet, tuts auch "include()".
>>>Das Optimum holt man mit einem Offline-Templating-System heraus, wie
>>>z.B. WML - www.thewml.org (nicht zu verwechseln mit WML für wireless).
>>
>>Ist doch alles irgendwie extrem stark vereinfacht...
>
>
> Kann es sein, daß du noch nie mit einer Website von nennenswertem
> Umfang oder mit nennenswert vielen Zugriffen zu tun hattest?
> Ich war mal Admin für eine Site mit >1000 Contentseiten und 2 Mio.
> Seitenabrufen am Tag. Da lernt man, was funktioniert und was nicht.
Sehe ich genauso - allerdings hatte ich bisher eher selten mit Seiten in so
kleinem Umfang zu tun, es sind eher mehrere Millionen Contentseiten (davon sind
allerdings nur ein paar hunderttausend wirklich in der Liveausspielung, der Rest
ist Archiv (wegen Presserecht) bzw vorbereitet und noch nicht live) mit vielen
Autoren und automatisierten Zulieferung, verschiedenen Zeitsteuerungen etc -
eine statische Generierung würde viel zu lange dauern und zu oft zu
inkonsistenten Eregbnissen führen (sprich, es wird eine Seite verlinkt, die
bereits veraltet ist, wenn die Generierung abgeschlossen und freigeschaltet ist
oder gar nicht mehr existiert). Teildaten werden allerdings auch vorgeneriert,
insbesondere Daten, deren Erstellung sehr aufwändig ist und die sich nur zu
definierten Zeitpunkten ändern.
Achso, die Seitenabrufe bewegen sich bei bis zu 10 Millionen am Tag (Peaks bei
etwa 5000 PIs in der Sekunde), dabei kommen allerdings zum Cache der generierten
Teildaten in der Anwendung auch noch reverse-Caches vor den Servern, die die
generierten Seiten ein paar Minuten speichern (je nach System zwischen einer
Minute und 15 Minuten, je nach Anwendung über Akamai oder ein eigenes
Squid-Custer). Ich würde mal behaupten, dass ich da schon ungefähr weiß, von was
ich spreche ;o)
> Klar, der Taubenzüchterverein in Hintertupfingen braucht keine
> besonders skalierbare Website. Da reicht dann auch ein CPU-fressendes
> nichtskalierendes Monster wie Mambo oder Typo3, das jedes Fetzelchen
> Content bei jedem Zugriff aus der Datenbank klaubt.
Stimmt, deswegen verwenden wir da ja auch entsprechende Java-Anwendungen, die
auf mehreren Servern verteilt laufen. Typo3 hatten wir übrigens auch mal dafür
getestet: schönes System, nur leider etwas langsam.
> Aber bloß weil schlechtes Design manchmal nicht gleich auffällt,
> muß man das noch lange nicht als den einzig wahren Weg darstellen.
Stimmt auch - aber was Du beschrieben hast, ist einfach nicht der einzig wahre
Weg, als den Du ihn hingestellt hast. Ich habe nichts gegen statische
Generierung, im Gegenteil, in vielen Fällen macht sie Sinn - aber nicht
generell. Das ist der Punkt, um den es mir geht. Ich habe nicht behauptet, dass
der von mir beschriebene Fall die letzte Wahrheit darstellt, nur, dass es auch
andere Fälle als die von Dir beschriebenen gibt und mir Deine Darstellung zu
verallgemeinernd war. Darüber, dass ziemlich oft mit Kanonen auf Spatzen
geschossen wird, brauchen wir nicht zu diskutieren, da stimme ich Dir zu :o)
Grüße,
Martin
On Sun, 18 Sep 2005 00:05:46 +0200, Axel Schwenke wrote:
> Irgendwie scheinst du seltsame Ansichten darüber zu haben, was statisch
> und was dynamisch ist. Mal abgesehen von Sonderfällen wie Boards, Blogs
> und Gästebüchern ist der Inhalt von Webseiten statisch. D.h. er ändert
> sich nicht ohne Zutun des Autors.
>
> Die Navigation gar (um Mißverständnisse auszuschließen: die typischen
> Menüs und Buttons "Meine Hobbys", "Mein Haustier" etc.) ist vollends
> statisch. Selbst wenn der Autor einer Website jeden Tag Änderungen auf
> Seiten macht und Seiten hinzufügt oder löscht - die Navigation sollte
> bis auf offensichtliche Fälle von neuen oder gelöschten Teilen so
> bleiben wie sie ist. Oder möchtest du auf einer Website jeden Tag
> suchen, wo sich denn der Link auf eine bestimmte Unterseite heute
> versteckt?
Navigation ist oft deshalb dynamisch, weil es Zugriffsrechte gibt. D.h.
wenn man die DB abfragt, ob der Nutzer bestimmte Seiten sehen darf, ist es
sinnvoll, sich das Menu, über das er navigiert, aus DB-Einträgen
zusammenzubauen. Und da muss sich nicht der Inhalt der Seiten ändern,
sondern bloss neue Nutzer angelegt bzw. deren Rechte geändert werden,
damit unterschiedliche Menues gebraucht werden.
Natürlich stehen dann nicht die
entsprechenden Bilder oder Seitenquelltexte in der DB, sondern nur die
Verweise. Aber anderes hatte der namensunterversorgte OP auch nicht
geschrieben.
Gruß Jürgen
Am 18.09.2005 00:05 schrieb Axel Schwenke...
> Martin Kurz
>
>>Axel Schwenke schrieb:
>
>
>>>Navigationselemente genauso wie Bilder und Content
>>>sind *statisch*.
>>
Datenbanken sind rubuste gefährten. Ich glaub mit Kanonen auf Spatzen
schiessen ist das nur bedingt. Ein dickes CMS macht natürlich sehr viele
Abfragen - aber ob SQLLite oder mySQL - ein paar selects - davon geht
nix in die Knie. Gerade mySQL hat doch als oberstes Prinzip
Geschwindigkeit. Es gab auch schon Systeme, die als Systemphilosophie
hatten, alles in der OLTP Datenbank abzuspeichern - inkl. Grafiken -
sämtlicher Content. - Also komplett eigene serverseitige Sprachen wie
PowerDynamo.
Viele Grüße,
Alexander
A. Kutz wrote:
>>>Axel Schwenke schrieb:
>>>>Navigationselemente genauso wie Bilder und Content
>>>>sind *statisch*.
> Datenbanken sind rubuste gefährten. Ich glaub mit Kanonen auf Spatzen
> schiessen ist das nur bedingt. Ein dickes CMS macht natürlich sehr viele
> Abfragen - aber ob SQLLite oder mySQL - ein paar selects - davon geht
> nix in die Knie.
Ja, genau du bist die Zielgruppe für meine Predigt. "Datenbanken sind
schnell!" - "Was meinst du mit 'skaliert nicht'?" - "Wenn es langsam
wird, nehmen wir eben schnellere Hardware!"
Du glaubst gar nicht, wie mir diese Sprüche und die daraus sprechende
Ignoranz auf den Sack gehen. Rechenleistung ist viel zu billig. Kein
Schwein kümmert sich mehr darum,mit Ressourcen sparsam umzugehen...
XL
Martin Kurz wrote:
> Axel Schwenke schrieb:
>>Die Navigation gar (um Mißverständnisse auszuschließen: die typischen
>>Menüs und Buttons "Meine Hobbys", "Mein Haustier" etc.) ist vollends
>>statisch. Selbst wenn der Autor einer Website jeden Tag Änderungen auf
>>Seiten macht und Seiten hinzufügt oder löscht - die Navigation sollte
>>bis auf offensichtliche Fälle von neuen oder gelöschten Teilen so
>>bleiben wie sie ist.
>
> Nunja, ich spreche von Seiten mit mehr als einem Autor, eher mit mehreren
> hundert Autoren.
Ob einer oder hundert spielt hier keine Rolle. Aber klar, wenn hundert
Autoren am Werke sind, werden viel öfter neue Seiten erscheinen (und
dafür andere verschwinden). Und sicherlich werden Links auf neue Seiten
erscheinen und Links auf alte Seiten verschwinden. Dennoch sind diese
Links (als Teil dessen was wir "Navigation" nennen wollen) trotzdem noch
statisch. Sie haben vielleicht eine arg begrenzte Lebensdauer. Aber sie
ändern sich über ihre Lebensdauer nicht. Vielleicht ist das sogar das
beste Kriterium für 'statisch" vs. 'dynamisch'
> Statisch ist das Basislayot,
> also das Gerüst, in das die vielen verschiedenen Daten einlaufen. Alles andere,
> wie Navigation wird generiert und eine kurze Zeit in der Anwendung gecached, da
> es sich einfach zu oft ändert (und es einfach zu viele Versionen gäbe, um sie
> statisch vorzugenerieren).ziemlich weit von dem entfernt, was man typischerweise auf
Irgendwie habe ich den Verdacht, das du mit "Navigation" etwas völlig
anderes meinst als ich. Wenn ich beispielsweise beim Heiseticker in die
7-Tage-Ansicht gehe, dann ist das für micht keine Navigation, sondern
eine Webanwendung die mir eine spezielle Ansicht auf einen dynamischen
Datenbestand zeigt.
>>Ich war mal Admin für eine Site mit >1000 Contentseiten und 2 Mio.
>>Seitenabrufen am Tag. Da lernt man, was funktioniert und was nicht.
>
> Sehe ich genauso - allerdings hatte ich bisher eher selten mit Seiten in so
> kleinem Umfang zu tun, es sind eher mehrere Millionen Contentseiten (davon sind
> allerdings nur ein paar hunderttausend wirklich in der Liveausspielung
....
> Achso, die Seitenabrufe bewegen sich bei bis zu 10 Millionen am Tag
OK, den 'dick size war' hast du gewonnen ;-)
Aber jetzt bin ich neugierig: 10 Mio/d extrapolieren auf 300 Mio/Monat.
Soviel hat Spiegel Online. Und in der Region wird die Luft schon sehr
dünn (zumindest listet die IVW nur noch eine handvoll Angebote dieser
Größenordnung). Außerdem fällt auf, das die Angebote dieser Größe alle
irgendwelche Nachrichtendienste oder Zeitungen sind.
> was Du beschrieben hast, ist einfach nicht der einzig wahre
> Weg, als den Du ihn hingestellt hast. Ich habe nichts gegen statische
> Generierung, im Gegenteil, in vielen Fällen macht sie Sinn - aber nicht
> generell. Das ist der Punkt, um den es mir geht.
Klar doch. Generell beste Lösungen gibt es nicht. Nur irgendwie ist
deine Anwendung ziemlich weit von dem entfernt, was man typischerweise
auf einem Webserver beim Massenhoster macht. Vermutlich kann man das,
was der OP vor hat, gar nicht zu bloatig aufsetzen. Bei 100
Seitenabrufen pro Tag langweilt sich auch der langsamste Webserver zu
Tode. Aber warum soll man den Leuten nicht beibringen, wie man es
richtig macht - vielleicht brauchen sie es ja später mal.
XL
Axel Schwenke schrieb:
> Martin Kurz wrote:
>
>
> Ob einer oder hundert spielt hier keine Rolle. Aber klar, wenn hundert
> Autoren am Werke sind, werden viel öfter neue Seiten erscheinen (und
> dafür andere verschwinden). Und sicherlich werden Links auf neue Seiten
> erscheinen und Links auf alte Seiten verschwinden. Dennoch sind diese
> Links (als Teil dessen was wir "Navigation" nennen wollen) trotzdem noch
> statisch. Sie haben vielleicht eine arg begrenzte Lebensdauer. Aber sie
> ändern sich über ihre Lebensdauer nicht. Vielleicht ist das sogar das
> beste Kriterium für 'statisch" vs. 'dynamisch'
Ja, statisch ist sie schon - nur würde eine andauernede Neugenerierung als
statische Seite halt einfach mehr Zeit verschlingen, als nur die Seiten
on-the-fly zu generieren, die man gerade wirklich benötigt :)
Das Problem bei vielen parallel arbeitenden Autoren wäre auch das Timing der
Generieung - generiert man bei jeder Änderung? Dann kommen garantiert neue
Änderungen, bevor die vorige Generierung abgeschlossen ist. Entweder bricht man
dann ab und fängt neu an (und kommt eventuell über lange Zeit nicht zum Ende)
oder die verschiedenen Jobs schaukeln sich immer mehr auf, bis gar nichts mehr
geht oder aber man nimmt ein festes Zeitraster. Die beste Lösung wäre in diesem
Fall wohl eine Queue, in der geänderte/neue Dokumente gelistet werden und die
Generierung läuft einfach durch. Was zum Zeitpunkt X in der Queue steht, wird im
nächsten Generierungsdurchlauf aufgenommen, alles andere kommt in eine frische
Queue... Um ehrlich zu sein, auf diese simple Idee mit der Queue bin ich bisher
noch nicht gekommen, darüber nachgedacht habe ich ja auch schon öfter mal,
gefällt mir eigentlich ganz gut :o)
>>Statisch ist das Basislayot,
>>also das Gerüst, in das die vielen verschiedenen Daten einlaufen. Alles andere,
>>wie Navigation wird generiert und eine kurze Zeit in der Anwendung gecached, da
>>es sich einfach zu oft ändert (und es einfach zu viele Versionen gäbe, um sie
>>statisch vorzugenerieren).ziemlich weit von dem entfernt, was man typischerweise auf
>
>
> Irgendwie habe ich den Verdacht, das du mit "Navigation" etwas völlig
> anderes meinst als ich. Wenn ich beispielsweise beim Heiseticker in die
> 7-Tage-Ansicht gehe, dann ist das für micht keine Navigation, sondern
> eine Webanwendung die mir eine spezielle Ansicht auf einen dynamischen
> Datenbestand zeigt.
Ja, aber es gibt ja auch Fälle, wo man bspw die Top-Drei als Navigationspunkte
aufnehmen muss oder ähnliches (inwiefern das Sinn macht, sei mal dahingestellt,
an größeren Projekten arbeiten ja nicht nur Techniker, sondern auch Designer und
Chefs :)
>>>Ich war mal Admin für eine Site mit >1000 Contentseiten und 2 Mio.
>>>Seitenabrufen am Tag. Da lernt man, was funktioniert und was nicht.
>>
>>Sehe ich genauso - allerdings hatte ich bisher eher selten mit Seiten in so
>>kleinem Umfang zu tun, es sind eher mehrere Millionen Contentseiten (davon sind
>>allerdings nur ein paar hunderttausend wirklich in der Liveausspielung
>
> ....
>
>>Achso, die Seitenabrufe bewegen sich bei bis zu 10 Millionen am Tag
>
>
> OK, den 'dick size war' hast du gewonnen ;-)
>
> Aber jetzt bin ich neugierig: 10 Mio/d extrapolieren auf 300 Mio/Monat.
> Soviel hat Spiegel Online. Und in der Region wird die Luft schon sehr
> dünn (zumindest listet die IVW nur noch eine handvoll Angebote dieser
> Größenordnung). Außerdem fällt auf, das die Angebote dieser Größe alle
> irgendwelche Nachrichtendienste oder Zeitungen sind.
Die Richtung stimmt. Ist einer der kleinsten der öffentlich-rechtlichen (SR),
das dicke Angebot, dass wir betreuen, ist tour.ARD.de. Die Zugriffe sind dabei
halt sehr ungleichmäßig verteilt, sprich, wir haben da extreme Peaks und lange
Flauten. Und ein Peak sind durchaus 1000 Reqs/sec (das geht dann über etwa fünf
Minuten). Leider lässt es sich nicht so einfach auf den Monat umrechnen, in drei
Wochen TdF haben wir da nur 45-50 Millionen (also einen Schnitt von etwa 2,5
Millionen PIs/Tag), es gibt halt ein paar extreme Tage und viele relativ
"schwache" Tage. Das Problem dabei ist, man muss halt vor allem die Peaks gut
überstehen.
>>was Du beschrieben hast, ist einfach nicht der einzig wahre
>>Weg, als den Du ihn hingestellt hast. Ich habe nichts gegen statische
>>Generierung, im Gegenteil, in vielen Fällen macht sie Sinn - aber nicht
>>generell. Das ist der Punkt, um den es mir geht.
>
>
> Klar doch. Generell beste Lösungen gibt es nicht. Nur irgendwie ist
> deine Anwendung ziemlich weit von dem entfernt, was man typischerweise
> auf einem Webserver beim Massenhoster macht. Vermutlich kann man das,
> was der OP vor hat, gar nicht zu bloatig aufsetzen. Bei 100
> Seitenabrufen pro Tag langweilt sich auch der langsamste Webserver zu
> Tode. Aber warum soll man den Leuten nicht beibringen, wie man es
> richtig macht - vielleicht brauchen sie es ja später mal.
Naja, ein Massenhoster würde uns damit wahrscheinlich entweder sofort kicken -
oder sich die Hände reiben, je nach abgeschlossenem Vertrag :o)
Generell sollte sich aber auf jeden Fall jeder Programmierer darüber im Klaren
sein, dass viele Wege nach Rom führen - nur nicht jeder gleich gut und dass die
Lösung, die in drei Fällen gut (genug) war, nicht automatisch auch im vierten
Fall gut ist. Vernünftige, vorausschauende Planung ist bei größeren Projekten
unumgänglich (wenn man nicht auf unangenehme Überraschungen steht, die gibt es
eh auch bei der besten Planung immer noch).
Grüße,
Martin
Hallo,
ich finde ja interessant, dass sich hier eine Diskussion entwickelt hat,
von der ich nur noch rudimentär etwas verstehe. Aber würde
freundlicherweise sich jemand zu meinem eigentlichen Problem äußern? Ich
möchte ca. 100-150 Seiten verwalten und erachte es als sinnvoll, die
Navigation über eine Datenbank laufen zu lassen, da ansonsten der Aufand
der Aktualisierung erheblich wäre. Das hätte ich zudem gern mit SQLite
gemacht, da ja nicht in die Datenbank geschrieben wird, sondern diese
nur ausgelesen werden muß. Aber - SQLite wird von 1&1 nicht unterstützt,
was jedoch u.U. nicht heisst, dass man es doch istallieren kann und
genau das war meine Frage.
969 schrieb:
> Hallo,
>
> ich finde ja interessant, dass sich hier eine Diskussion entwickelt hat,
> von der ich nur noch rudimentär etwas verstehe. Aber würde
> freundlicherweise sich jemand zu meinem eigentlichen Problem äußern? Ich
> möchte ca. 100-150 Seiten verwalten und erachte es als sinnvoll, die
> Navigation über eine Datenbank laufen zu lassen, da ansonsten der Aufand
> der Aktualisierung erheblich wäre. Das hätte ich zudem gern mit SQLite
> gemacht, da ja nicht in die Datenbank geschrieben wird, sondern diese
> nur ausgelesen werden muß. Aber - SQLite wird von 1&1 nicht unterstützt,
> was jedoch u.U. nicht heisst, dass man es doch istallieren kann und
> genau das war meine Frage.
Hm, ich kann dir leider keine genaue angabe geben, da ich 1und1 nicht
kenne, aber:
Was für ein betriebssystem hast du am Provider?
Wahrscheindlich ein Linux.
Damit du da eine Datenbank installieren kannst brauchst du erstens
einmal einen zugriff zur schell, meist über ssh.
Zweitens brauchst du die rechte (für eine DB meist root rechte) um die
Datenbank zu installieren.
Diese angebote sind meist recht teuer, aber falls du so eines hast,
poste einfach dein OS und frag wie man da am besten SQLlite über die
Shell installiert, sollte recht einfach gehen.
[Im fall von Debian z.B.: apt-get install {ok: ich denke mal: sqllite}]
Im fall von einer Windowsversion kann ich dir leider nicht helfen.
Ach ja: eine möglichkeit gibt es nocht: was ich beschreiben habe ist wie
man es selbst installieren kann. Wenn das nicht geht, geht es unter
umständen doch manchmal wenn man sich mit dem Provider in verbindung
setzt, und fragt ob die einen das machen können. Hat durchaus immer
wierder mal erfolg ;)
MfG,
Jörg
969 schrieb:
> Hallo,
>
> ich finde ja interessant, dass sich hier eine Diskussion entwickelt hat,
> von der ich nur noch rudimentär etwas verstehe. Aber würde
> freundlicherweise sich jemand zu meinem eigentlichen Problem äußern? Ich
> möchte ca. 100-150 Seiten verwalten und erachte es als sinnvoll, die
> Navigation über eine Datenbank laufen zu lassen, da ansonsten der Aufand
> der Aktualisierung erheblich wäre. Das hätte ich zudem gern mit SQLite
> gemacht, da ja nicht in die Datenbank geschrieben wird, sondern diese
> nur ausgelesen werden muß. Aber - SQLite wird von 1&1 nicht unterstützt,
> was jedoch u.U. nicht heisst, dass man es doch istallieren kann und
> genau das war meine Frage.
Ich denke da die Nachfrage bei 1&1 nicht zum Erfolg führte, bleibt dir
nichts anderes über als das mit der MySQL Datenbank umzusetzen.
Auch wenn dir das so scheint als schießt man mit Kanonen auf Spatzen, so
führt es dennoch zum Erfolg und das ist doch alles was zählt.
-Kirsten
Joerg Simon schrieb:
> Ach ja: eine möglichkeit gibt es nocht: was ich beschreiben habe ist wie
> man es selbst installieren kann. Wenn das nicht geht, geht es unter
> umständen doch manchmal wenn man sich mit dem Provider in verbindung
> setzt, und fragt ob die einen das machen können. Hat durchaus immer
> wierder mal erfolg ;)
Hat er ja schon, aber leider stellt sich 1&1 da quer.
-Kirsten
969 wrote:
> ich finde ja interessant, dass sich hier eine Diskussion entwickelt hat,
> von der ich nur noch rudimentär etwas verstehe. Aber würde
> freundlicherweise sich jemand zu meinem eigentlichen Problem äußern?
Du hast kein Problem. Zumindest keins bei dem *wir* dir helfen könnten.
Wenn du mit dem Angebot deines Hosters unzufrieden bist, dann kaufe ein
Upgrade oder wechsle. Wenn du beliebige Software installiert haben
willst, dann brauchst du einen Rootserver. Geiz mag zwar geil sein, aber
manchmal auch unpraktisch.
> Ich möchte ca. 100-150 Seiten verwalten und erachte es als sinnvoll, die
> Navigation über eine Datenbank laufen zu lassen, da ansonsten der Aufand
> der Aktualisierung erheblich wäre.
Bla bla bla. Wenn du meinst, daß eine Datenbank angemessen ist für die
Aufgabe, dann nimm doch das angebotene MySQL!
> Das hätte ich zudem gern mit SQLite
> gemacht, da ja nicht in die Datenbank geschrieben wird, sondern diese
> nur ausgelesen werden muß.
Und wieso sollte das ein Grund *für* SQLite aber *gegen* MySQL sein?
BTW, natürlich mußt du mindestens einmal in die Datenbank schreiben.
Oder wie sollen sonst deine Daten da rein kommen? Und wieso ist es
weniger aufwendig, die Daten in die Datenbank zu schreiben als in ein
(Include-)File? Fragen über Fragen.
> Aber - SQLite wird von 1&1 nicht unterstützt,
> was jedoch u.U. nicht heisst, dass man es doch istallieren kann und
> genau das war meine Frage.
Wie sollen *wir* dir diese Frage beantworten? Wir wissen ja noch nicht
mal, welchen der 10 (20?) Tarife von 1und1 du benutzt. Deine Frage
solltest du 1und1 stellen und die haben ja schon "Nein" gesagt.
XL