Leistungsbeschreibung eine Frechheit?!

[Reiner]

Hallo,

ich ärgere mich gerade wieder mal über Schlund....

Was sagt Ihr, wenn in der Leistungsbeschreibung steht:

[...]
Datenbank (mysql)
[...]

Ich gehe davon aus, ich habe DB-Zugriff. Dieser macht auch nur Sinn, wenn er mehr Leistung bietet, als wenn ich meine Dinge in Textdateien speicher, oder?
Sehe ich das so falsch?

Nun ist es so, das das DB-Timeout bei 120 Sek. liegt...

Da der Admin ein Script schonmal gesperrt hatte, weil ich die 120 Sek. überschritten hatte, bin ich dazu übergegangen, das Script nun selbst per alarm nach 110 Sek. zu töten.

Nachdem das nun einige Zeit anstandslos lief (obwohl in der Zeit nicht immer alle Daten bekommen konne...), wurde die DB nun vorrübergehend kurzerhand ganz abgeschaltet....

Begründung:
"[...]....über 500.000 sql-querys ....select from....[...]"

Ist es mein Problem? Wenn ich doch die Timeouts einhalte, bzw. er mich (falls er dazu imstande wäre...) killen würde, wäre die Sache doch gegesssen, oder?

Ich meine, das schreit doch nach außerordentlicher Kündigung, oder?
Für mich ist eine Textdatei somit effektiver als so'ne schrottige Connectivity an mysql-db.

Was meint Ihr?

Reiner

[Urmel]

Hui sind aber ganz schön viel sql-querys ;), allerdings verstehe ich Logik das Anbieters nicht ganz. Zum einen bieten diese eine Mysql DB an da diese um einiges schneller sein soll als der normale zugriff auf txt files zum anderen verbieten diese gleichzeitig den zugriff auf diese Daten.
Das kenn ich doch irgendwoher !!
Wie war das noch mal mit den sogenannten Flatrates!!??
Dort stand ebenfalls in der Leistungsbeschreibung "24 Stunden Online 7 Tage die Woche, alle 12 Stunden Zwangsdisconnect"
doch fatal für die Jenigen die diesen Leistungsanspruch wahr nahmen, denen wurde nämlich nach kurzer zeit gekündigt, mit der Begründung, dass es sich für den Anbieter nicht rentieren würde!!!
Von wegen kompetente Analytiker, scheisendreck Analytiker.
Das Problem mit diesen Firmen ist doch eindeutig die Selbstüberschätzung.
Denn wenn man etwas verspricht sollte man es auch halten können, hat mir schon meine Oma als kleines Kind beigebracht, da man sonst auf lange Dauer nicht mehr als loyal gilt.

Und was ziehe ich aus dieser Parallele?
Na ganz einfach, all diese miesen Gauner, welche sich mit irgendwelchen Versprechungen die Kunden anlocken, hatten einfach keine Oma.

Fazit: @Reiner-Falls dieses Problem weiter bestehen bleibt und damit meine ich so ca. 2 Stunden, würde ich diesem scheissendreck Anbieter kündigen. (Solange nichts im Vertrag von wegen
if(sql-querys>500.000){abstell(DB);}
drinne stand ;))

Wie schaut es eigentlich mit dem Namen des Anbieters aus, würde mich aus reiner Neugier interessieren. Ein bisschen Werbung muss einfach sein.

Gruß Urmel

[Reiner]

Hi,

Hui sind aber ganz schön viel sql-querys ;), allerdings verstehe

ach, was sind 500.000 querys pro Stunde, wenn ich da Daten von 100 Kunden für einen Monat verarbeiten will....

Wie war das noch mal mit den sogenannten Flatrates!!??

Dem kann ich def. NICHT zustimmen, habe Flat bei T-Online-->keine Probleme!!!

Wie schaut es eigentlich mit dem Namen des Anbieters aus, würde mich aus reiner Neugier interessieren. Ein bisschen Werbung muss einfach sein.

Habe ich doch (in der ersten Zeile) genannt!

http://www.schlund.de, wer sonst....

Reiner

[Cheatah]

Hi,

ach, was sind 500.000 querys pro Stunde, wenn ich da Daten von 100 Kunden für einen Monat verarbeiten will....

mindestens 499.000 Queries pro Stunde zu viel.

Du hast eindeutig Dein DB-Layout ungünstig gewählt. Dazu gehören die Tabellenstruktur _und_ die Statements, die Du abfährst. Organisiere entweder die Tabellen anders, oder optimiere die Statements. Wenn Du in Deiner Programmlogik innerhalb von Schleifen Statements ausführst, versuche, die entsprechenden Daten durch _ein_ Statement zu erhalten.

Jeder DB-Request kostet Zeit und Ressourcen. Damit ist nicht nur die Rechenzeit im DBMS gemeint, und auch nicht die Übertragung der Bytes.

Wenn Du in einem Script mehr als ca. 10 DB-Requests brauchst, solltest Du Dir vermutlich Gedanken machen.

Cheatah

[Bio]

Sup!

Nee, Cheatah, die Datensaetze alle auf einmal anzufordern geht nicht, da muss man schon fuer jeden der Kunden alle Datensaetze einzeln anfordern, sonst verbraucht das ja lokal Speicherplatz, da belasten wir lieber die Datenbank mit 1Mio. Queries.
Ein Kumpel von mir wollte mal seine Festplatte per eMail ausbauen: Alle Daten von der Platte an falsche eMail-Addressen verschicken, nach ein paar Stunden sind sie wieder verfuegbar, weil der Mailserver den Mailinhalt als Error-Message ja wieder zurueckschickt - dann schnell eMails wieder wegschicken, Platz sparen, Internet als Speicher benutzen... die 1 Mio eMails und der Traffic waren dem auch nicht so wichtig ;-)

Gruesse,

Bio

[Cheatah]

Hi,

Nee, Cheatah, die Datensaetze alle auf einmal anzufordern geht nicht,

nur die, die man braucht.

sonst verbraucht das ja lokal Speicherplatz,

Nope. Du holst Dir jeden Datensatz einzeln aus der Queue - aus nur einem Statement.

da belasten wir lieber die Datenbank mit 1Mio. Queries.

Query = SQL-Statement = DBMS-Roundtrip = Zeitaufwand = böse

Ein Kumpel von mir wollte mal seine Festplatte per eMail ausbauen: [...]

Waaah! :-)

Cheatah

[Slyh]

Hallo,

Hui sind aber ganz schön viel sql-querys ;),

Allerdings.

allerdings verstehe ich Logik das Anbieters nicht ganz. Zum einen bieten diese eine Mysql DB an da diese um einiges schneller sein soll als der normale zugriff auf txt files zum anderen verbieten diese gleichzeitig den zugriff auf diese Daten.
Das kenn ich doch irgendwoher !!
Wie war das noch mal mit den sogenannten Flatrates!!??
Dort stand ebenfalls in der Leistungsbeschreibung "24 Stunden Online 7 Tage die Woche, alle 12 Stunden Zwangsdisconnect"
doch fatal für die Jenigen die diesen Leistungsanspruch wahr nahmen, denen wurde nämlich nach kurzer zeit gekündigt, mit der Begründung, dass es sich für den Anbieter nicht rentieren würde!!!

In den AGBs von Schlund (um diesen Provider geht es, wie Reiner schon gesagt
hat) steht eindeutig folgendes:
" 13.5
   eine übermäßige Belastung des Servers, z.B. durch CGI-Skripte, die eine hohe Rechenleistung erfordern oder überdurchschnittlich viel Arbeitsspeicher beanspruchen, vermieden wird.
   Schlund + Partner ist berechtigt, Seiten, die den obigen Anforderungen nicht gerecht werden, vom Zugriff durch den Kunden oder durch Dritte auszuschließen. Schlund + Partner wird den
   Kunden unverzüglich von einer solchen Maßnahme informieren. Schlund + Partner wird die betreffenden Seiten wieder zugänglich machen, wenn der Kunde Schlund + Partner nachweist,
   dass die Seiten und so umgestaltet wurden, dass sie den obigen Anforderungen genügen.
"

Das halt ich für legitim und absolut korrekt. Ein 120-Sekunden-DB-Zugriff mit
500.000 SQL-Querys ist weit entfernt von Gut und Böse.
Wie mein Admin gerade sagte: "Boah, armer Server!".
Ungünstigerweise liegen auf den Kisten bei Schlund wohl noch ein paar mehr
Kunden, die gelegentlich auch mal ganz gerne den Datenbank-Server benutzen
würden.
Wenn er wirklich einen ganzen Server für sich haben will, sollte er sich
einen eigenen hinstellen und auch gewillt sein, für diesen zu zahlen.

[..]

Wie schaut es eigentlich mit dem Namen des Anbieters aus, würde mich aus reiner Neugier interessieren.

Du weißt noch nicht einmal um welchen Anbieter es geht, meinst aber trotzdem,
dir auch nur ansatzweise eine Meinung bilden zu können?!

Gruß
Slyh

PS: Zugegeben, ein bißchen viel Polemik meinerseits. Aber nicht wirklich
unberechtigt.

PPS: Ach ja, Disclaimer: Ich arbeite weder bei Schlund, noch 1&1, noch einer
sonstigen Partner/Tochter-Firma beider genannter Unternehmer. Bin aber
Kunde bei Schlund.

[Reiner Rusch]

Das halt ich für legitim und absolut korrekt. Ein 120-Sekunden-DB-Zugriff mit
500.000 SQL-Querys ist weit entfernt von Gut und Böse.
Wie mein Admin gerade sagte: "Boah, armer Server!".

Die halbe Millionen Querys stammen nicht von den 120 Sek.! Sondern von einer Stunde (etwa). Das halte ich nicht für besonders viel, aber darum geht es auch nicht.

Reiner

[Ron]

Die halbe Millionen Querys stammen nicht von den 120 Sek.! Sondern von einer Stunde (etwa). Das halte ich nicht für besonders viel, aber darum geht es auch nicht.

Hallo Reiner,

wenn 500.000 Querys pro Stunde (immerhin fast 139 Querys pro Sekunde) nicht viel sind, was ist denn dann für Dich viel? Mal so aus Interesse...

Sorry, aber bei der Menge kann ich voll und ganz verstehen, wenn Schlund Dir da einen Riegel vorschiebt.

Viele Grüße,
Ron

[Slyh]

Hallo,

Das halt ich für legitim und absolut korrekt. Ein 120-Sekunden-DB-Zugriff mit
500.000 SQL-Querys ist weit entfernt von Gut und Böse.
Wie mein Admin gerade sagte: "Boah, armer Server!".

Die halbe Millionen Querys stammen nicht von den 120 Sek.! Sondern von einer Stunde (etwa). Das halte ich nicht für besonders viel, aber darum geht es auch nicht.

Auch 16666 Datenbank-Anfragen in 120 Sekunden sind immer noch weit jenseits
von Gut und Böse. Aber das hat Ron ja jetzt schon gesagt.
Sieh es ein.

Gruß
Slyh

[Urmel]

In den AGBs von Schlund (um diesen Provider geht es, wie Reiner schon gesagt
hat) steht eindeutig folgendes:
" 13.5

»»eine übermäßige Belastung des Servers, z.B. durch CGI-Skripte, die eine hohe Rechenleistung erfordern oder überdurchschnittlich viel Arbeitsspeicher beanspruchen, vermieden wird.

ersteinmal glaub ich kaum das irgendein script solch viel Arbeitspeicher-platz in Anspruch nehmen wird, das hierdurch eine gefährdung des Systems auf GRund eines DatenOverflow stattfindet. (ausgenommen script mit der berühmten while(1){...}-schleife) Denn jeder gute Server sollte ein oder >ein GB-Ram haben.
Zweitens kann man den Prozessen verschieden viel Rechenleistung zur verfühgung stellen so das kein Prozess den server bzw. die anderen Kunden beeinträchtigen sollte. Was jeder daraus macht ist seine sache.

Das halt ich für legitim und absolut korrekt. Ein 120-Sekunden-DB-Zugriff mit
500.000 SQL-Querys ist weit entfernt von Gut und Böse.
Wie mein Admin gerade sagte: "Boah, armer Server!".
Ungünstigerweise liegen auf den Kisten bei Schlund wohl noch ein paar mehr
Kunden, die gelegentlich auch mal ganz gerne den Datenbank-Server benutzen
würden.

Da geb ich dir einerseits recht doch ich würde es nicht einsehen, denn warum soll ich das nicht voll ausnutzen. Es liegt doch wohl in den Händen eines jeden guten Administrator, den server so zu konfigurieren das solche lapalien erspart bleiben.
Denn ich kauf mir doch auch keinen ferrari, damit anschließend der Hersteller zu mir kommt und verlangt das ich mit dieser heisserkarre nur 100 Km/h fahren darf da ansonsten die Garantieanspüche als nichtig golten.

Wenn er wirklich einen ganzen Server für sich haben will, sollte er sich
einen eigenen hinstellen und auch gewillt sein, für diesen zu zahlen.

Nagut, da hast du recht aber hat er jemals etwas davon erwähnt?

Du weißt noch nicht einmal um welchen Anbieter es geht, meinst aber trotzdem,
dir auch nur ansatzweise eine Meinung bilden zu können?!

Hierbei geht es doch eindeutig nicht um den Namen eines Anbieters, mit solchen belanglosen dingen gib ich mich erst garnicht ab, hierbei sprechen doch eindeutig die Fakten für mich.

PS: Zugegeben, ein bißchen viel Polemik meinerseits. Aber nicht wirklich
unberechtigt.

nicht nur das, ein richtiger Polemiker bist du mir.

Gruß Urmel

[Slyh]

Hallo,

»»eine übermäßige Belastung des Servers, z.B. durch CGI-Skripte, die eine hohe Rechenleistung erfordern oder überdurchschnittlich viel Arbeitsspeicher beanspruchen, vermieden wird.

ersteinmal glaub ich kaum das irgendein script solch viel Arbeitspeicher-platz
in Anspruch nehmen wird, das hierdurch eine gefährdung des Systems auf GRund
eines DatenOverflow stattfindet.

Wer redet von Arbeitsspeicher? Das ist zwar auch ein Faktor, hierum geht es
jedoch nicht. Es geht um Prozessorleistung, im speziellen auf dem Datenbank-
Server.
Und doch, solche Skripte gibt es. Es gab da z.B. mal ein recht simples
Skript mit einer For-Schleife und einem flock, das die E6500 (bei Strato
war das) ziemlich böse in die Knie gezwungen hat. Wie böse, weiß ich nicht.
Ein Amdin bei XLink (so hieß das damals noch) war damals aber ziemlich sauer :)

Zweitens kann man den Prozessen verschieden viel Rechenleistung zur
verfühgung stellen so das kein Prozess den server bzw. die anderen
Kunden beeinträchtigen sollte. Was jeder daraus macht ist seine sache.

Ja, das gibt es. http://service.schlund.de/service/dokumentation/neu_limits.php3#1
Und genau über diese Art von Limits beschwert sich Reiner.
Was man übrigens nicht kontrollieren kann, sind die Anzahl der Querys pro
Skript. Zumindest mit mySQL ist dies nicht möglich. Und genau hier tritt
das "Problem von Reiner" auf.

Das halt ich für legitim und absolut korrekt. Ein 120-Sekunden-DB-Zugriff mit
500.000 SQL-Querys ist weit entfernt von Gut und Böse.
Wie mein Admin gerade sagte: "Boah, armer Server!".
Ungünstigerweise liegen auf den Kisten bei Schlund wohl noch ein paar mehr
Kunden, die gelegentlich auch mal ganz gerne den Datenbank-Server benutzen
würden.

Da geb ich dir einerseits recht doch ich würde es nicht einsehen, denn warum soll ich das nicht voll ausnutzen.

Zum Beispiel weil du dadurch gegen den Vertrag verstößst? Zum Beispiel, weil
du dadurch auf anderen Kunden rumtrampelst? Zum Beispiel, weil du deinem
Hoster dadurch ganz erhebliche Arbeit aufhalst?
Was heißt hier überhaupt "voll ausnutzen"? Einen Server, den ich mit wasweißich
500 oder 1000 anderen Kunden benutze, voll auszunutzen, ohne Rücksicht
auf Verluste, halte ich für mehr als frech. Noch viel frecher finde ich es,
sich dann noch über den ach so bösen Hoster aufzuregen.

Es liegt doch wohl in den Händen eines jeden guten Administrator, den server so zu konfigurieren das solche lapalien erspart bleiben.

Wie gesagt, funktioniert dies in diesem konkreten Fall aufgrund der Tatsache,
daß die mySQL-Datenbank keine Kontrolle in diese Richtung zuläßt, nicht.
Trotzdem haben die Leute von Schlund das gemerkt, das aggressive Skript
stillgelegt und den Kunden informiert, damit die restlichen 999 Kunden auf
dem Server wieder mit der Datenbank arbeiten können.

Von welchen Lapalien redest du?
Reiner beschwert sich, daß sein Skript gekillt wurde. Du sagtest im voran-
gegangenen Posting, daß der Hoster seine versprochene Leistung nicht einhält/
einhalten kann, was aus genannten Gründen faktisch natürlich völlig falsch ist.
In diesem Posting schreibst du nun, daß der Hoster doch bitte sein System
so konfigurieren soll, daß die Zugriffe begrenzt werden.
Was genau willst du jetzt eigentlich?

Denn ich kauf mir doch auch keinen ferrari, damit anschließend der Hersteller zu mir kommt und verlangt das ich mit dieser heisserkarre nur 100 Km/h fahren darf da ansonsten die Garantieanspüche als nichtig golten.

1. ist es nicht _sein_ Ferrari. Er teilt sich diesen mit 1000 Leuten.
2. hat er keinen Ferrari. Ein eigener Server kommt in die Richtung eines Ferraris. Er fährt in einem Bus mit.
3. wird er es sich nicht leisten können, einen Ferrari zu haben. Er wird sich eher einen Kleinwagen leisten.

Wenn er wirklich einen ganzen Server für sich haben will, sollte er sich
einen eigenen hinstellen und auch gewillt sein, für diesen zu zahlen.

Nagut, da hast du recht aber hat er jemals etwas davon erwähnt?

Wovon? Nein, er hat nicht gesagt, daß er einen eigenen Server will. Ich habe
gesagt, daß er den ganzen Server für sich beansprucht. Wenn er meint, er müsse
das tun, sollte er sich aber auch einen eigenen hinstellen.

[..], hierbei sprechen doch eindeutig die Fakten für mich.

Scheinbar nicht. Wie du bestimmt schon den restlichen Postings entnommen
hast, stehe ich mit meiner Meinung nicht so ganz alleine da.
Jeder, der auch nur ansatzweise eine Ahnung von der Thematik hat, wird mir
recht geben, obwohl ich eher Laie auf diesem Gebiet bin.

nicht nur das, ein richtiger Polemiker bist du mir.

Sorry, aber solches Verhalten geht mir auf den Keks. Da erlaube ich mir ein
bißchen Polemik, solange ich auch Argumente liefere. Soll aber kein
persönlicher Angriff jeglicher Art sein!

Gruß
Slyh

[Urmel]

Also ...
1. wusste ich nicht das dies bei MySql nicht möglich ist (nicht begrenzung der Abfragen in einem Script)

2. Gib ich dir recht sql-querries über 500.000 innerhalb von einer Stunde, ist auf gut deutsch wahnsinn!!!

3. Es ging mir garnicht mal so sehr um die Fakten, sondern um die Einstellung des Anbieters, den Kunden zur Verantwortung zu ziehen, wenn das system unsicher bzw. unstabliel ist. (siehe Microsoft die fahren allerdings noch eine andere Taktik auf die stellen nämlich alle Hacker ein, die es schaffen das System zu knacken, dass ist doch mal was). Jetzt, wie in Reiners Fall ist es natürlich etwas anderes denn wenn bei MySql keine Abfrage stattfindet ist das natürlich aa für den Server.

Gruß Urmel

Ps. Dass sollte auch nicht erstgemeint sein, mit dem Polemiker, aber ein wenig Ironie muss einfach sein. ;)

[Slyh]

Hallo,

na fein, dann sind wir uns ja einig. :)

Ich denke, daß Schlund durchaus als seriös bezeichnet werden kann. Ist
immerhin einer der wenigen Provider, die Gewinn abwerfen, wenn ich richtig
informiert bin. Und daß die sich und ihre Kunden schützen möchten, ist nur
verständlich und vertraglich auch einwandfrei geregelt.

Ich mag nur eben die Leute nicht, die Mist bauen und dann groß rumjammern,
wie böse die Welt, speziell irgendeine Firma, doch ist. Am besten sollten
die einen eigenen Server hinstellen, 20 Domains, 40 GB Traffic. Und das
ganze für 10 Mark/Monat. Aber ich fange schon wieder damit an.. :-)

Gruß
Slyh

PS: Ich glaube ich habe das mit der Polemik schon richtig verstanden :-)

[Slyh]

Hallo,

die anderen Kunden auf dem Server freuen sich bestimmt ganz besonders,
wenn du den Datenbankserver ganz alleine für dich beanspruchst.

Was erwartest du denn für das Geld? Daß Schlund dir einen eigenen Server
hinstellen? Wenn du das willst, solltest du dich mal über Server-Homing
informieren. Beschwer dich dann aber nicht, daß du das 5- bis 10-fache
bezahlst.

Und was redest du da von außerordentlicher Kündigung? Hast überhaupt mal die
AGBs von Schlund gelesen? Die sind Vertragsbestandteil, wie du bestimmt
weißt. Speziell interessiert dich vermutlich Punkt 13.5

Gruß
Slyh

[Reiner]

Hi,

die anderen Kunden auf dem Server freuen sich bestimmt ganz besonders,
wenn du den Datenbankserver ganz alleine für dich beanspruchst.

das ist Quark!
Ich lasse die Scripte per Cron schon mit nice 19 laufen!
Mir ist auch egal, wie lange sie brauchen, aber das geht bei schlund ja auch nicht...

Was erwartest du denn für das Geld? Daß Schlund dir einen eigenen Server
hinstellen? Wenn du das willst, solltest du dich mal über Server-Homing
informieren. Beschwer dich dann aber nicht, daß du das 5- bis 10-fache
bezahlst.

Ich erwarte ordentliche Information "bevor" ich den Kram anmiete!
Ich halte mich ja an die Limits. Es ist einfach ein Unding bzw. Willkür, die DB bzw. Scripte einfach auszuhebeln...
Das kommt, je nach Anwendung, teurer, als wenn ich Homing genommen hätte!
Zu Homing: Schlund ist auch nicht in der Lage, ohne weiteres mehr Speicher (Ram > 128MB) zu installieren (wenn doch, sollte das neu sein).
Fazit ist für mich: Wir sagen dem Kunden, er hat eine DB, wenn er sie mehr als dazu nutzt, alle drei Wochen ein Familienmitglied und dessen Adresse zu speichern, sperren wir einfach mal sein Script.
Natürlich mit dem Hinweis, daß er bei uns auch Homing haben kann...

Und was redest du da von außerordentlicher Kündigung? Hast überhaupt mal die
AGBs von Schlund gelesen? Die sind Vertragsbestandteil, wie du bestimmt
weißt. Speziell interessiert dich vermutlich Punkt 13.5

Gerade der Punkt ist nur schwammig!
Es ist keine klare Aussage, wo die Grenzen sind. Deutet auch wieder auf Willkür hin!

Reiner

[Slyh]

Hi,

das ist Quark!
Ich lasse die Scripte per Cron schon mit nice 19 laufen!
Mir ist auch egal, wie lange sie brauchen, aber das geht bei schlund ja auch nicht...

Wenn ich richtig informiert bin, killt Schlund Skripte nicht nach Laufzeit,
sondern nach verbratener Rechenzeit. Diese maximale Rechenzeit beträgt
zwischen 6 und 12 Sekunden. Wenn dein Skript praktisch keine Rechenzeit
verbrät, kannst du es auch erheblich länger laufen lassen.

Eigentlich ging es aber um die Datenbank. Hier besteht laut FAQ eben die
genannte Begrenzung von 120 Sekunden. "Die MySQL-Datenbank darf in einem
Skript nur 120 Sekunden geöffnet bleiben und muss dann wieder geschlossen
werden."

Was erwartest du denn für das Geld? Daß Schlund dir einen eigenen Server
hinstellen? Wenn du das willst, solltest du dich mal über Server-Homing
informieren. Beschwer dich dann aber nicht, daß du das 5- bis 10-fache
bezahlst.

Ich erwarte ordentliche Information "bevor" ich den Kram anmiete!

Hast du. Es gibt die AGBs, es gibt die FAQ bzw. die "technischen Fragen".
Unter http://service.schlund.de/service/dokumentation/neu_limits.php3
findest du alles, was du wissen mußt. Wenn Fragen dort nicht beantwortet
werden, kannst du sicherlich den Support bemühen.
Was willst du noch mehr?

Ich halte mich ja an die Limits. Es ist einfach ein Unding bzw. Willkür, die DB bzw. Scripte einfach auszuhebeln...

Du hast gegen die AGBs verstoßen. Was erwartest du? Schlund hat sich völlig
vertragskonform verhalten. Du bist derjenige, der meiner Ansicht nach gegen
den Vertrag verstoßen hat.

Das kommt, je nach Anwendung, teurer, als wenn ich Homing genommen hätte!

Dann solltest du dich vorher informieren. Bei (mind.) 99 DM/Monat, die du
vermutlich zahlst, würde ich das zumindest tun.
(S.o.)

Zu Homing: Schlund ist auch nicht in der Lage, ohne weiteres mehr Speicher (Ram > 128MB) zu installieren (wenn doch, sollte das neu sein).

Dazu kann ich nichts sagen.

Fazit ist für mich: Wir sagen dem Kunden, er hat eine DB, wenn er sie mehr als dazu nutzt, alle drei Wochen ein Familienmitglied und dessen Adresse zu speichern, sperren wir einfach mal sein Script.

Falsch. "Wenn er sie so benutzt, daß die anderen Kunden sie nicht mehr
benutzen können, dann sperren wir ihm das Skript, so wie das in unseren AGBs
zu lesen ist". Schon alleine daß sie gemerkt haben, daß die Datenbank
erheblich beansprucht wird, dürfte ein eindeutiges Zeichen sein, daß da
vielleicht auf deiner Seite was nicht so toll läuft. Du glaubst doch wohl
nicht wirklich, daß die bei der Menge an Datenbanken überhaupt merken, wenn
ein einzelner Kunde mal ein bißchen mehr von der Datenbank beansprucht. Da
muß wohl schon ein bißchen mehr passieren.

Und was redest du da von außerordentlicher Kündigung? Hast überhaupt mal die
AGBs von Schlund gelesen? Die sind Vertragsbestandteil, wie du bestimmt
weißt. Speziell interessiert dich vermutlich Punkt 13.5

Gerade der Punkt ist nur schwammig!
Es ist keine klare Aussage, wo die Grenzen sind. Deutet auch wieder auf Willkür hin!

Was sollen die denn deiner Meinung nach in die AGBs schreiben, das nicht
so schwammig ist?

Gruß
Slyh

[Reiner]

Also,

die 500.000 habe ich der Mail des Admins, ohne groß nachzudenken, einfach übernommen...
Ist im Grunde Schwachsinn oder ironisch gemeint?!

Ich mache folgendes:

Für jeden Kunden:
 |_Für jeden Monat:
   |_Für jeden Tag:
     |_hole Daten, wo Kunde = "blablabla" UND parameter1 = "blablabla".....

d.h. vielleicht könnte man das besser zusammenfassen, aber dann habe ich ein anderes Problem, weil ich an ein CGI-Timeout beim sortieren der Arrays komme.

Im Endeffekt komme ich also auf:

4 (Mai - August) * 30 (Tage) * 100 Kunden = Anzahl der Querys....

Das sind also (ca.) 12.000 querys.

Ist sicher noch zu verbessern, aber eben nicht 500.000

Da das auch nur einmal durchlaufen wird, wird später auch nur ein Monat erneuert....
Vielleicht ist aber auch das schon zuviel?

[donut]

MAchst du ein Join auf den Datenbanken oder schmeist du ersteinmal die Datenbanken wild mit nem Select * FROM a,b zusammen? Dann muß er erstemal die Kreuztabelle aufbauen.. udn dann rechne nochmal was da an Daten rauskommt...

Oder ist das etwa nur eine Tabelle?

Ich mache folgendes:

Für jeden Kunden:
|_Für jeden Monat:
   |_Für jeden Tag:
     |_hole Daten, wo Kunde = "blablabla" UND parameter1 = "blablabla".....

d.h. vielleicht könnte man das besser zusammenfassen, aber dann habe ich ein anderes Problem, weil ich an ein CGI-Timeout beim sortieren der Arrays komme.

Ich hoffe Du sortierst nicht das was aus der Datenbank kommt, sondern holst es dir schon mit nem Sort raus (geht schneller wenn die DB das macht)

Im Endeffekt komme ich also auf:

4 (Mai - August) * 30 (Tage) * 100 Kunden = Anzahl der Querys....

Nö. Wie ist die DB aufgebaut? Machst Du ein böses select * from bei dem er dann erst aussortiert?

Das sind also (ca.) 12.000 querys.

Ist sicher noch zu verbessern, aber eben nicht 500.000

Sicher?

Schnapp Dir am besten mal ein Buch über DB - Design...

[Reiner]

MAchst du ein Join auf den Datenbanken oder schmeist du ersteinmal die Datenbanken wild mit nem Select * FROM a,b zusammen? Dann muß er erstemal die Kreuztabelle aufbauen.. udn dann rechne nochmal was da an Daten rauskommt...

Oder ist das etwa nur eine Tabelle?

Ja, ist nur eine.

Ich mache folgendes:

Für jeden Kunden:
|_Für jeden Monat:
   |_Für jeden Tag:
     |_hole Daten, wo Kunde = "blablabla" UND parameter1 = "blablabla".....

d.h. vielleicht könnte man das besser zusammenfassen, aber dann habe ich ein anderes Problem, weil ich an ein CGI-Timeout beim sortieren der Arrays komme.

Ich hoffe Du sortierst nicht das was aus der Datenbank kommt, sondern holst es dir schon mit nem Sort raus (geht schneller wenn die DB das macht)

Im Endeffekt komme ich also auf:

4 (Mai - August) * 30 (Tage) * 100 Kunden = Anzahl der Querys....

Nö. Wie ist die DB aufgebaut? Machst Du ein böses select * from bei dem er dann erst aussortiert?

Nein, kein Wildcard!

Schleife wie beschrieben, und dann:

select from TABELLE where kunde = 'id-soundso' and date = '2001-08-20' and parameter1 = 'dasunddas'

[Reiner]

select from TABELLE where kunde = 'id-soundso' and date = '2001-08-20' and parameter1 = 'dasunddas'

meinte natürlich:

select count(ID) from TABELLE where kunde = 'id-soundso' and date = '2001-08-20' and parameter1 = 'dasunddas'

wobei ID eine fortlaufende Zeilennummer ist...

[Klaus Mock]

Hallo,

select count(ID) from TABELLE where kunde = 'id-soundso' and date = '2001-08-20' and parameter1 = 'dasunddas'

Hmm, wenn ich mich recht erinnere, war das da ja mal vor kurzem Thema in einem Thread hier.
Nachdem nur die Summen gefragt sind, müßte ein
SELECT kunde,date,parameter1,COUNT(*)
   FROM tabelle
   GROUP BY kunde,date,parameter1

oder eventuell monatsweise (hier August)

SELECT kunde,date,parameter1,COUNT(*)
   FROM tabelle
   WHERE MONTH(date) = 8
   GROUP BY kunde,date,parameter1

reichen.
Das ist nur mehr ein Statement und daher für die Datenbank, das Script und das Nervenkostüm sowohl des Providers  als auch von Dir deutlich besser.

Vielleicht ist da noch ein ORDER BY notwendig.

Grüße
  Klaus

PS.: Ich weiß nicht, ob DU auch an Indizes gedacht hast, aber ich habs zumindest mal erwähnt. Auch das hat erheblichen Einfluß auf die Performance.
Noch ein Tip. Hol Dir, falls Du das nicht ohnehin schon mal getan hast, die aktuelle Datenbank vom Server und probiere die Scripts und die Statements lokal aus, um das alles besser zu optimieren.
Erst dann sollten die Dinger wieder auf die Live-Maschine.

[Cheatah]

Hi,

mal so nebenbei:

probiere die Scripts und die Statements lokal aus, um das alles besser zu optimieren.

Gibt es bei MySQL eigentlich so etwas wie "Explain Plan" bei Oracle? Das hilft nämlich gerade bei der Optimierung von (ursprünglich mehrstündigen *g*) Statements ungemein, weil man sie nicht erst ausführen muss. Zwar braucht man eine Menge Erfahrung, um damit zu arbeiten; aber für die Execution Plans könnte ich Oracle regelmäßig küssen.

Beherrscht MySQL mehrspaltige (oder gar Function Based) Indizes?

Cheatah

[Klaus Mock]

Hallo,

Gibt es bei MySQL eigentlich so etwas wie "Explain Plan" bei Oracle?

Ich bin sicherlich nicht einer, der mySQL gut kennt, aber anscheinend gibts schon was:

http://www.mysql.com/doc/Q/u/Query_Speed.html

Das hilft nämlich gerade bei der Optimierung von (ursprünglich mehrstündigen *g*) Statements ungemein, weil man sie nicht erst ausführen muss.

Meinst Du mit mehrstündig die Ausführung des Statements, oder das Schreiben (und Diskutieren) desselben:-)

Beherrscht MySQL mehrspaltige (oder gar Function Based) Indizes?

Auch das AFAIK. http://www.mysql.com/doc/C/R/CREATE_INDEX.html

Das Ding kann eine Menge wirklich toller Dinger, nur das Fehlen von Transaktionslogik und Stored Procedures verhindern IMHO den Einsatz für viele Anwendungsfälle.

Bei Oracle habe ich persönlich so eine zweigeteilte MEinung. Einerseits kann Oracle wirklich viel mehr als die meisten anderen Datenbanken, andererseits werden die auch immer schlampiger, und ich befürchte, daß uns mit Oracle in so 5 bis 10 Jahren das gleiche blüht, das es schon vor 10 Jahren mit IBM gab und heute mit Microsoft gibt.
Ellison (Schreibt man den so?) und Gates unterscheidet IMHO nur der Umstand, daß Gates heute schon das Geld scheffelt, das Ellison so gern haben möchte.

Grüße
  Klaus

[Cheatah]

Hi,

http://www.mysql.com/doc/Q/u/Query_Speed.html

exakt sowas hatte ich gesucht. Danke!

Das hilft nämlich gerade bei der Optimierung von (ursprünglich mehrstündigen *g*) Statements ungemein, weil man sie nicht erst ausführen muss.

Meinst Du mit mehrstündig die Ausführung des Statements, oder das Schreiben (und Diskutieren) desselben:-)

Klare Sache: beides! *g*

Wenn man ein Statement nur ein Mal ausführen will, kann es natürlich suboptimal sein. Sowie es aber öfter abgefahren werden soll, lohnt sich die Optimierung - auch weil die Leistungskapazität des DBMS während der Ausführung natürlich reduziert ist.

Beherrscht MySQL mehrspaltige (oder gar Function Based) Indizes?

Auch das AFAIK. http://www.mysql.com/doc/C/R/CREATE_INDEX.html

Coole Sache, das. Hätte ich MySQL nicht wirklich zugetraut. Mehrspaltige Indizes schon, aber FBI... :-)

Das Ding kann eine Menge wirklich toller Dinger, nur das Fehlen von Transaktionslogik und Stored Procedures verhindern IMHO den Einsatz für viele Anwendungsfälle.

Subselects (soll es ja ab MySQL 4.0 geben) und diverse Constraints fehlen mir persönlich neben den Transaktionen am meisten; vielleicht auch, weil ich mit Stored Procedures nur selten Kontakt habe. Da man MySQL sehr häufig (jaja, ich weiß, genau wie Perl *g*) im Zusammenhang mit dem Internet verwendet, hat man aber oft definierte Programmiersprachen vorliegen (PHP, Perl), deren Modularität Stored Procedures bei geschicktem Einsatz zumindest teilweise ersetzen kann.

Bei Oracle habe ich persönlich so eine zweigeteilte MEinung. Einerseits kann Oracle wirklich viel mehr als die meisten anderen Datenbanken, andererseits

...ist es bisweilen grottenlahm. Man muss schon einiges an Optimierungsarbeit leisten, um mit Oracle eine vertretbare Geschwindigkeit zu erreichen. Der Vorteil: mit Oracle _kann_ man optimieren - und zwar _wirklich_ :-)

werden die auch immer schlampiger,

Unser DB-Experte sagte mal sinngemäß: Die Oracle-Entwickler können mit allem, was gradlinig ist, unglaubliche Dinge leisten. Sowie aber der Begriff "fuzzy" an Bedeutung gewinnt, versagen sie kläglich.

Ich persönlich merke das ständig dadurch, dass wir auf dem Intermedia Text Package von Oracle aufbauen. Uns schmieren dabei ständig die Shadow-Prozesse auf DB-Seite ab und nehmen die Connection vom Client gleich mit, welcher sie (bei unserer Software) dann erst mal nicht wieder aufbauen kann. Die Folge sind ORA-03113 und danach 03114 bei Requests selbst statischer Seiten, weil auch diese bei uns von einer DB-Verbindung abhängen.

Morgen spielen wir einen neuen Patch ein, der angeblich auch einiges an Intermedia fixen soll. Es sind auch nur vier Lifesysteme, die dabei einige Stunden lang ausfallen, und nur ca. 15 Leute haben währenddessen nichts zu tun; von zahlenden Kunden außer Haus ganz zu schweigen... :-)

Meintest Du mit "schlampig" ungefähr sowas, oder gibt es noch 'ne Stilblüte?

Cheatah

[Klaus Mock]

Hallo,

Meinst Du mit mehrstündig die Ausführung des Statements, oder das Schreiben (und Diskutieren) desselben:-)

Klare Sache: beides! *g*

Das habe ich aber durchaus ernstgemeint. [1]

Wenn man ein Statement nur ein Mal ausführen will, kann es natürlich suboptimal sein.

[1] Ein Freund von mir ist DBA bei einem hiesigen Unternehmen, in dem (VDA und EU sei dank) sämtliche Produktionsschritte peinlich genau protokolliert werden müssen.
Die haben da eine Datenbank mit an die 35 TByte Tablespaces.
Ein Statement mit Joins über mehrere Tabellen bei der Größenordnung will auch bei einmaliger Ausführung genau überlegt sein.

...ist es bisweilen grottenlahm.

"Jo, des schdimmd" (c) Toni Polster (wer'n kennt)

[...] mit Oracle _kann_ man optimieren - und zwar _wirklich_ :-)

"nicht immer, aber immer öfters" (Wenn ich schon beim zitieren bin)

werden die auch immer schlampiger,

[...]

Meintest Du mit "schlampig" ungefähr sowas, oder gibt es noch 'ne Stilblüte?

Ob es eine Stilblüte ist, weiß ich nicht.
Da war z.B. mal der Fall, daß plötzlich einige Clients abkrachten, weil ein aufgerufenes Package mehr als 10 Parameter benötigte. BEi einer älteren Version des Clients gings, dann wieder nicht, dann gings bei einer neueren Version wieder(8.0.x). Irgenwann war Ruhe, aber ich denke, das wird sicherlich wieder mal auftauchen.
Oben genannter Freund hatte mal die Probleme mit SQL-Plus unter True64, daß quasi zufällig einige SQL-scripts coredumps produzierten. Irgendwo ein Leerzeichen dazu, und alles ging wieder.

Ist halt auch nur ein Stück Software. Warum sollen es die bei Oracle auch besser machen als alle anderen (inklusive meinereiner)

Grüße
  Klaus

[Cheatah]

Hi,

Schleife wie beschrieben, und dann:

Schleife mit SQL drin ist böse[tm].

select from TABELLE where kunde = 'id-soundso' and date = '2001-08-20' and parameter1 = 'dasunddas'

SELECT bla
FROM tabelle
WHERE kunde IN (1, 2, 3, ...)
AND date BETWEEN '2001-07-01' AND '2001-08-20'
AND parameter1 IN ('a', 'b', ...)
ORDER BY kunde, parameter1, date

Oder so ähnlich. Auseinanderpflücken, um welchen Kunden es sich handelt, kannst Du in der Programmlogik. Oder aber Du nutzt die GROUP BY Clause sinnvoll.

Vermutlich ist die Abfrage auf 'kunde' sogar unnötig.

Cheatah

[Reiner]

Hi,

Schleife wie beschrieben, und dann:

Schleife mit SQL drin ist böse[tm].

select from TABELLE where kunde = 'id-soundso' and date = '2001-08-20' and parameter1 = 'dasunddas'

SELECT bla
FROM tabelle
WHERE kunde IN (1, 2, 3, ...)
AND date BETWEEN '2001-07-01' AND '2001-08-20'
AND parameter1 IN ('a', 'b', ...)
ORDER BY kunde, parameter1, date

Oder so ähnlich. Auseinanderpflücken, um welchen Kunden es sich handelt, kannst Du in der Programmlogik. Oder aber Du nutzt die GROUP BY Clause sinnvoll.

Vermutlich ist die Abfrage auf 'kunde' sogar unnötig.

Super!

Danke, das hat mir ja schon geholfen!
Ok, dann war es schon auch mein Fehler (muß ich wohl zugeben)!!!
Werde dennoch auf eigenen Server umziehen.

Reiner

[Cheatah]

Hi,

Werde dennoch auf eigenen Server umziehen.

ich will Dir davon keinesfalls abraten; aber wenn Du Deine DB-Abfragen nicht optimierst verschiebst Du das Problem eigentlich nur von "Provider schaltet mich ab" zu "ich werde zwar nicht abgeschaltet, aber irgendwann funktioniert es halt nicht mehr" :-)

Cheatah

[donut]

MAchst du ein Join auf den Datenbanken oder schmeist du ersteinmal die Datenbanken wild mit nem Select * FROM a,b zusammen? Dann muß er erstemal die Kreuztabelle aufbauen.. udn dann rechne nochmal was da an Daten rauskommt...

Oder ist das etwa nur eine Tabelle?

Ja, ist nur eine.

Nebenbei.. wenn die db größer ist.. also verschiedenes enthält sollte man einzelne Tabellen wählen welche 1:n oder n:1 Beziehungen haben.

Ich mache folgendes:

Für jeden Kunden:
|_Für jeden Monat:
   |_Für jeden Tag:
     |_hole Daten, wo Kunde = "blablabla" UND parameter1 = "blablabla".....

Ich hoffe Du sortierst nicht das was aus der Datenbank kommt, sondern holst es dir schon mit nem Sort raus (geht schneller wenn die DB das macht)

Im Endeffekt komme ich also auf:

4 (Mai - August) * 30 (Tage) * 100 Kunden = Anzahl der Querys....

Nö. Wie ist die DB aufgebaut? Machst Du ein böses select * from bei dem er dann erst aussortiert?

Nein, kein Wildcard!

Schleife wie beschrieben, und dann:

select from TABELLE where kunde = 'id-soundso' and date = '2001-08-20' and parameter1 = 'dasunddas'

also doch ne Wildcard...

Select * From  - Du bekommst den ganzen Datensatz zurück an der Stelle an der der Kunde mit der Verknüpfugn steh und nicht nur einzelne Daten .

was Du machst ist jedesmal die komplette Datenbank durchzugehen.

Etwas besser (abe immer noch schlimm) wäre ein

Select * From TABELLE Where date > '2001-08-01' AND date < '2001-08-31' AND parameter1='dasunddas' ORDER BY kunde, date

Heraus kommt ein Feld was geordnet ist.

Auch möglich wäre es z.b. Eine Temp_Table zu schaffen auf der Du arbeitest.. die viel weniger Daten enthält und schneller und weniger arbeitsintensiv durchgearbeitet wird ( CREATE TEMPORARY TABLE temp_Tabelle SELECT * FROM Tabelle WHERE ...)

Du könntest auch mit Group by schon Ergebnisse gruppieren.. also die Arbeit des Scriptes danach vereinfachen..

[Reiner]

select from TABELLE where kunde = 'id-soundso' and date = '2001-08-20' and parameter1 = 'dasunddas'

also doch ne Wildcard...

Select * From  - Du bekommst den ganzen Datensatz zurück an der Stelle an der der Kunde mit der Verknüpfugn steh und nicht nur einzelne Daten .

nee, hatte mich verschrieben, meinte:

select count(ID) from TABELLE where kunde = 'id-soundso' and date = '2001-08-20' and parameter1 = 'dasunddas'

siehe auch andere Antwort direkt dadrunter!

[Klaus Mock]

Hallo,

d.h. vielleicht könnte man das besser zusammenfassen, aber dann habe ich ein anderes Problem, weil ich an ein CGI-Timeout beim sortieren der Arrays komme.

Vielleicht kannst Du uns sagen, was Du da genau machst, dann könnten wir vielleicht was effizenteres finden, denn ich glaube auch 12.000 Statements sind eine ganze Menge.
Da verstehe ich schon, wenn der Provider nicht mehr einverstanden ist.

Grüße
  Klaus

[Reiner]

Vielleicht kannst Du uns sagen, was Du da genau machst, dann könnten wir vielleicht was effizenteres finden, denn ich glaube auch 12.000 Statements sind eine ganze Menge.
Da verstehe ich schon, wenn der Provider nicht mehr einverstanden ist.

siehe Antwort zu DONUT

[Cheatah]

Hi,

denn ich glaube auch 12.000 Statements sind eine ganze Menge.

es ist das 12.000-fache des Notwendigen, um genau zu sein :-)

Ein einziges Statement mit vernünftiger ORDER BY Clause und ggf. sinnvoller Verwendung von IN würde absolut reichen.

Da verstehe ich schon, wenn der Provider nicht mehr einverstanden ist.

Ich auch :-)

Cheatah

[Reiner]

Ok,

danke an alle!

Fazit vielleicht:
Ich habe da etwas Mist gemacht, d.h. das Query war schrottig...
Für die Zukunft sollte ich mir vielleicht einen Satz (den ich gut fand) merken:

Selects in Schleifen sollte man nicht machen -> geht anders.
(sinngemäße Widergabe)

Ich habe mir gerade neue Farbpatronen besorgt, werde mal das ganze Manual von MySQL drucken und lesen....

Danke, Ihr habt mir sehr geholfen!

Reiner

[Lord Helmchen]

Seid gegrüsst!

Unsere Lordschaft sind amüsiert und erfreut zugleich; aus dem trotzigen "Meine-Anfrage-verrate-ich-nicht" und "der-Provider-ist-schuld" Trotzkopf ist ein selbstkritischer und lernfähiger Zeitgenosse geworden.

Ein Triumph des Forums! Hurra!

Lord Helmchen

[Reiner]

Hallo Lord,

Unsere Lordschaft sind amüsiert und erfreut zugleich; aus dem trotzigen "Meine-Anfrage-verrate-ich-nicht" und "der-Provider-ist-schuld" Trotzkopf ist ein selbstkritischer und lernfähiger Zeitgenosse geworden.

trotz meiner "Selbsterkenntnis" bzw. Eingestehung eines Fehlers, würde ich das so ungern stehen lassen.
Mit dem "Meine-Anfrage-verrate-ich-nicht" meinst Du sicher den Threat "ist der Oktober länger...". Das Problem war dort etwas anders gelagert, ich habe auch nicht gesagt, daß mein Query geheim ist, habe es ja auch mehrmals genannt...
Zu "der Provider ist schuld" möchte ich sagen, daß ich dennoch aus anderen Gründen nicht begeistert bin...

Ein Triumph des Forums! Hurra!

War doch angemessen, oder?
Ich kann in DB ja noch ein Anfänger sein, in anderen Themen auch nicht, aber das größte ist es vielleicht auch, einmal einen Fehler eingestehen zu können.

Reiner

[Lord Helmchen]

Seid gegrüßt!

Mit dem "Meine-Anfrage-verrate-ich-nicht" meinst Du sicher den Threat "ist der Oktober länger...". Das Problem war dort etwas anders gelagert, ich habe auch nicht gesagt, daß mein Query geheim ist, habe es ja auch mehrmals genannt...

Unsere Lordschaft sind von Stand, Rang und Namen! Wir verbitten uns diese widerwärtige, anbiedernde Anrede!

Ich kann in DB ja noch ein Anfänger sein, in anderen Themen auch nicht, aber das größte ist es vielleicht auch, einmal einen Fehler eingestehen zu können.

Interessant, daß er das sagt, denn im Lounge Forum haben unsere Lordschaft bei einer Erkundung zur Feststellung der Stimmung des Plebs einen auf das Zugeben von Dingen bezogenen Thread entdeckt - verblüffend, wie uns scheint, denn unsere Lordschaft vermeiden für gewöhnlich, diese dekadente Stätte des Müßiggangs des Forum-Pöbels zu betreten.

Lord Helmchen

[Klaus Mock]

Ich habe mir gerade neue Farbpatronen besorgt, werde mal das ganze Manual von MySQL drucken und lesen....

Gut in der Idee, und es freut mich, wenn bei der ganzen Aufregung etwas Positives rausgekommen ist.
Ob aber ca. 790 Seiten (PDF-Manual) drucken billiger ist, als sich ein gutes Buch (O'Reilly) zu kaufen, wage ich zu bezweifeln;-)

Grüße
  Klaus

[Reiner]

Ich habe mir gerade neue Farbpatronen besorgt, werde mal das ganze Manual von MySQL drucken und lesen....

Gut in der Idee, und es freut mich, wenn bei der ganzen Aufregung etwas Positives rausgekommen ist.
Ob aber ca. 790 Seiten (PDF-Manual) drucken billiger ist, als sich ein gutes Buch (O'Reilly) zu kaufen, wage ich zu bezweifeln;-)

Naja, muß ja nicht alles ausdrucken! :-)

Reiner

[donut]

Oder ein günstiges REv. Exemplar. gibt genug Versteigerer solcher Bücher im netz (Mediasell.de  manchmal Ebay.de usw.)