Läuft alles einwandfrei. Es sind im Speziellen die Seiten, die mit
tt_products laufen.
Am Di., 29. Jan. 2019 um 20:25 Uhr schrieb Olivier Dobberkau <
olivier.dobber...@dkd.de>:
> On 28.01.19 11:21, Björn Hahnefeld wrote:
>
> > Was meint ihr dazu?
>
> Was sagt das depreciation log?
>
> RealUrl Con
On 28.01.19 11:21, Björn Hahnefeld wrote:
> Was meint ihr dazu?
Was sagt das depreciation log?
RealUrl Config?
Olivier
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Hallo Falk,
meine Lösung interpretiert sowieso das HTML mit jquery und baut den DOM neu:
https://hosdev.sub.uni-hamburg.de/
Jetzt muss ich nur noch die Stelle finden, wo ich es patche.
Danke für die Inspiration!
Rainer
Am 26.07.18 um 14:27 schrieb Falk Gebauer:
Hallo Rainer,
ja, sehe ic
Hallo Rainer,
ja, sehe ich auch als beste Lösung. Oder du schreibst die Facetten-Daten
ungerendert als JSON-Data in die Seite und renderst sie dann mit JS im Klienten.
Gruß Falk
> Am 26.07.2018 um 11:41 schrieb Rainer Schleevoigt
> :
>
> Hallo Falk,
>
> Du hast recht (klar), die Startseite
Hallo Falk,
Du hast recht (klar), die Startseite mit den Resultaten und den Acetten
braucht 1200, die Detailseite braucht 160 ms. Man müsste also die
Facetten über Ajax ausliefern.
Gruss Rainer
Am 26.07.18 um 10:49 schrieb Falk Gebauer:
Hallo,
ist die Seite mit der Typo3 Ext. solr realis
Hallo Falk,
viele Dank für Deine Nachfrage/Hilfe.
Nein, diese Seite ist mit https://github.com/subugoe/typo3-find gebaut.
Aber das Problem wird ähnlich sein. Es gibt eben auch Viewhelper für die
Facetten. Was könnte man tun?
Gruss Rainer
Am 26.07.18 um 10:49 schrieb Falk Gebauer:
Hallo,
Hallo,
ist die Seite mit der Typo3 Ext. solr realisiert? Ausgabe über das Solr Results
Plugin mit Fluid Template?
Und gibt es ein oder mehrere (ev. hierarchische) Facets mit einer grossen
Anzahl von Optionen?
Hintergrund: Das Results Plugin ist verständlicherweise nicht ‚cache'bar
(user_int),
Nachtrag.
admPanel per TypoScript einschalten
Dieter
Am 25.07.2018 um 11:18 schrieb Rainer Schleevoigt:
Hallo Mitstreiter,
ich bin erschüttert: das Ausliefern des HTML-Codes dauert ca. 1200 sec
(21kB Ladung).
Die Instanz besteht nur aus einer Seite, die lediglich einen Solr
Index abfragt
In TYPO3 hat sowas nichts zu suchen.
Man könnte ggfls die Tracefunktion von xDebug verwenden oder Blackfire
(kommerzieller Service) nutzen.
Mit besten Grüßen
Dieter
Am 25.07.2018 um 11:18 schrieb Rainer Schleevoigt:
Hallo Mitstreiter,
ich bin erschüttert: das Ausliefern des HTML-Codes d
Hallo,
vielen Dank an alle für die Vorschläge. Ich werde die probieren.
viele Grüße
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Hi,
die Startseite ist inkl. Binärmaterial per se schon einmal doppelt so
groß wie die Unterseite (2,x MB statt 1,xMB) und offenbar nicht gecached.
Grundlegend:
* Concatenate / Compress für JS und CSS nutzen
* Page-Caching aktivieren
* Ggf. Staticfilecache nutzen
* Bilder optimieren
* Wen
Es gibt einen 404 Fehler – diese Darei wird nicht gefunden:
https://www.isolde-richter.de/typo3temp/assets/css/sidebar
Nachzuvollziehen in z.B.: Chrome-> Developer Tools -> Netzwerk
viele Grüße
Birgit
> Am 09.03.2018 um 11:20 schrieb Stefan Padberg :
>
> Guten Tag,
>
> schau dir in so einem F
Guten Tag,
schau dir in so einem Fall das Laden der Seiten mal mit dem
Netzwerkanalysetool von Firefox oder chrome an.
Die Homepage braucht ca. 8 Sek., bis sie überhaupt antwortet. Dann geht
alles ganz schnell. Das deutet für mich darauf hin, dass sie nicht
gecached ist. Irgendeine Extension scha
Old-School:
Mein Deprecation-log schrieb mir kürzlich:
04-09-17 10:13: DatabaseConnection a.k.a. $["TYPO3_DB"] has been marked as
deprecated in TYPO3 v8 and will be removed in TYPO3 v9. Please use the newly available
ConnectionPool and QueryBuilder classes.
Am 04.09.2017 um 15:47 schrieb Ale
On Sat, 2015-07-25 at 09:26 +0200, Anton Kornexl wrote:
> Das Speichern dauert bei den CEs für ca die Hälfte der Seiten 1-2
> Minuten. Auf den anderen Seiten sind es 1-2 Sekunden.
[...]
> Das Problem muss bei einem der letzten Updates von
> myql/PHP/Typo3/Ubuntu verursacht worden sein.
[...]
Ich
Am 25.07.2015 um 09:26 schrieb Anton Kornexl:
Hat jemand ähnliche Erfahrungen gemacht oder kann mir jemand einen Tipp
zur weiteren Eingrenzung geben.
Hallo Anton,
hast Du denn mal in Deine Fehlerlogs geguckt? Denen sollte doch
irgendwas zu entnehmen sein.
Schöne Grüße,
Peter
--
http://func
Das Problem des langen Timeouts, um die Verbindung zu beenden, liegt an der
Einstellung des Apache.
Aufgrund von KeepAlive On mit 15 Sekunden wartet Typo3 6.2 bis diese
abgelaufen, auch wenn keine weiteren anfragen vom Client kommen.
Diese Einstellung war auch so für ältere Versionen konfigurier
Am 12.08.2014 23:38, schrieb Philipp Gampe:
Hi Hugo,
OK, dann wartet er erst einmal, ob er eine Sperre bekommen kann. Wenn die
Seitengenerierung länger als 30 Sekunden dauert, dann kommt ja auch "The
page is being generated."
@see 3358+
typo3/sysext/frontend/Classes/Controller/TypoScriptFrontend
Hi Hugo,
Hugo wrote:
> Naja, wenn ich mir das im AdminPanel ansehe und mir unter Typoscript die
> Renderingzeiten anzeigen lasse, fällt auf das die Verzögerung wohl immer
> bei folgenden beiden Einträgen auftritt:
> Get Page from cache
> Get Page from cache/Cache Row
>
> Anscheinend wird hier ja
Hi,
nein, wird anscheinend beides nicht unterstützt.
Naja, wenn ich mir das im AdminPanel ansehe und mir unter Typoscript die
Renderingzeiten anzeigen lasse, fällt auf das die Verzögerung wohl immer
bei folgenden beiden Einträgen auftritt:
Get Page from cache
Get Page from cache/Cache Row
An
Hi Hugo,
Hugo wrote:
> ja das ist korrekt. Dort ist simple eingestellt.
Evtl. kannst du ja mal flock oder semaphore ausprobieren. Aber bitte vorher
nachschauen, ob dein Server dies unterstützt.
Ggf. kann es passieren, dass lock Dateien jetzt zuverlässiger Sperren,
wodurch das Rendering von pa
Hi Philipp,
ja das ist korrekt. Dort ist simple eingestellt.
Gruß
Am 12.08.2014 18:37, schrieb Philipp Gampe:
Hi Hugo,
Hugo wrote:
Ist so ein Problem bereits bekannt? Könnte das ein Bug sein oder eher
ein Einstellungsproblem an meiner Installation?
Dies hört sich nach dem Locking-Framework
Hi Hugo,
Hugo wrote:
> Ist so ein Problem bereits bekannt? Könnte das ein Bug sein oder eher
> ein Einstellungsproblem an meiner Installation?
Dies hört sich nach dem Locking-Framework an. Schau mal im Install-Tool, was
unter [SYS][lockingMode] gesetzt ist. Ich denke mal simple.
Grüße
--
Phil
Hallo Jo,
danke fürs helfen, hat mich auf die richtige Fährte gebracht - eine
überdimensionierte Tabelle von yatse (eine Extension die indexed_search
ersetzen sollte, aus der Zeit, als indexed_search nicht mit der Volltextsuche
von mysql umgehen konnte). Leider ist die Extension nicht ausgerei
/Print Content 314 16998
/Print Content 314 16998
Wenn ich das richtig sehe, läuft das Parsen völlig normal ab, bis zu Print
Content - und hier verliert er dann fast 17 Sekunden. Stimmt meine
Interpretation? Wenn ich das auf meinem lokalen Testrechn
Hallo,
nach Update von 6.1.7 auf 6.2.4 musste ich leider feststellen, dass der
vollständige Seitenaufbau erheblich lange dauert. Dabei werden eigentlich die
Elemente zügig angezeigt.
Server Umgebung Ubuntu 12.04.4 LTS
Nach Aufzeichnung mit Wire Shark scheint das Verbindungsende der einzelnen
Hallo Andre,
ich kann dir nur sagen du bist nicht alleine. Ich teste aktuell
verschiedene Einstellungen, aber die Performance ist seit 4.5 erheblich
schlechter geworden.
Melde mich wenn ich was gefunden habe.
lg
Freddy
Freddy Tripold
http://www.tlog.at
"Wenn Du entdeckst, dass Du ein tot
Hat niemand einen Hinweis für mich, was das Problem sein könnte?
Gruß
Andre
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Hi Freddy,
Freddy Tripold wrote:
> Und wie machst du deine responsiven Menüs?
I.d.R. nur mit zwei Ebenen.
Und dann versuche ich auch unter 10 Einträge pro Ebene zu bleiben. Somit
habe ich meist <<100 Einträge insgesamt.
Responsive selbst kommt dann per CSS.
Grüße
--
Philipp Gampe – PGP-Key 0
Und wie machst du deine responsiven Menüs?
Freddy Tripold
http://www.tlog.at
"Wenn Du entdeckst, dass Du ein totes Pferd reitest, steig ab!"
(Weisheit der Dakota-Indianer)
Am 04.07.2014 15:11, schrieb Philipp Gampe:
Hi Simon,
Simon Würstle wrote:
Ein absoluter Performancekiller ist übrig
Hallo Joey,
es war alles auf custom gesetzt. Ich hab jetzt alles angepasst, aber
noch keine merkliche Veränderung. Muss ma da noch was machen?
Der Server ist managed, von dem her könnte ich alles einstellen
(lassen), nur was?
An einer Extensions wird die Backend Performance ja wohl nicht liege
Hi Simon,
Simon Würstle wrote:
> Ein absoluter Performancekiller ist übrigens ein HMENU mit mehreren Ebenen
> und expAll = 1. Beispiel: bei einem 4-stufigen Menü mit insgesamt ca. 150
> Seiten braucht eine ungecachte Seite 15-20 Sekunden bis diese gerendert
> ist. Da das beim Kunden natürlich all
[FE][activateContentAdapter] stand auf 0 und environment ist "production".
Ein absoluter Performancekiller ist übrigens ein HMENU mit mehreren Ebenen und
expAll = 1.
Beispiel: bei einem 4-stufigen Menü mit insgesamt ca. 150 Seiten braucht eine ungecachte
Seite 15-20 Sekunden bis diese gerendert
Am 03.07.2014 21:58, schrieb Freddy Tripold:
Hallo Leute,
ich habe massive Performance Probleme mit 6.2.3 bei der Wartung im BE
und auch bei der Ausgabe. 10 Sekunden Wartezeit beim Speichern sind eher
die Regel. Ist die Seite gecacht, geht die Ausgabe der Seiten ordentlich
flott, aber die Wartun
Hi Simon,
Simon Würstle wrote:
> Auch bei 6.2 Auftritten, welche kaum Extensions, wenig Menüs etc. haben
> ist die Ladezeit bei ungecachten Seiten absolut inakzeptabel.
Ist der Frontend Content Adapter für FAL an? Dann müssen nämlich jedes Mal
die FAL Datenstrukturen für potentiell alten TS Cod
Ich habe ähnliche Erfahrungen mit der 6.2 gemacht. Die Performance ist bei
ungecachten Seiten absolut inakzeptabel. Vor kurzem habe ich bei einem Auftritt
ein Update von 4.7 auf 6.2 gemacht. Hier die Durchschnitts-Messwerte jeweils
mit den exakt gleichen Systemvoraussetzungen (identischer Serve
Hi,
ich habe massive Performance Probleme mit 6.2.3 bei der Wartung im BE und
auch bei der Ausgabe. 10 Sekunden Wartezeit beim Speichern sind eher die
Regel. Ist die Seite gecacht, geht die Ausgabe der Seiten ordentlich flott,
aber die Wartung ist ein Drama und auch ungecacht, bzw. während des
Für mich hört es sich an, als ob dein Server zu wenig Arbeitsspeicher hat
und dann swappen muss.
Auch kann es sein, dass deine Datenbank überlastet ist.
Ja, genau. Der VServer hat zu wenig Arbeitsspeicher und ist überlastet.
Außerdem nur einen CPU-Core. Und das Frontend ist noch nicht mal das
Hi,
wenn du viele "statische" Seiten hast, kannst du noch nc_staticfilecache
verwenden, da werden dann die Seiten lokal in dateien gecacht und via
mod_rewrite ausgeliefert. (TYPO3 wird also nicht gestartet)
Nachteil ist, dass zeitlich gesteuerte Freigaben nicht mehr klappen,
wenn man nicht z.B. n
Hi Mikel,
Mikel Wohlschlegel wrote:
> Ich greife auf eine bestimmte Seite zu, die keine Ext hat, die das
> Caching deaktiviert. Sonstige Bestandteile sind nur noch ein Bild und
> ein Text mit Bild.
Nutzt du noch PHP 5.2.x? PHP 5.3.x ist deutlich schneller.
>> Dein TS kannst du mit Hilfe des Templ
ich habe ähnliches Problem mit meiner Typo3 Installation. Wenn ich
mein cache no_cache=1 geth gar nichts mehr.
Kannst Du mir beschreiben, was Du gemacht hast um dein Typo3 zu
verbessern.
Was hast Du denn genau für Server Specs? Was für ein OS, was für ein
Webserver, memory_limit, etc? Ge
Am 03.05.11 00:22, schrieb Mikel Wohlschlegel:
Habe es rausgefunden. Eine völlige Fehlkonfiguration des Apache. Der
Cache war in Ordnung. TYPO3 war also nicht daran schuld (oder zumindest
nicht direkt).
schon wieder bzw. immer noch bin ich dabei, die TYPO3-Seiten auf
meinem VServer etwas perfor
Habe es rausgefunden. Eine völlige Fehlkonfiguration des Apache. Der
Cache war in Ordnung. TYPO3 war also nicht daran schuld (oder zumindest
nicht direkt).
schon wieder bzw. immer noch bin ich dabei, die TYPO3-Seiten auf
meinem VServer etwas performanter zu machen. Ein paar Benchmarks haben
d
Erstmal natürlich danke für Deine Antworten.
Dies ist ein häufiges Problem. Extensions können den Cache deaktivieren.
Außerdem kann es sein, dass irgendwo *_INT TS Objekte sind. Diese verhindern
zumindest teilweise das Caching.
Ich greife auf eine bestimmte Seite zu, die keine Ext hat, die das
C
Hallo Mikel,
Mikel Wohlschlegel wrote:
> Hallo zusammen,
>
> schon wieder bzw. immer noch bin ich dabei, die TYPO3-Seiten auf meinem
> VServer etwas performanter zu machen. Ein paar Benchmarks haben die
> ernüchternde Anzahl von 3,6 Zugriffe pro Sekunde ergeben (gemessen per
> Apache Benchmark m
Hi Steffen,
danke für die Ausführungen. Ich habe dann beim scriptmerger wohl was
verdaddelt, denn der hat mir nicht alle css und js in eine zusammengefasst,
sondern nur einzelne comprimiert, aber leider nicht alle. Werde bei
nc_staticfilecache gleich noch vorbeisteuern und mal schauen ob ich damit
*nc_staticfilecache.
Gestern wurde übrigens die Version 2.3.2 von nc_staticfilecache getaggt
- im TER aber offensichltich noch nicht veröffentlicht.
Ich würde dir sehr anraten, gleich diese Version zu verwenden - da hat
sich wieder einiges getan:
http://forge.typo3.org/repositories/show/ex
Hi Domi,
Ich habe für das Backend eine compression von 7 eingestellt und ich merke
einen enormen Performanceboost. Nur mit TRUE lädt er bei mir definitiv das
Backend nur enorm zerschlagen und ohne Funktionalität.
okay, dann muss ich das mal testen.
Nur im Frontend komm ich nicht so recht weit
Hallo Steffen,
Ich habe für das Backend eine compression von 7 eingestellt und ich merke
einen enormen Performanceboost. Nur mit TRUE lädt er bei mir definitiv das
Backend nur enorm zerschlagen und ohne Funktionalität.
Nur im Frontend komm ich nicht so recht weiter. Habe folgendes von TYPO3
auspr
On 08.09.10 03:34, Domi Garms wrote:
Ich muss mich selbst noch kurz berichtigen:
$TYPO3_CONF_VARS['BE']['compressionLevel'] = 'true' funktioniert nciht, aber
ein int Wert wird akzeptiert und funktioniert auch richtig gut.
Hi,
okay, das beruhigt mich zu hören.
TRUE ist früher mal offiziell erla
Ich muss mich selbst noch kurz berichtigen:
$TYPO3_CONF_VARS['BE']['compressionLevel'] = 'true' funktioniert nciht, aber
ein int Wert wird akzeptiert und funktioniert auch richtig gut.
Am 8. September 2010 09:20 schrieb Domi Garms :
> Guten Morgen,
>
> ich wollte mich mal grundsätzlich über die
51 matches
Mail list logo
