Verbesserungsoptionen von Sefrengo gegenüber Dedi Einstellungen

[kalesco]

Hallo!

Manche kennen mich vielleicht schon vom dedi Forum.
Mein beinahe letzter Beitrag dort beschäftigte sich mit den massiven Performanceproblemen die ich mit dedi mit einer zugegeben eher großen und komplexen Seite hatte.

Wir ( ein Kollege und ich, Eppi & Co waren ja keine Hilfe ) haben dann ein Profiling durchgeführt um herauszufinden wo die Zeiten draufgehen.
Das Ergebnis war dass das mod-rewrite viel Rechenzeit verpulvert indem bei jedem Seitenaufruf die Navigation erstellt wird und dieses Array dann auch noch für das rewrite mit Stringfunktionen umgeschrieben wird.
Bei 1000 plus Seiten sind das recht viele Rechenoperationen und dort wurde viel Zeit liegen gelassen.
Unser Lösungsansatz dafür war, den rewrite Namen (also eine bereinigte Version des Seitennamens) direkt in die Tabelle mitzuspeichern. Jetzt gibt es dort ein Feld modrewrite_name und nur wenn das leer ist werden die üblichen Berechnungen durchgeführt und dann auch gleich reingeschrieben.

Weiters ist das Cachesystem von dedi relativ unbrauchbar. In der Tabelle x_code werden zwar die aufgerufenen (nicht geänderten) Seiten gespeichert, allerdings nicht als HTML sondern mit dem PHP Code aller Module. Nun muss dieser Code erst wieder ausgeführt werden, inklusive aller Datenbankabfragen, die in Modulen eben so vorkommen (Navi etc).
Wir haben eine neue Tabelle erstellt die rein das Endoutput vom CMS (reines HTML, kein PHP mehr, keine DB Abfragen) speichert. Bei einer Änderung irgendeiner Seite wird die Tabelle geleert (die gesamte, da sich ja die Navigation geändert haben könnte) und dann wieder neu aufgebaut.
Das ist zwar keine tolle Lösung, aber wenn einmal am Tag was geändert wird, ist die Seite auch "nur" einmal am Tag relativ langsam, wenn die Seite erstmal im Cache ist (nach dem ersten Aufruf) dann geht alles eigentlich ganz fix.

Ein weiteres Problem war inode (österreichischer Provider) und ein Flaschenhalssystem. Zur Mittagszeit wurden Spitzen-Ladezeiten von 20 sek erzielt. Als Zwischenlösung wurde die Seite nun auf einen unserer eigenen Server kopiert. Nun sind wir nat. auf der Suche nach einem neuen CMS und ich werde mir Sefrengo genau anschauen.
(Weiteres inode Problem: safe mode = on)

Nach dieser langen Erklärung ein paar Fragen dazu:
x) wie sieht es mit dem mod-rewrite von Sefrengo aus?
x) wie cacht Sefrengo?
x) wie schauts mit safe mode = on aus?

Beziehungsweise: könnte es sein, dass solche Änderungen in eine offizielle Sefrengo Version einfließen? Durch unsere Änderungen im Core von dedi kann ich nun keine (Security-) Updates oder Ähnliches mehr einspielen... bzw. wird es sehr sehr kompliziert.

Noch was: ich habe für mein dedi-Projekt einen aufgebohrten Dateimanager gehackt... Interesse?


Nun gut, ich muss Sefrengo erst ausprobieren, aber schön dass ihr es geschafft habt mit dem Release! Auf das hübsche neue Layout warte ich dann noch

LG
kalesco

[alexander]

Ein weiteres Problem war inode (österreichischer Provider) und ein Flaschenhalssystem.

hatte ich dir ja schon damals im dedi forum gesagt das die inode systeme generell für (cms) system mit vielen DB-Abfragen nicht zu gebrauchen sind.

auch noch für das rewrite mit Stringfunktionen umgeschrieben wird.
Bei 1000 plus Seiten sind das recht viele Rechenoperationen und dort wurde viel Zeit liegen gelassen.

tja, das war schon länger bekannt ... steht glaub ich auch einige male im dedi forum

Wir haben eine neue Tabelle erstellt die rein das Endoutput vom CMS (reines HTML, kein PHP mehr, keine DB Abfragen) speichert. Bei einer Änderung irgendeiner Seite wird die Tabelle geleert (die gesamte, da sich ja die Navigation geändert haben könnte) und dann wieder neu aufgebaut.

einfach und performanter ist aus meiner sich einen cache wie http://eaccelerator.net/ zu verwenden. so hab ich das bei einer sefrengo site gemacht die weit mehr als 1000 seiten im system hat. das funktioniert super ...

wie sieht es mit dem mod-rewrite von Sefrengo aus?

da hat sich einiges geändert. es ist das neue modrewrite 2 hinzugekommen, das aber auch wieder mehr rechenzeit braucht

wie cacht Sefrengo?

im prinzipt noch so wie sein vorgänger. allerdings hat björn bereits begonnen für die navigations arrays eigenen klassen zu schreiben, welche auch ein anderes wesentlich performanteres caching mitbringen. sobald die api dafür fertig ist, können dies dann auch die module (wie z.B. die naviagtion) verwenden. d. h. aber auch, dass man alle module entsprechend anpassen muss. wann das fertig ist kann ich dir aber nicht sagen.

wie schauts mit safe mode = on aus?

genauso wie bei jeden anderen (cms) php system, weil das daran liegt wie gut dein provider den safemode konfiguriert hat und nicht am cms system selbst.

nachtrag: neben den arrayproblem liegt es auch of daran, dass mache module wesentlich performanter laufen könnten, wenn man sich die zeit nimmt und sie optimiert. bestes beispiel der neue contentflex von mistral. in der aktuelln version für sefrengo wurden die db abfragen auf unter 10 gesenkt, sein vorgänger brauchte dafür noch ca. 80

Der Beitrag wurde von alexander bearbeitet: Mon. 3. July 2006, 14:16

[kalesco]

na gut, das schaut für mein projekt dann ja leider noch nicht so toll aus.

ein provider wechsel ist im moment keine option, das entscheidet der kunde, nicht ich. (hatte ich auch schon im dedi forum gesagt )

irgendein tool zum cachen zu verwenden ist auch schön und gut, allerdings sollte das meiner meinung nach schon das cms mitbringen (bei typo3 kann man zb statische seiten exportieren, das verlangt zwar niemand von sefrengo, wär aber auch ein ansatz).
bin auf inode angewiesen und was sie mir an systemen bieten. und wenn ich nix installieren kann, nutzen mir alle tools der welt nix.

tja. schade eigentlich.

kann man anscheinend gar nix machen.

eine weitere anregung hätt ich noch ( ich weiß ich bin lästig ): eine suche die auch dateien findet (titel und beschreibung gibt es ja im ressourcenmanager oder wie das jetzt heißt).

[bjoern]

Die Performanceprobleme bei großen Seiten sind mir bekannt und hängen nach wie vor an den $con_side und $con_tree Arrays.

Ich habe angefangen, das Problem anzugehen, indem ich die Generierung der Arrays in Klassen gepackt habe, wo ich auch ein verbessertes Caching implementiert habe. Das löst das Problem aber auch nur teilweise, nach wie vor kann es, je nach Hardware und nicht vorhandenen Tuningspezialwissen, Performanceengpässe ab PI* Daumen +400 Seiten geben.

Das Problem bei den Arrays ist, das die quer durchs ganze System (kleines Problem) und vielen Modulen (großes Problem) benutzt werden. Eine Änderung des Systems würde also einen gehörigen Rattenschwanz an Arbeit nach sich ziehen.

Mein Lösungsansatz ist die Erweiterung der PageInfo und CatInfo Objekte um getXY() Methoden, die bei Aufruf nur die benötigten Informationen generieren. Gleichzeitig müssen die Objekte einen Switch bieten, wo angegeben werden kann, ob alle Informationen generiert werden (alles wie bisher, bei großen Seiten schlechte Performance, dafür abwärtskompatibel) oder ob die Daten nur geladen werden, wenn sie von den get Methoden gefordert werden (gute Performance bei großen Seiten, dafür fliegen einen nicht angepasste module um die Ohren).

Das gibt zum einen die Möglichkeit der Abwärtskompatibilität, zum Anderen können Module angemessen migriert werden, ohne das User, die leider keine speziellen PHP Kentnisse haben, vor einen Seitenscherbenhaufen stehen.

Wenn Du Interesse an solchen Anpassungen hast und auch durchführen willst, melde Dich bitte bei mir. Dann können wir das gerne koordinieren. Ich selbst kann Dir da konzeptionell zur Seite stehen, habe aber für die nächsten Monate sicher gut damit zu tun, jede Menge andere Sefrengo- Baustellen zu beseitigen, kann daher die Änderungen nicht programmieren.

Bei Inode kann ich Dich verstehen, da hatte ich auch ziemliche Probleme mit einer Seite. Die Konfiguration des safe_mode ist aber wirklich eine Sache, die die Provider lösen müssen und wo man mit PHP Boardmitteln fast nichts reißen kann. Ein vernünftig konfiguriertes System funktioniert auch mit safe_mode = off ohne Einschränkungen.

Zu Deinen Fragen:

x) wie sieht es mit dem mod-rewrite von Sefrengo aus?
Die Strings liegen in der DB. Der Pfad zu einer aktuellen Seite wird aus diesem zusammengebaut. Bei der automatischen Generierung wird der rewritestring aus den Ordnern und Seiten dynamisch zusammengesetzt . Also für "ordner1/ordner2/seite.html" einmal in den $con_side gehen, dann zwei mal in den $con_tree. Manuell eingegebene Seiten brauchen nur eine Abfrage aud den $con_side Array.

x) wie cacht Sefrengo?
Genau so wie damals. Hinzugekommen ist die Klasse DbCache im Package UTILS. Die Klasse wird benutzt zum cachen der con_tree und side Arrays. Das bringt gegenüber dem Vorgängersystem Performancegewinne und stellt nach meiner Meinung das äusserste an Performancesteigerung dar, was mit dem derzeitigen System möglich ist.


x) wie schauts mit safe mode = on aus?
Wie oben gesagt, funktioniert, wenn der Provider den Server ordentlich konfiguriert.


Änderungen, die vernünftig implementiert sind, die Systemstabilität und abwärtskompatibilität nich gefährden, fließen in das System ein. An Hacks habe ich aber kein Interesse. Ich habe alle Hände damit zu tun, die vorhandenen alle zu killen.

[kalesco]

danke für die ausführliche antwort, das hilft mir schon mehr weiter

wegen safe mode: naja, kann man halt nix machen, inode weigert sich da was zu machen. bzw. wird behauptet das joomla einwandfrei läuft, nur ich konnte kein plugin für dedi installieren. da hab ich dann meine sachen nur noch über module abgebildet. geht auch.

und wegen den hacks: naja, es ist schon sauber programmiert, so ists nicht. aber es ist halt ein eingriff in einige dedi core dateien notwendig gewesen. und da das nun mal nicht vorgesehen ist (open source + dedi...pfff) bezeichnete ich es als hack.

es gibt ganz einfach mehr felder im dateimanager für die annotierung einer datei:
beschreibungsfeld das größer ist und bbcode kann,
untertitel, quelle und autor. in arbeit ist mehr oder weniger noch eine anbindung an ein schlagwort system...
alles nur änderungen im formular, der tabelle und in der sprachdatei.

inkl. des performancetunings hab ich mir ja beinahe schon meinen eigenen fork gebastelt

[alexander]

irgendein tool zum cachen zu verwenden ist auch schön und gut, allerdings sollte das meiner meinung nach schon das cms mitbringen (bei typo3 kann man zb statische seiten exportieren, das verlangt zwar niemand von sefrengo, wär aber auch ein ansatz).
bin auf inode angewiesen und was sie mir an systemen bieten. und wenn ich nix installieren kann, nutzen mir alle tools der welt nix.

bitte nicht falsch auffassen, aber warum hast du dann eigentlich für dein projekt dedi verwendet? das das system mit einer solchen anzahl an seiten ein problem hat war ja schon lange bekannt. zumindest meine ich mich zu erinnern, dass dies von beginn an immer wieder diskutiert und bemängelt wurde.

die einschränkungen wirst du auch noch einige zeit mit sefrengo haben, denn die ursachen dafür liegen so tief im system und den modulen verankert, dass man dies nicht von heute auf morgen ändern kann. das wir es ändern müssen ist uns bewußt - konzepte dazu gibt es teile davon befinden sich schon in der beta 1.

eine weitere anregung hätt ich noch ( ich weiß ich bin lästig ): eine suche die auch dateien findet (titel und beschreibung gibt es ja im ressourcenmanager oder wie das jetzt heißt).

eine aufgabe des resourcebrowser ist einen einheitlichen auswahldialog bereitzustellen. aktuell kann man damit dateien (bilder) und interne links auswählen. Er ist über eine api ins system integriert und kann damit einfach erweitert werden um künftig z.b. gruppen oder benutzer auszuwählen.

bei der dateienauswahl zeigt er dir eben auch die beschreibung an, wenn du sie im dateimanager erfasst hast, mit der suche hat dies nichts zu tun.

damit die suche datein des dateimanagers findet, müßte man das suchmodul entsprechend erweitern. eventuell findet sich ja jemand der dies übernehmen möchte.

ein suche die auch dokumente im volltext erfaßt wird es so schnell als eigenständiges modul glaub ich nicht geben. dafür gibt es ja auch andere/externe tools die das besser können. tigger aus dem dedi forum hatte mal so eine externe suche mit einem kleinen modul integriert.

[kalesco]

die seitenanzahlproblematik wurde mit der aussage 1000 seiten plus verkraftet das system bei 4-5000 könnte es haarig werden, oder so ähnlich abgetan. naja.

den resourcebrowser hab ich dann falsch verstanden sorry.

dass man die suche erweitern müsste ist mir klar. genau das wollte ich doch nur mal gesagt haben

aber ich verstehe dass ihr momentan im stress seid und euch auf feature requests nicht einlasst.
ich würde ja aushelfen wenn ich könnte, glaub aber nicht dass das meinem arbeitgeber gefallen würde.
und meine freizeit verbringe ich internet- und pc-los.

[alexander]

die seitenanzahlproblematik wurde mit der aussage 1000 seiten plus verkraftet das system bei 4-5000 könnte es haarig werden, oder so ähnlich abgetan. naja.

den der diese aussage getroffen hat sollte man bitten alle 1-3999 seiten einer solchen site einmal zu öffen und z.b. in den metadaten author und keywords neu einzugeben. das wäre eine gerechte strafe.

habt ihr euch schon mal überlegt einen caching proxy vor die site zu schalten um die last zu veringern? dann könnte auch der server bei der inode bleiben.

und zum schmunzeln: als inode ihre eigenen webauftritt vor einiger zeit mit typo3 relauncht haben, haben sie vergessen das caching aufzudrehen und die site war in kürzester zeit platt und nicht mehr zu erreichen.

Der Beitrag wurde von alexander bearbeitet: Mon. 3. July 2006, 15:09

[bjoern]

aber ich verstehe dass ihr momentan im stress seid und euch auf feature requests nicht einlasst.

Finde ich ein wenig unglücklich formuliert. Meine Formulierung wäre:

Auf Feature Requests lassen wir uns gerne ein. Wir können konzeptionelle Hilfe anbieten, Programmierarbeiten am System können wir aber meistenteils nicht leisten. Vorne Feature Request reinschmeissen und nach X Tagen hinten Feature rausziehen funktioniert leider nur gelegentlich bei Grimms Märchen. Wenn Ihr ein Feature haben wollt, müßt Ihr dann schon selber aktiv werden oder jemanden kennen, der es macht. Wir sind das Jahr sicher noch genug damit beschäftigt, den Sefrengo Quellcode aufzuräumen. Ist leider so. Haben ja auch nur zwei Hände oder "Wer fordert, muß auch leisten".

[kalesco]

ja, stimmt, ist unglücklich formuliert! tut mir leid!

[STam]

Wir haben eine neue Tabelle erstellt die rein das Endoutput vom CMS (reines HTML, kein PHP mehr, keine DB Abfragen) speichert. Bei einer Änderung irgendeiner Seite wird die Tabelle geleert (die gesamte, da sich ja die Navigation geändert haben könnte) und dann wieder neu aufgebaut.

... nur noch eine schnelle Frage/Antwort.
Die Vorgeschlagene Änderung impliziert doch das die Seiten keinen dynamischen <DEDIPHP/> Content mehr beinhalten bzw. das das eben nicht mehr funktioniert, Richtig?

Wenn [JA]:
Warum dann überhaupt noch in die dB, die Entscheidung das in der dB zu halten verstehe ich nicht ganz?
Warum nicht einen Datei-Cache ala Mediawiki?
Ist das in in der Lösung konfigurierbar, werden alle Seiten gecacht oder kann es Ausnahmen geben?

Bemerkung:

inkl. des performancetunings hab ich mir ja beinahe schon meinen eigenen fork gebastelt

... eher ein Downgrade der Funktionalität denke ich

Wenn [Nein]: Erklärungsbedarf!

irgendein tool zum cachen zu verwenden ist auch schön und gut, allerdings sollte das meiner meinung nach schon das cms mitbringen (bei typo3 kann man zb statische seiten exportieren, das verlangt zwar niemand von sefrengo, wär aber auch ein ansatz).

... hmm,
eAccelerator und Zend-Optimizer sind nicht irgendwelche Tools und können schon gar nicht von einem CMS oder ähnlichem 'mitgebracht' werden.
Zumal explizit bei Typo3 und auch anderen Systemen wie Wiki's (Beispiel wieder Mediawiki) sogar eine extra Unterstützung für diese Tools implementiert ist oder empfohlen wird.
Das Thema 'statische Seiten' erschlägt dein Vorschlag (mit den einhergehenden nachteilen) doch ganz gut.
Bei dynamischen Content bleibt ein Einsatz dieser Tools eben nicht aus.

Gruss

[kalesco]

... nur noch eine schnelle Frage/Antwort.
Die Vorgeschlagene Änderung impliziert doch das die Seiten keinen dynamischen <DEDIPHP/> Content mehr beinhalten bzw. das das eben nicht mehr funktioniert, Richtig?

hm. wenn eine seite editiert wurde wird der cache gelöscht. bei aufruf einer seite kommt genau dieser html output dann nicht nur am bildschirm des users an sondern wird auch in die db als cache geschrieben. solange sich nichts ändert bleibt dieser cache dann bestehen. die seiten sind zwar dynamisch aber es gibt jetzt nicht unbedingt mehr als eine änderung pro tag... dann bringt das schon einen performance gewinn.

Wenn [JA]:
Warum dann überhaupt noch in die dB, die Entscheidung das in der dB zu halten verstehe ich nicht ganz?
Warum nicht einen Datei-Cache ala Mediawiki?
Ist das in in der Lösung konfigurierbar, werden alle Seiten gecacht oder kann es Ausnahmen geben?

da ist nichts konfigurierbar, deshalb die bezeichnung hack. man könnte das nat. erweitern und in den config values in der db speichern und auslesen, es wurde aber eine schnelle lösung gebraucht.

Bemerkung: ... eher ein Downgrade der Funktionalität denke ich
Wenn [Nein]: Erklärungsbedarf!

naja. für uns ist das kein downgrade.
funktionalität des dateimanagers wurde ganz klar erweitert! dass der modrewrite name in der db steht ist auch eine erweiterung und kein downgrade meiner meinung nach.
und dass mit dem cache ist einfach eine andere art das zu handlen als es momentan bei dedi der fall ist.

... hmm,
eAccelerator und Zend-Optimizer sind nicht irgendwelche Tools und können schon gar nicht von einem CMS oder ähnlichem 'mitgebracht' werden.
Zumal explizit bei Typo3 und auch anderen Systemen wie Wiki's (Beispiel wieder Mediawiki) sogar eine extra Unterstützung für diese Tools implementiert ist oder empfohlen wird.
Das Thema 'statische Seiten' erschlägt dein Vorschlag (mit den einhergehenden nachteilen) doch ganz gut.
Bei dynamischen Content bleibt ein Einsatz dieser Tools eben nicht aus.

gut dann sind es nicht irgendwelche tools, aber mir nützen sie nix da ich nichts installieren darf und das der provider auch einfach nicht macht. also was soll ich dann damit? dass es sie gibt ist ja eh ganz toll wenn man einen dezidierten server hat.
und zum dateicache eines wikis... hab mich damit nicht beschäftigt, werde ich noch machen (danke für den tipp) aber es musste eine rasche lösung her.

was soll ich machen?! das sind die probleme die wir hier hatten/haben und unsere lösungen. ich wollte damit nicht anregen das Sefrengo das gleich machen muss oder soll. sondern lediglich vielleicht ideen einbringen, bzw. auf die dedi spezifischen missstände hinweisen.

[bjoern]

ich wollte damit nicht anregen das Sefrengo das gleich machen muss oder soll. sondern lediglich vielleicht ideen einbringen, bzw. auf die dedi spezifischen missstände hinweisen.

Hab ich auch so aufgefasst. Die Beseitigung des Problems sehe ich auch als sehr wichtig an. Geht von meiner Seite nur leider zur Zeit nicht.

[amk]

Wir haben eine neue Tabelle erstellt die rein das Endoutput vom CMS (reines HTML, kein PHP mehr, keine DB Abfragen) speichert. Bei einer Änderung irgendeiner Seite wird die Tabelle geleert (die gesamte, da sich ja die Navigation geändert haben könnte) und dann wieder neu aufgebaut.
Das ist zwar keine tolle Lösung, aber wenn einmal am Tag was geändert wird, ist die Seite auch "nur" einmal am Tag relativ langsam, wenn die Seite erstmal im Cache ist (nach dem ersten Aufruf) dann geht alles eigentlich ganz fix.

die frage die sich mir dabei stellt : wozu dann noch eine datenbank nutzen ... dann könnte man sämtliche seiten auch als statische html-pages auf dem server ablegen, die sich je nach veränderung neu generieren. so haben wir's damals mit einer cms-agentur-eigenentwicklung gehalten ... und all der umstand mit mod-rewrite etc. war kein thema.

dies nur mal so nebenbei ...

Der Beitrag wurde von amk bearbeitet: Thu. 6. July 2006, 01:02

[kalesco]

die frage die sich mir dabei stellt : wozu dann noch eine datenbank nutzen ... dann könnte man sämtliche seiten auch als statische html-pages auf dem server ablegen, die sich je nach veränderung neu generieren. so haben wir's damals mit einer cms-agentur-eigenentwicklung gehalten ... und all der umstand mit mod-rewrite etc. war kein thema.

dies nur mal so nebenbei ...

statische seiten wären nur eine lösung wenn sie vom cms aus generiert werden könnten. ein cms ist notwenig! statische seiten (viele viele tausend, da viele seiten durch module befüllt werden, die je nach get parametern anders befüllt werden. zb übersichtsseite von ca 1000 bildern!)

daher unsere zwischenlösung, die ich durchaus für gerechtfertigt halte.
cms natürlich auch deswegen weil redakteure die seiten aktuell halten! - ist ja klar.

[amk]

statische seiten wären nur eine lösung wenn sie vom cms aus generiert werden könnten.

was ich ja damit sagen wollte. ihr habt die fertig generierten seiten (somit statischen) in der db-abgelegt (oder hab ich das falsch verstanden) ... insofern: warum in der db und nicht als html-file auf dem server ... aber egal ...

[alexander]

ich stelle jetzt nochmal die frage: warum verwendest du keinen caching proxy der die last vom inode sever nimmt. da brauchst du nix auf deinem inode account ändern (bis auf den DNS Eintrag) und hast das problem auf jeden fall für das frontend gelöst. ist zwar nicht optimal, aber auf jeden fall sehr skalierbar. die kosten/der aufwanf für diese lösung sind ja im vergleich für die schwere, welche das problem laut deinen aussagen für dich darstellt, eigentlich gering. ein anderer lösungsweg fällt mir unter den für dich geltenden randbedingungen nicht ein.

[saschapi]

@alexander or @all:
Kann mir nicht so technisch versiertem (was Netzwerktechnik etc angeht) mal jemand erklären was es mit dieser Proxylösung auf sich hat? Interessiert mich einfach mal so

[amk]

@alexander or @all:
Kann mir nicht so technisch versiertem (was Netzwerktechnik etc angeht) mal jemand erklären was es mit dieser Proxylösung auf sich hat? Interessiert mich einfach mal so

also ich bin ja auch "all" und auch "alexander" ... *ggg* ... aber ich weiss es auch nicht so genau ... wikipedia ist bzgl. technik aber ein großer fundus an infos. so ist inode z.b. auch ein österreichischer Internet Service Provider

grundlegend kann aber gesagt werden : man muss auf keinen fall alles wissen und begreifen. ich persönlich finds toll wenn dinge einfach nur funktionieren warum auch immer

[alexander]

eigentlich müsste man von einem reverse caching proxy sprechen. einer der bekannteren vertreter ist squid.