Jens.cz

Jak se liší tyhle dva Seagaty? Naprosto stejná kapacita (500GB), naprosto stejné fyzické uspořádání (1 plotna, 2 hlavy), naprosto stejné téměř všechny ostatní parametry … téměř, jediný rozdíl je ve vydávaném „hluku“ :) viz specifikace:

Drive acoustics, | ST3500418AS         | ST3500410AS
sound power      |                     |
-----------------------------------------------------------
Idle**           | 2.6 bels (typical)  | 2.3 bels (typical)
                 | 2.7 bels (max)      | 2.5 bels (max)
-----------------------------------------------------------
Quiet Seek       | 2.75 bels (typical) | 2.5 bels (typical)
                 | 3.10 bels (max)     | 2.7 bels (max)

Cenový rozdíl? V Softcom je o necelých 30 Kč dražší hlučnější disk ST3500418AS, zajímavé :) V Alfacomp se již tichý model neprodává (prodával se jen několik měsíců, cena 1375 Kč) a hlučnější model je zase o cca 20 Kč dražší :)

Proč se tichý model ST3500410AS tak rychle stáhl z obchodů? A proč je hlučnější model dražší a nahradil tichý? A jak se vůbec vyrábí disk, tak že bude o 0.3 db hlučnější nebo tiší a přitom má úplně stejné všechny parametry?

Podle vyjádření Seagate, které získal server xcpus.com je varianta ST3500410AS více šetrná k životnímu prostředí … viz článek Seagate Barracuda 7200.12 500GB Drive Review (ST3500410AS):

The 410AS model adheres to industry standard „low halogen“ specs and thus is more environmentally friendly than 418AS. The 410AS model also produces less noise than the 418AS model. That’s about all we know, and to date Seagate has done little to distinguish these models from each other in their marketing material, which is odd.

Kolega mě nedávno upozornil na zajímavé použít příkazu ALTER TABLE v MySQL. Jedná o přeřazení tabulky pomocí zvoleného sloupce (nebo sloupců). Nejdříve jsem si říkal, na co to asi může být užitečné, ale když už jsem to několikrát použil, tak jsem zjistil že takovou funkci může být velmi užitečná.

ALTER TABLE table_name ORDER BY col_name [, col_name] ...

V MySQL je řazení jeden ze zásadních bottlenecků. Často je samotný dotaz velmi rychlý, přidáte-li řazení, rychlost jde exponenciálně dolů. Částečně tomu lze pomoci vytvoření správného indexu. Ale ani to nemusí být vždy ideální řešení – indexy vám nepomůžou například v případě řazení podle více sloupců a kombinaci ASC a DESC (více viz nepoužití indexů při řazení). V některých případech pak lze s úspěchem použít ALTERT TABLE … ORDER BY ….

Konkrétní příklad použití

Mějme tabulku články, články se většinou na stránku vypisují podle datumu (dne uveřejnění) sestupně, pokud je datum shodný, tak články seřadíme podle primárního klíče (id) vzestupně. V tabulce články máme cca 118 tisíc řádků.

0) Dotaz na články bez řazení:

mysql> SELECT SQL_NO_CACHE id, datum FROM clanky LIMIT 10;
+------+---------------------+
| id   | datum               |
+------+---------------------+
| 8211 | 2007-10-14 15:00:00 |
| 8213 | 2007-10-14 15:00:00 |
| 8218 | 2007-10-14 15:00:00 |
| 8220 | 2007-10-14 15:00:00 |
| 8231 | 2007-10-14 15:00:00 |
| 8237 | 2007-10-14 19:16:22 |
| 8240 | 2007-10-14 19:40:28 |
| 8241 | 2007-10-14 19:45:01 |
| 8242 | 2007-10-14 19:48:34 |
| 8245 | 2007-10-14 18:57:17 |
+------+---------------------+
10 rows in set (0.09 sec)

Výchozí řazení tabulky je podle toho, jak řádky vkládáme, tedy vetšinou podle primárního klíče.

1) Řazení bez použít klíčů:

mysql> SELECT SQL_NO_CACHE id, datum FROM clanky ORDER BY datum DESC, id LIMIT 10;
+--------+---------------------+
| id     | datum               |
+--------+---------------------+
| 175364 | 2038-01-19 03:14:08 |
| 176782 | 2038-01-19 03:14:08 |
| 178837 | 2038-01-19 03:14:08 |
| 178838 | 2038-01-19 03:14:08 |
| 181779 | 2038-01-19 03:14:08 |
| 191940 | 2038-01-19 03:14:08 |
| 215340 | 2009-04-09 19:02:39 |
| 215339 | 2009-04-09 19:02:33 |
| 215338 | 2009-04-09 19:02:31 |
| 215337 | 2009-04-09 19:02:29 |
+--------+---------------------+
10 rows in set (0.21 sec)

2) Řazení s použitím klíče:

mysql> CREATE INDEX razeni ON clanky (datum DESC, id);
Query OK, 118970 rows affected (1.24 sec)
Records: 118970  Duplicates: 0  Warnings: 0
mysql> OPTIMIZE TABLE clanky;
+--------------+----------+----------+----------+
| Table        | Op       | Msg_type | Msg_text |
+--------------+----------+----------+----------+
| bench.clanky | optimize | status   | OK       |
+--------------+----------+----------+----------+
1 row in set (0.05 sec)
mysql> SELECT SQL_NO_CACHE id, datum FROM clanky ORDER BY datum DESC, id LIMIT 10;
+--------+---------------------+
| id     | datum               |
+--------+---------------------+
| 175364 | 2038-01-19 03:14:08 |
| 176782 | 2038-01-19 03:14:08 |
| 178837 | 2038-01-19 03:14:08 |
| 178838 | 2038-01-19 03:14:08 |
| 181779 | 2038-01-19 03:14:08 |
| 191940 | 2038-01-19 03:14:08 |
| 215340 | 2009-04-09 19:02:39 |
| 215339 | 2009-04-09 19:02:33 |
| 215338 | 2009-04-09 19:02:31 |
| 215337 | 2009-04-09 19:02:29 |
+--------+---------------------+
10 rows in set (0.20 sec)

Výsledek při přidání klíče v tomto případě nemá téměř žádný vliv, při kombinace ASC a DESC řazení MySQL klíče nezohledňuje.

3) Použít řazení pomocí seřazené tabulky:

mysql> DROP INDEX razeni ON clanky;
Query OK, 118970 rows affected (1.03 sec)
Records: 118970  Duplicates: 0  Warnings: 0

mysql> OPTIMIZE TABLE clanky;
+--------------+----------+----------+----------+
| Table        | Op       | Msg_type | Msg_text |
+--------------+----------+----------+----------+
| bench.clanky | optimize | status   | OK       |
+--------------+----------+----------+----------+
1 row in set (0.02 sec)

mysql> ALTER TABLE clanky ORDER BY datum DESC, id;
Query OK, 118970 rows affected (1.45 sec)
Records: 118970  Duplicates: 0  Warnings: 0

mysql> SELECT SQL_NO_CACHE id, datum FROM clanky LIMIT 10;
+--------+---------------------+
| id     | datum               |
+--------+---------------------+
| 175364 | 2038-01-19 03:14:08 |
| 176782 | 2038-01-19 03:14:08 |
| 178837 | 2038-01-19 03:14:08 |
| 178838 | 2038-01-19 03:14:08 |
| 181779 | 2038-01-19 03:14:08 |
| 191940 | 2038-01-19 03:14:08 |
| 215340 | 2009-04-09 19:02:39 |
| 215339 | 2009-04-09 19:02:33 |
| 215338 | 2009-04-09 19:02:31 |
| 215337 | 2009-04-09 19:02:29 |
+--------+---------------------+
10 rows in set (0.10 sec)

Zde je vidět dvojnásobný nárůst rychlosti. Navíc, mám experimentálně ověřeno, že pokud vybíráte více sloupců (né tedy jen id a datum), tak se rychlost řazeného výsledku dramaticky propadá. To proto, že řazení probíhá v sort bufferu v paměti, velikost tohoto bufferu definuje proměnná sort_buffer_size v nastavení MySQL. V momentě kdy řadíte velké výsledky, buffer „přeteče“ a řazení se začne odehrávat na disku — viz algoritmus filesort v MySQL — což celý proces dále zpomaluje.

Jediný vážný problém tohoto způsobu využití seřazení tabulky je ten, že v případě vložení nebo aktualizace řádků se „seřazenost“ tabulky nezachová. Dále pak tento princip nefunguje na InnoDB typy tabulek. I přes tyto nevýhody lze tuto vlastnost MySQL často s úspěchem využít a zefektivnit tak některé dotazy.

Zajímavé odkazy k tématu:

• ALTER TABLE … ORDER BY syntax – kapitola v manuálu MySQL.
• ORDER BY optimalizace – kapitola v manuálu MySQL,
• ORDER BY … LIMIT Performance Optimization – článek na MySQL Performance Blog.

Jak otestovat výkonnost souborového systému na linuxu? Je lepší ext3, ReiserFS, JFS nebo XFS? Jaký RAID použít a jako ho nastavit? Odpověď není jednoduchá, vždy záleží na konkrétní situaci a na konkrétních požadavcích. Jedno je ale jasné, většina z nás chce dosáhnout maximálního výkonu při zachování bezpečnosti uložených dat. To jak otestovat výkonnost filesystému na linuxu je předmětem tohoto článku.

Utilita bonnie++

Tato jednoduchá utilitka testuje zvolený filesystém tím že na něj vytvoří různými způsoby poměrně velké souboru (ve výchozím stavu 2 * velikost RAM po 1 GB — tedy 8 GB RAM = 16 * 1GB souborů), které následně čte a přepisuje. Toto všechno měří a počítá rychlosti jednotlivých operací, navíc v dalších testech umí vyvářet různé (volitelné) množství souborů a adresářů, ke kterým různě přistupuje (mazání a čtení). Otestuje tedy i schopnost filesystému rychle přistupovat k adresářům a souborům.
Instalace bonnie je na Debianu velmi jednoduchá, i ve stable existuje balíček bonnie++:

# apt-get install bonnie++

Spuštění je téměř stejně jednoduché jako instalace, vytvoříte si na testovaném FS nějaký adresář (například /var/bonnie):

# mkdir -m 0777 /var/bonnie
# bonnie++ -d bonnie -u root:root

a už to jede …, výsledek testu se pak zobrazí v textovém formátu přibližně takto (důležitý pro další zpracování je poslední řádek):

jens,16G,62748,98,180566,53,79826,14,71269,94,230871,21,614.8,0,16,31768,100,+++++,+++,+++++,+++,31162,99,+++++,+++,+++++,+++

Tomuto bonnie říká CSV formát, zároveň s utilitou bonnie++ se vám taky nainstalují bon_csv2html a bon_csv2txt. První převádí CSV formát do přehledné HTML tabulky a druhý generuje textovou tabulku.
bon_csv2html lze použít následovně:

# echo "jens,16G,62748,98,180566,53,79826,14,71269,94,230871,21,614.8,0,16,31768,100,+++++,+++,+++++,+++,31162,99,+++++,+++,+++++,+++" | bon_csv2html > bonnie.html

Výsledný soubor bonnie.html je výsledková tabulka s popisky a s výsledky (ke každému testu rychlost a zatížení CPU), pokud provedeme více testování, pak si všechny výsledné řádky dáme do jednoho souboru, např. bonnie.txt a vygenerujete si výsledkovou tabulku pro všechny testy:

# cat bonnie.txt | bon_csv2html > bonnie.html

Při použiti bon_csv2txt získáváte textový výstup:

Version  1.03e      ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
jens            16G 62748  98 180566  53 79826  14 71269  94 230871  21 614.8   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
jens             16 31768 100 +++++ +++ +++++ +++ 31162  99 +++++ +++ +++++ +++

Je důležité říci, co znamenají hodnoty ++++ a +++ ve výsledku benchmarku: tento výsledek znamená, že test proběhl tak rychle (méně jako 500ms), že nebylo možně vyhodnotit správnou hodnotu a proto raději nevypíše nic, než nevypovídající číslo. Z tohoto důvodu je třeba parametry spuštění ještě lehce upravit tak, aby benchmark vyvořil více souborů a aby naměřil nějaké relevantní hodnoty. Vetšinou se s tím setkáte u create testů, které vytváří soubory a adresáře. Proto nastavte parametr -n například takto:

# bonnie++ -d bonnie -u root:root -n 16:10000:16:64

Důležité odkazy na bonnie++:

• oficiální stránka projektu, zdrojáky a různé verze,
• manuálová stránka bonnie++,
• článek na Linux.com: Using Bonnie++ for filesystem performance benchmarking.

Debian (Etch i Lenny) používá ve výchozím stavuj editor nano. Toto lze jednoduše změnit pomocí utility update-alternatives. Pokud tedy chcete používat například vi nebo vim namísto nano, tak hurá do toho.

# update-alternatives --config editor

Tento příkaz vám pak dá na výběr, začátečník si pak může vybrat třeba i iterní editor který používá Midnight Commander: mcedit.

franta:~# update-alternatives --config editor

There are 5 alternatives which provide `editor'.

  Selection    Alternative
-----------------------------------------------
          1    /bin/ed
 +        2    /bin/nano
          3    /usr/bin/vim.tiny
*         4    /usr/bin/vim.basic
          5    /usr/bin/mcedit-debian

Press enter to keep the default[*], or type selection number:

Další zajímavá věc, které s tímto tak trochu souvisí je, že v poslední době se ve výchozí instalaci Midnight Commanderu (mc) používá také nano jako výchozí editor. To je poměrně nepříjemné, protože nano mě přijde oproti mcedit jaksi nepřívětivé. Toto lze však také velmi jednoduše změnit, v konfiguraci mc si zaškrtnete use internal edit (viz obrázek).

Pětkrát sláva! Po 22 měsících vývoje byla dnes vydána další stabilní verze Debianu: Debian GNU/Linux 5.0 s kódovým označením Lenny. Testing verze se tedy tak stala stable, aktuální testing se stává verze s kódovým označením Squeeze.

Důležité novinky jsou z mého pohledu především tyto:

• jádro Linux verze 2.6.26
• Apache 2.2.9
• MySQL 5.0.51a
• PHP 5.2.6

A ještě link na oficiální stránku novinky o vydání Debianu 5.0.

Nastavení Doctype aplikace v Zend Frameworku pomocí helperu (placeholder helperu) Zend_View_Helper_Doctype je ideální udělat přímo v bootstrapu. Zend si poté automaticky zajistí (pomocí Zend_Registry), že všechny následně vykreslené helpery budou syntakticky správně – tedy přidá potřebné ukončovací lomítko nepárového elementu, je-li třeba (jedná-li se o XHTML).

Příklad kódu v bootstrapu, který zajistí nastavení doctype (hlavně poslední řádek):

...
// Mvc Layout + adresa pro layouty
Zend_Layout::startMvc(array('layoutPath' => '../application/layouts'));
// xhtml sablona layoutu (musi existovat '../application/layouts/xhtml.phtml'!)
Zend_Layout::getMvcInstance()->setLayout('xhtml');

// nastaveni cesty pro scripty view
$view = Zend_Layout::getMvcInstance()->getView();
$view->setScriptPath(array('../application/views/scripts', '.'));
// nastaveni helperu
$view->setHelperPath('../application/views/helpers', 'Jens_View_Helper');
// nastaveni docType pro celou aplikaci
$view->doctype(Zend_View_Helper_Doctype::XHTML1_STRICT);
...

V šabloně ../application/layouts/xhtml.phtml, si pak přímo na začátek přidáte voláni vykreslení doctype jednoduchý voláním $this->doctype() bez parametru, a on už bude sám vědět co má vypsat :) Příklad xhtml.phtml layoutu pak vypadá přibližně takto:

<?=$this->doctype()?>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="cz" lang="cz">
	<?=$this->layout()->header?>
	<body>
		<?=$this->layout()->content?>
	</body>
</html>

Jak přidat CSS soubory nebo ikonu do hlavičky (X)HTML v Zend Frameworku? Už od delší dobu je přímo v Zendu k dispozici spousta View Helperů (headLink, headMeta, headScript, headStyle a headTitle). Dnes se zaměříme jen na dva: headLink a headStyle.

Přidání CSS souboru

Přidání CSS souboru lze klasicky dvojím způsobem, první:

<style media="all" type="text/css">@import "/css/style.css";</style>

a druhý:

<link rel="stylesheet" href="/css/style.css" type="text/css"/>

Oba dva jsou hojně používání na různých webech. Který z nich je nejideálnější či úplně nejoptimálnější (:-) nevím, asi se zrovna používá to, co se komu líbí.

V Zendu budete pro první případ potřeboval helper headStyle:

echo $this->headStyle()->appendStyle('@import "/css/style.css";', array('media' => 'all'));

a pro druhý pak využijete headLink:

echo $this->headLink()->appendStylesheet('/css/style.css', 'all');

Oba použití samozřejmě můžete řetězit a celek vypsat pouze jednou:

$this->headLink()->appendStylesheet('/css/style.css', 'all');
$this->headLink()->appendStylesheet('/css/layout.css', 'all');
echo $this->headLink(); // vypise oba dva styly

Přidání favicon(y)

Na přidání favicony se používá pouze element <link>, takže tedy helper headLink:

echo $this->headLink()->headLink(
	array(
		'rel' => 'favicon',
		'href' => '/img/favicon.ico',
		'type' => 'image/x-icon'
	)
);

… co jsem si řekl, že bych si měl začít někam psát svoje poznámky a myšlenky, které nechci zapomenout a nechat ladem. A tak jsem si založil tento blog abych se o moje poznámky mohl i podělit. Počáteční nadšení rychlo opadlo, interval mezi příspěvky za začal prodlužovat ale občas mě popadla tvůrčí múza a měl jsem trochu více času. Za ten rok jsem vyprodukoval asi 24 článků, to je krásný průměr dva za měsíc :) No tak to zkůsím vydržet ještě další rok, dám si předsevzetí (ale né moc zavazující) napsat tři články za měsíc, to jsem sám zvědav jak mě to půjde …

Vzhledem k tomu, že tento blog je téměř anonymního autora, tak jsem se rozhodl o sobě něco napsat. Nebudu to více rozmazávat, vytvořil jsem novou stránku o autorovi, kde se o mě můžete něco málo dozvědět.

Nedávno jsem objevil další zajímavý nástroj na monitorování systému – Monitorix. Né že by to byla nějaká novinka na poli monitorovacích nástrojů různých systém, těch existuje celá řada, kvalitních a vyzkoušených, co monitorují kde co. Monitorix mě zaujal ale svými screenshoty, které vypadaly z dálky velmi dobře, tak jsem to zkusil nainstalovat. Jelikož to vypadá, že je to poměrně mladý projekt, tak mě bylo jasné že v Debianu balíček určitě nebude, i když používám současný testing (Lenny). Takže klasická instalace ze zdrojáků.

Monitorix monitoruje:

• CPU: vytížení, procesy, pamět, teplotu
• Časy procesů user, nice, system, idle a i/o wait)
• Teploty pomcí LM-Sensors a HDDtemp
• Využití disků (max. 5 mount-pointů)
• Síťová rozhraní input/output (max. 5)
• Aktivitu na uživatelsky definovatelných portech sítového rozhraní
• Aktivitu přerušení sytému
• Monitorování služeb SMTP, SSH, FTP, Telnet, Samba, NetAtalk, VirusMail, FAX, POP3 a HTTP
• … a možná i další

Příprava instalace

V době psaní tohoto článku byla aktuální verze Monitorixu 1.2.2, na oficiálních stránkách je uveden návod na instalaci v Ubuntu, který bohužel se nezdá příliš aktuální. Monitorix používá pro vykreslování grafů nástroj RDDtool, takže před vlastní instalací Monitorixu bude třeba ještě nainstalovat balíček rddtool a knihovnu rddtool librrds-perl pro Perl – protože Monitorix je napsán celý v Perlu.

# apt-get install rrdtool librrds-perl

Instalace Monitorixu ze zdrojáků

# wget http://www.monitorix.org/monitorix-1.2.2.tar.gz
# tar xfz monitorix-1.2.2.tar.gz
# cd monitorix-1.2.2
# ./install.sh

Až se vás to zeptá, jakou distribuci chce instalovat, zvolte: 3 – Debian a poté už další otázky jen potvrďte (případně postupujte dle uvážení).

Příprava na spuštění

V tuto chvíli by teoreticky mohlo být vše připraveno na spuštění, ale to by autor musel odstranit všechny mušky příslušné verze. V první řadě je třeba vytvořit adresář, kam se budou logovat stavy systému aby se z nich následně daly vytvořit grafy.

# mkdir -p /var/lib/monitorix

Dále, ač jsme sice zvolili instalaci pro Debian, tak se nainstaluje defaultní verze konfiguračního souboru /etc/monitorix.conf, proto je třeba jej upravit (jedná se především o řádek 34 – our $OSTYPE="Linux-RHFC" přepsat na our $OSTYPE="Linux-Debian", další parametry pak podle uvážení a potřeby, včetně sekce vybraných grafů.

our $TITLE="Jens.cz";                   # your company name
our $HOSTNAME="";                       # hostname of this server
our $OSTYPE="Linux-Debian";             # choose your OS type (see below)
our $IDATE="01 Jan 2009";               # initial statistics date
our $SAMBAVER="3";                      # Samba version (2 or 3)
our $MULTIHOST="N";                     # Enable multihost feature
our $MULTIHOST_FOOTER="Y";              # (multihost) display URL in image
our $MULTIHOST_IMGPERLINE="2";          # (multihost) # of images per line
our $REPORT_LANG="en";                  # Report language
our $THEME_COLOR="black";               # Default is "black", none is "white"
our $EMAIL="root@localhost";           # Generic email for reports
our $REFRESH_RATE="150";                # Web stats' refresh rate in seconds
our $ENABLE_CROND_MAIL="N";             # Error messages are sent by crond

Poslední věc co musíte udělat je ověřit nastavení případně přenastavit Apache tak, aby jste měli přes nějakou adresu dostupnou složku /var/www/monitorix (já jsem použil do svého virtual-hostu Alias, protože nemám DocumentRoot ve /var/www) a poté přístup k CGI skriptům přes klasickou URL ../cgi-bin/...

Alias /monitorix/ /var/www/monitorix/

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
    AllowOverride None
    Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
    Order allow,deny
    Allow from all
</Directory>

Spuštění

A konečně můžete Monitorix spustit. On se sice tváří jako daemon, a spouští přes /etc/init.d/monitorix, ale to je jen skript, který vytvoří minutový cron /etc/cron.d/monitorix, který provádí monitorování systému.

# /etc/init.d/monitorix start

V případě že vám to při spuštění napíše nějakou chybu, tak máte nejspíše špatně nastaven konfigurační soubor a nebo nemáte vytvořené příslušné adresáře (/var/lib/monitorix, /var/www/monitorix).

Zhodnocení

Monitorix lze nainstalovat velmi rychle, jeho konfigurace je taktéž poměrně jednoduchá (v defaultním stavu jsou zobrazeny všechny grafy). Vypnuté jsou pouze statistiky z lm-sensors a hddtemp, které umožňují monitorování hardwaru – teplot, otáček atd. Grafické výstupy jsou obstojné, na úvodní stránce s výběrem zobrazovaného intervalu by se dalo zapracovat a doplnit možnost hodinového zobrazení a možnost zobrazení konkrétního intervalu od – do. Po nahlédnutí do zdrojáku musím říci, že je na celém nástroji ještě hodně práce, spousta věcí je tam jaksi „natvrdo“ a chtělo byt to lepší dokumentaci jak na webu, tak v kódu.

Jinak ještě upozorním, že v defaultní konfiguraci se Monitorix pokouší provádět monitorování různých portu síťového rozhraní, to dělá tak, že si přidá vlastní „pravidla“ pomocí iptables. Toto chování se konkrétně mě silně nelíbí, a proto doporučují vypnout před prvním spuštěním monitorování portů pomocí proměnné $ENABLE_PORT na „N“.

Občas je třeba provést na stránkách údržbu tak, že je třeba na chvíli zastavit zobrazování webu – ať už je to údržba databáze nebo cokoliv jiného. V takovém případě se změní například index.php aby zobrazoval „nějakou hlášku o údržbě“. Problém ale může nastat, když zrovna v tu chvíli indexuje váš obsah třeba GoogleBot. Vaše hláška o údržbě pro něj bude obyčejná informace vrácená typicky s hlavičkou HTTP statusu 200 (viz. RFC HTTP status 200) a GoogleBot stránku pěkně zaindexuje a pak se nestačíte divit co že to google vrací za výsledky na vašem webu :)

Na toto existuje doporučení přímo od Googlu: „… nastavte server tak, aby vrátil status 503 (viz. RFC HTTP status 503) namísto statusu 200 …“. V PHP jednoduchá věc pomocí funkce header(), ideálně ještě doplníme vlastní hlášku o údržbě:

<?php
header('HTTP/1.1 503 Service Temporarily Unavailable');
header('Status: 503 Service Temporarily Unavailable');
?>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>503 Service Temporarily Unavailable</title>
</head><body><h1>Service Temporarily Unavailable</h1>
<p>The server is temporarily unable to service your request due to maintenance downtime or
capacity problems. Please try again later.</p>
</body></html>

Retry-After hlavička

Navíc, podle RFC – Header Field Definitions je může být použito v hlavičce u statusu 503 pole Retry-After:

 The Retry-After response-header field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. This field MAY also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked wait before issuing the redirected request. The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.

       Retry-After  = "Retry-After" ":" ( HTTP-date | delta-seconds )

Two examples of its use are

       Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
       Retry-After: 120

In the latter example, the delay is 2 minutes.

Tedy, navíc ještě přidáte hlavičku Retry-After s hodnotou (v sekundách, nebo přímo časem), za kterou předpokládáte že web pojede – na příklad za 1 hodinu (3600s):

header('HTTP/1.1 503 Service Temporarily Unavailable');
header('Status: 503 Service Temporarily Unavailable');
header('Retry-After: 3600');

Zend Framework

A závěrem ještě příklad, pro odeslání statusu 503 v Zend Frameworku:

$this->getResponse()->clearBody();
$this->getResponse()->setRawHeader('HTTP/1.1 503 Service Temporarily Unavailable');
$this->getResponse()->setRawHeader('Status: 503 Service Temporarily Unavailable');
$this->getResponse()->setRawHeader('Retry-After: 3600');

$msg = '<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">';
$msg.= '<html><head><title>503 Service Temporarily Unavailable</title>';
$msg.= '</head><body><h1>Service Temporarily Unavailable</h1>';
$msg.= '<p>The server is temporarily unable to service your request due to maintenance downtime or
capacity problems. Please try again later.</p>';
$msg.= '</body></html>';			

$this->getResponse()->setBody($msg);
$this->getResponse()->sendResponse();