Seite 3 von 3
Verfasst: So 9. Jul 2006, 10:54
von jost
Code: Alles auswählen
/**
* compose debuginfo (hit/miss and execution time of caching)
* @var bool $cfgConCache['debug']
*/
$cfgConCache['debug'] = false;
So, jetzt geht es.

Verfasst: Sa 28. Okt 2006, 15:53
von flom
bei mir ist das ergebnis eher bescheiden: 1 sekunde statt vorher 2 sekunden. immerhin aber ich hatte mir mehr erwartet. getestet mit
http://www.iwebtool.com/speed_test . oder ist das ergebnis nicht reell? mir kommt die seite auch so nicht besonders schnell vor. bin bei 1und1.
Verfasst: Sa 28. Okt 2006, 16:55
von stese
bei 1und1 is eh hopfen und malz verloren - solange die db langsam ist, is wirklich alles langsam - da kann eine cache engine nur bedingt abhilfe schaffen, denn sobald irgendwo ne db-verbindung aufgebaut wird (und zwar ist das der fall bei den statistiken in diesem script) und die db ist lahm, bremst das alles aus. such dir am besten nen ordentlichen hoster. oder nen root bzw managed server wo du dir die dbs nicht teilen musst.
du kannst probieren die cache engine zu beschleunigen, indem du die beiden statistikverbindungen rausnimmst, dann werden die seiten aber nicht mehr contenido intern gezählt
Verfasst: Sa 28. Okt 2006, 19:06
von flom
stese danke für die info. da ich bereits durch 1und1 sowie google statistiken habe würde ich das gerne austesten. welche bereiche sind das mit der statistik?
abgesehen davon würde ich gerne auf einen solchen managed server zurückgreifen, da 1und1 nach mehrmaliger aufforderung immer noch nicht die DB in den griff bekommen hat. sind die managed server bei 1und1 denn ok? oder gibts da wieder ärger?
falls sie ok sind: bei derzeit ca 16.000 besuchern in nem OSC online shop sowie einem contenido mit läppischen 300 besuchern pro monat dürfte ein L64 reichen oder?
der hat:
AMD Athlon 64 3000+
1.024 MB DDR-RAM
2 x 80 GB Festplatte (RAID1)
5 Domains
vielen dank für die (hoffentlich weitergehende

) hilfe
Verfasst: Sa 28. Okt 2006, 19:26
von stese
probiere in der cms/includes/concache.php folgende setting:
Code: Alles auswählen
$cfgConCache['raiseonevent'] = array(
'beforeoutput' => array('/* some code here */'),
'afteroutput' => array($sStatCode, 'page_close();')
);
mal so zu schreiben
Code: Alles auswählen
$cfgConCache['raiseonevent'] = array(
'beforeoutput' => array('/* some code here */'),
'afteroutput' => array('/* nothing */')
);
vielleicht bringts was - wenn aber darüber hinaus noch eine db verbindung aufgebaut wird (kann das script jetzt nicht genau auswendig) wird das nicht helfen.
der server sollte reichen. und solange du wie gesagt allein bist und dir den server nicht mit hunderten bzw tausenden anderen teilen musst, ist alles besser als der derzeitige stand
Verfasst: Sa 28. Okt 2006, 19:56
von flom
ok danke. bestelle den server gerade

Verfasst: Fr 3. Nov 2006, 09:09
von flom
wahnsinnig schnell seit dem managed server L64... kann ich nur empfehlen!
http://www.muenkel.eu.
Verfasst: Do 21. Jun 2007, 15:11
von dampfradio
Danke xmurrix!
Habe meine Seite mit Hilfe des Caches von 6,2 auf 1,2 sek. "getuned".
Das ist beachtlich..
Frage an stese
Verfasst: Mi 29. Aug 2007, 20:10
von codefux
Hallo,
sind die hier beschriebenen Cache-Anpassungen im aktuellen Bundle contenido-4.6.15mr_070112 integriert?
Konnte im Changelog nichts darüber finden...
Verfasst: Do 30. Aug 2007, 16:35
von HerrB
Nein.
Gruß
HerrB
Ganzes Verzeichnis nicht cachen
Verfasst: So 13. Jan 2008, 17:50
von JochBec
Moin
Erstmal vielen Dank für das klasse Modul, funktioniert bei mir super!
Zwei Dinge krieg ich aber nicht hin:
Wie kann ich ganze Verzeichnisse am cachen hindern? Dort liegen so viele Seiten, daß es unsinnig wäre alle ids einzeln einzugeben und zu blocken. Gibts da ne Möglichkeit? Statt idart eben die idcat zu blocken?
Danke und Gruß!
gelöst!
Verfasst: Mo 14. Jan 2008, 09:31
von JochBec
Hallo -
Problem selber gelöst es geht indem man einfach aus der idart eine idcat macht. Der Code wäre also:
Code: Alles auswählen
// check if current article shouldn't be cached (by stese)
$sExcludeIdcats = getEffectiveSetting('cache', 'excludeidcats', false);
if ($sExcludeIdcats && strlen($sExcludeIdcats)>0) {
$sExcludeIdcats = preg_replace("/[^0-9,]/", '', $sExcludeIdcats);
$aExcludeIdcat = explode(',', $sExcludeIdcats);
if (in_array($GLOBALS['idcat'], $aExcludeIdcat)) {
$this->_bEnableCaching = false;
return;
}
}
Prima Geschichte
Verfasst: Di 15. Jan 2008, 11:27
von apicalart
Kompliment an die Beteiligten. Auch bei uns ist eine enorme Steigerung drin gewesen.
Hat einer eine Ahnung, ob denn etracker oder google analytics durch den Cache gestört wird?
Re: Prima Geschichte
Verfasst: Sa 16. Feb 2008, 15:38
von xmurrix
Hallo apicalart,
apicalart hat geschrieben:Hat einer eine Ahnung, ob denn etracker oder google analytics durch den Cache gestört wird?
das Caching sollte sich nicht auf auf das Tracking auswirken, das per JavaScript oder Trackingimages beim Client stattfindet. Eine gecachte Version der Seite enthält weiterhin den Code für etracker, Google Analytics und Co. und daher wird jeder Besuch und jeder Seitenaufruf - wenn möglich - protokolliert.
Gruß
xmurrix