Data, která se ukládají do cache prochází nějakou kompresí, ale kupodivu když před uložením smažu prázdné znaky (tj řádkování, tabulátory apd) ve výsledku data zaberou méně dat v cache. Je to např 10,3kB a po smazání bílých znaků 10,09kB. Tedy -2% dat. Jestli to má smysl?

5GB cache, průměrně 4,55GB dat -2% tj cca 93MB úspora místa. Bohužel se to vůbec nemusí projevit. Efekt to bude mít jen na pár položkách, které díky tomu spadnou do menšího SLABu, kde se jich vejde víc.

Ale co, je to maličkost. Zkusím.

Zjistil jsem, že používám Memcached ve verzi z roku 2018. Tedy dva roky starou a od té doby se událo  mnoho užitečných změn. Bohužel v balíčku Linuxu je jen tato stará verze tj 1.5.6. Pro skutečné linuxové administrátory je brnkačka si takový program aktualizovat, ale pro mě zrovna ne. Vyznám se ve webech, ale na serveru to je pro mě všechno nové.

tady je skromný návod, jak na linuxu aktualizovat memcached:

1) zjistit, kde je Memcached nainstalovaný na serveru: Which memcached

v mém případě v /usr/bin/memcached

2) stáhnout si balíček s novou verzí (stáhne se tam, kde zrovna jste - příkaz PWD vám to řekne)
wget https://memcached.org/files/memcached-1.6.9.tar.gz

Zrovna tohle jsem potřeboval řešit asi před 3 dny. Chvíli mě to potrápilo. Standadt HTML velí, že vše co jde do TEXTAREA dostane překlad entid. Takže neuvidíte žádné & lt; & gt;  & amp;  apd. Vždy rovnou <>&. Což je trochu problém, když potřebujete text editovat a uložit zpět do databáze a on se změní a zruší entity. Ani není možné si překlad udělat sám, protože nejde poznat co je přeloženo a co už bylo... ale jde to vyřešit!

Návod jsem na internetu nenašel. Takže můj postup je následující.
1) data nejprve opatřím mezerou za znakem & a tím vyřadím z provozu dekodování entit.
2) nechám zobrazit v TEXTAREA
3) javascriptem mezeru zase umažu a nezapoměnu, že se mi nahradil & za &

Včera jsem zprovoznil cache na serveru #1 tj mj pro nápovědy. Vybral jsem 3 nejvíce navštěvované. Tedy https://www.mojepixwords.cz/napoveda/, www.pixwords.sk/napoveda/ a www.wordsofwonders.cz/napoveda/

Je to jen malá cache 64MB a dost možná ji ještě zmenším až zjistím, kolik dat se v ní průměrně ukládá ve špičce. Data nemůžou mít dlouhou platnost, protože je potřeba držet je aktuální. Netroufnul jsem si na delší expiraci než 4 hodiny. 6x za den se data aktualizují, což snižuje přínos cache.

Testování se mi nakonec moc nepovedlo. Celou dobu jsem měnil obsah cache, takže výsledky jsou mezi sebou dost neporovnatelné. I Google řádil za poslední týden tolik, že porovnávat cache jen na základě času by nešlo. Běžně Google stahuje cca 100-150tis stran za den a tentokrát to bylo i 500tis stran/den. Hukot.

Samozřejmě cache se plní díky staženým stranám a tak se naplnila velice rychle a začala plnit svůj úkol skoro bleskově. Při nižší návštěvnosti to trvá déle a porovnat to mezi sebou nedává smysl. Takže testování jsem pro tentokrát hodil za hlavu.

Za chvíli to bude měsíc, co jsem si začal hrát s cache v paměti RAM, Memcached. Už tak rychlá poradna se ještě zrychlila. Potvrdily mi to snad všechny testy rychlosti. Jeden z nich vám ukážu.

A je tu další měsíc s TOPy blogů. Pro připomenutí:

::: V TOPu jsou zajímavé články, které za uplynulé dny našly nejvíce čtenářů z vyhledávání Google. Jsou to tedy většinou starší články a pravidelní čtenáři na tento TOP nemají vliv. Máte možnost podívat se, co zrovna frčelo a co bylo oblíbené. Těžko z toho soudit nějaký trend. Berte to pouze jako zajímavost. :::

Dnes jsem bohužel musel restartovat cache Memcached. Udělal jsem ve skriptu chybu a začalo cachování blábolů. Nešlo to jinak smazat než prostě celé resetnout. Ztratil jsem tak 1 den testování. Naštěstí jen jeden. S touto verzí jsem začal včera. :)

Zajímá vás efektivita takové cache? Tohle je graf po 2 hodinách provozu. Říká, že se uložilo 285MB dat a z cache odešlo 433MB. Rozdíl 148MB je ta efektivita. Tolik dat se nemuselo znovu spočítat a stačilo to vzít z už uložených hotových dat.

A přitom je vidět, že 45% požadavků cache neobsahuje.