comment 0

Adminer – composer package

Adminer nemá oficiální composer balíček. Jsou tady různá řešení: většina vývojářů si vystačí s tím, že jednou Adminer natvrdo do aplikace nakopírují a možná ho jednou za čas updatují novou minor verzí. O něco hezčí přístup je Pavlův instalační balíček, který sice přes composer nainstalujete, ale nedá se tím Adminer verzovat. O něco šťastnější řešení je Davidův adminer-custom, který ale obsahuje navíc nějaké kravinky o které nestojím a jeho verze neodpovídají verzím Admineru.

Před měsícem jsem si připravil daemona, který přes GitHub api kontroluje nové verze Admineru a ze SourceForge stáhuje všechny buildy pro konkrétní verzi (od myslq-cs po editor-pl): github.com/Mikulas/adminer-package. Tagy samozřejmě odpovídají konkrétním verzím Admineru. Nový package by se měl objevit max do pár minut od založení nového tagu v Adminer repu.

To že v balíčku jsou všechny buildy mě netrápí – nejsou v autoload a jenom si vyberu (symlinkem) ten který chci použít. Kdyby to pro někoho byl problém, můžete si napsat triviální composer update update script který vám smaže všechny buildy co nechcete.

Varnish: http cachování

Motivace: na mojesmrt.cz průměrně 10× zrychlení požadavků. Na homepage dokonce z 120 ms na 5ms. Za hodinu práce a bez zásahu do kódu aplikace.

Zjednodušeně je Varnish black box, který dáte mezi klienta a váš http server, nastavíte jaké stránky se mají cachovat jak dlouho a máte hotovo.

Screenshot 2014-10-07 12.34.07

Trochu složitěji je to takhle: varnish přijme http požadavek a rozhodne se (hlavně na základě url) jestli chce načíst nacachovanou odpověď. Každý http request má tzv. hash, kde je v základu jenom doména (nebo ip). Dá se to nastavit na libovolnou kombinaci (i upravených) proměnných z http požadavku. Pokud varnish požadavek cachovat nemá nebo ho cachovat má ale zatím tomu hashi žádný záznam neodpovídá, tak to pošle na backend. Pro zajímavost, backendů může být víc, dokonce to umí i fail-over.

Nejde to samozřejmě nasadit na všechny aplikace všude, takové jméno přihlášeného uživatele v hlavičce je typický neřešitelný problém. Na rozdíl od cachování v aplikaci samozřejmě nejde cachovat jenom část odpovědi. Všimněte si že spousta služeb má veřejný frontend kde se stav přihlášení nezobrazuje a samotná aplikace pro přihlášeného uživatele je jinde – tohle dělá třeba New Relic.

Dobré použití je Wiki (resp. MediaWiki). 95 % requestů mají od nepřihlášených uživatelů (Ori Livneh, Senior Performance Engineer at the Wikimedia Foundation , September 15, youtu.be/vgXgDVrb-BU?t=13:13). Doporučuju celý talk, pro ty co nemají čas vypíchnu nejlepší část:

This comes with a price. The price is that the use of a web accelerator masks the problems of the underlying application. If you know that the wast majority of requests are never going to hit php […] then you fret less about the performance characteristics of the code.

Nevýhody Varnish cache: špatná dokumentace a staré návody na webu. A pak nepodporuje tls, což ale lze vyřešit tím, že se použije tohle schéma:
Screenshot 2014-10-07 12.35.00

Přidání podpory pro tls se ani nechystá, odůvodněné to mají takto:

First, I have yet to see a SSL library where the source code is not a nightmare. […] Second, it is not exactly the best source-code in the world. Even if I have no idea what it does, there are many aspect of it that scares me. (varnish-cache.org/docs/…/ssl.html)

Nejsou to zrovna povzbuzující slova která by přesvědčovala o kvalitě Varnish, ale tls je drobnost a není potřeba, stačí že to podporuje http server. Když už se ale člověk prokouše dokumentací a nastavením, je to luxusní zrychlení.

PS: Jako všechny služby umí i varnish načítat konfiguraci ze všech souborů v určitě složce. Verzujte prosím tu konfiguraci v repozitáři, mějte symlink a deploy nástroj ať udělá varnish reload.

PPS: Kdyby vás zajímalo detailněji jak používá WikiMedia Varnish, mrkněte sem: http://www.mediawiki.org/wiki/Manual:Varnish_caching

Cronner jako generátor crontab.d

Štěkyho Cronner mě nadchnul a vidím v něm výhody, nicméně hlavně u hostingů které mají špatně nastavitelný cron. Napadlo mě ale další řešení.

Co v prezentaci na Poslední sobotě nezaznělo je, že je dobré informaci o cronech verzovat – to přesně cronner řeší. Osobně nemám problém crontab nastavit a asi bych nepřekousnul, že bych musel každou minutu volat cron manager v php, který by jenom občas něco zavolal. Takže mě napadlo verzovat nastavení crontabu. Co vím tak úplně každý linux má /etc/cron.d/, kam se dají nahrávat soubory ve stejném formátu jako v crontab. Řešení je tedy nasnadě: verzujte v repu aplikace nějakou vlastní cron definici a udělejte si symlink do /etc/cron.d/ (případně to nechte dělat deploy nástroj).

Další možností je nástroj, který by z cronner annotací vygeneroval crontab (což by mělo jít vždy). To bych asi nevyužil, ale dává to dohromady výmluvnost cronneru a výkon crontabu.

venn

Ještě ale nemáme to ultimátní řešení které by uspokojilo všechny.

Verzování konfigu

Při spolupráci s více lidmi často narážím na to, že někdo si upraví lokální konfiguraci a aplikace bez těch správných klíčů ostatním nefunguje. V lepším případě na to upozorní dobrá commit message, v tom horším se to programátor dozví z laděnky někdy v polovině rozběhnuté aplikace a špatně se to debuguje.

Na většině projektů co se podílím jsem nasadil verzované lokální konfigurace. Nemyslím tím že tenhle config přidávám do VCS (chraň bůh, jsou tam hesla atp.) ale v config.local.sample.neon i v config.local.neon máme klíč version: [1]. Pokud se do sample konfigurace udělá bc break, zvýší se version o jedna. Hned při dalším kompilaci konfigurace proběhne kontrola, že verze obou konfigurací jsou stejné – pokud nejsou, zobrazí se tahle krásná výjimka:

Config Version Bluescreen

Tohle celé je implementováno v rozšíření, které jsem pod Clevisem publikoval zde: https://github.com/Clevis/config-version-extension

Přidání do projektu je na tři řádky. Performance hit je prakticky nulový.

Mimochodem, protože se jako neon parsuje i config.local.sample.neon tak je rovnou kontrolováno, že je v tom souboru opravu validní neon. Říkám že je to feature tohohle rozšíření, protože se tomu nejde vyhnout – šlo by parsovat tu version regexem, ale to není to pravé ořechové.

Další řešení je mít git hook, který upozorní pokud se změní config.local.sample.neon. Tuším, že na tohle by šel použít post-checkout.