cms - fouten afvangen?
Ik vraag me af... ik ben bezig met een cms, en een onderdeel van de installatie is het invullen van een pad naar de juiste directory. Nu vraag ik me af ik op dit soort installatie-zaken een foutafhandeling moet toepassen.
Voorbeeld: de programmeur gaat het cms installeren en moet een pad instellen. Nu typt hij het pad verkeerd in. Moet er dan een nette foutmelding komen dat hij het pad verkeerd heeft ingevuld, of moet er een standaard PHP foutmelding in beeld komen?
Het mooiste is natuurlijk als er een fatsoenlijke foutmelding in beeld komt, maar dat houdt wel in dat je bij iedere pagina-aanroep moet controleren of het pad juist is ingevuld (meer concreet, of de ingevulde directory bestaat). Dit gaat ten koste van je performance.
Mijn vraag is hoe jullie hier mee omgaan. Vang je dit soort installatie-zaken wel of niet af?
Ander voorbeeld: de programmeur moet de locatie van een config.php bestand aangeven. Moet nu telkens (bij iedere pagina-aanroep) via catch en try gecheckt worden of de locatie klopt, of toon je gewoon de standaard PHP foutmelding?
Het tonen van een nette foutmelding is natuurlijk super gebruiksvriendelijk, maar het gaat (denk ik) wel iets ten koste van de performance.
Wat adviseren jullie?
Wat betreft de config/pad, waarom? Zorg dat de config altijd op 1 vaste plaatst staat. Die van mij is bv core/config.php, zo krijg je nooit foutmeldingen omdat je zeker weet dat daar het bestand staat.
Denk aan ontbrekende config's...
Wat nu?
ik denk dat je tijdens de installatie daar zorgvuldig op moet controleren, en een nette foutmelding moet geven als de directory/file niet bestaat/leesbaar/schrijfbaar is. De installatie gebeurd maar 1 keer, dus qua performance valt dat wel mee.
Als je dit pad opslaat in de config file, die bij iedere pagina wordt aangeroepen, zou ik hier dan geen intensieve controle meer laten plaatsvinden. Die controle heb je al gedaan tijdens de installatie. Noem het een soort van Design-by-contract. Tijdens run-time ondervind je dan geen performance issues.
Waar het mis kan gaan, is als iemand handmatig de config aanpast. Je zou ervoor kunnen kiezen om de config gecodeerd oid op te slaan en mbv een script de configuratie aan te passen. Dit script lijkt me erg belangrijk. Als dat goed werkt, ben je niet snel geneigd om handmatig in de config te wijzigen.
Gewijzigd op 27/01/2012 10:53:13 door - Jim -
Ja maar dit klopt dus juist niet.
Je moet je dus zoiets indenken:
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
<?php
$config = '/bla/bla/config.php';
if (file_exists($config)) {
include $config;
} else {
echo 'Stomme programmeur, je hebt het pad fout ingevuld!';
}
?>
$config = '/bla/bla/config.php';
if (file_exists($config)) {
include $config;
} else {
echo 'Stomme programmeur, je hebt het pad fout ingevuld!';
}
?>
Die controle vindt nu bij iedere pagina-aanroep plaats. Dat is het probleem.
Gewijzigd op 27/01/2012 10:59:54 door Ozzie PHP
Dan heb je duplicaat-code, en zou ik dit op een enkele/centrale locatie zetten.
Geloof me als je echt over high-traffic na gaat denken speelt dit nog niet eens een rol. Zelfs hier zijn we op dat niveau niet eens bezig en ik werk hier aan sites met miljoenen aan hits per maand. Voor high-performance moet je denken aan database round-trips, sessies, incorrecte for/foreach loops, oppassen met memory usage aan de hand van Arrays, etc.
if(file_exists().. blaat
kost echt denk ik maar 0.00000001 sec ofzo ;)
@Kees: oké, thanks. Betekent dit dat jij wel dit soort controles inbouwt? Zo ja, doe je dat dan overal (bij iedere include)?
Kees Schepers op 27/01/2012 11:05:35:
...
if(file_exists().. blaat
kost echt denk ik maar 0.00000001 sec ofzo ;)
if(file_exists().. blaat
kost echt denk ik maar 0.00000001 sec ofzo ;)
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?php
// Set the path to check
$path = "/tmp";
$amountOfChecks = 1000000;
// Set the start-time
$start = time();
// Check 1000000 time for path-existance
for($i=0; $i <= $amountOfChecks ; $i++)
{
// Check
file_exists($path);
}
// Show the duration
$duration = (time() - $start);
echo "Duration: " . $duration . PHP_EOL;
echo "Duration per check: " . ($duration / $amountOfChecks) . PHP_EOL;
?>
// Set the path to check
$path = "/tmp";
$amountOfChecks = 1000000;
// Set the start-time
$start = time();
// Check 1000000 time for path-existance
for($i=0; $i <= $amountOfChecks ; $i++)
{
// Check
file_exists($path);
}
// Show the duration
$duration = (time() - $start);
echo "Duration: " . $duration . PHP_EOL;
echo "Duration per check: " . ($duration / $amountOfChecks) . PHP_EOL;
?>
Als je per request 1x de settings-file include, is dat geen probleem.
Uit het code voorbeeld hierboven kan je ook zien dat het bij 1.000.000 checks nog geen probleem is.
Als blijf ik van mening dat als de controle 1x intensief is gedaan, is het niet nodig/overbodig om het te blijven controleren. Als je toch de focus hebt op performance, reduceer overbodige controles.
@Jim: kun je voor de volledigheid even de resultaten vermelden?
"Als blijf ik van mening dat als de controle 1x intensief is gedaan, is het niet nodig/overbodig om het te blijven controleren. Als je toch de focus hebt op performance, reduceer overbodige controles."
Hier valt iets voor te zeggen, maar in mijn voorbeeld is dat toch niet te realiseren?
Ozzie PHP op 27/01/2012 11:40:28:
...
@Jim: kun je voor de volledigheid even de resultaten vermelden?
@Jim: kun je voor de volledigheid even de resultaten vermelden?
A: Dat verschil per server. Heb het script gepost zodat je kunt testen.
Quote:
"Als blijf ik van mening dat als de controle 1x intensief is gedaan, is het niet nodig/overbodig om het te blijven controleren. Als je toch de focus hebt op performance, reduceer overbodige controles."
Hier valt iets voor te zeggen, maar in mijn voorbeeld is dat toch niet te realiseren?
Hier valt iets voor te zeggen, maar in mijn voorbeeld is dat toch niet te realiseren?
Als je de include('path/to/config') 1x gebruikt in je index pagina, kan je het 1x controleren. Maar het is afhankelijk hoe je de omgeving opgebouwd hebt.
Worden alle pagina's apart aangesproken? of worden alle pagina's via de index-pagina aangesproken?
In het eerste geval, moet je de controle op iedere pagina uitvoeren. (Veel duplicaat code). In het 2e geval, staat de code 1x (bij voorkeur op een centrale plek), wordt vaak aangesproken, maar heeft weinig impact op de performance.
Ik heb weer een testje geschreven, zie het resultaat hier: http://waldio.webatu.com/phpbench/file-check.php
Broncode geef ik maar niet vrij, want ik heb nog nooit zo'n lelijke en slordige code geschreven...
Gewijzigd op 27/01/2012 15:52:55 door Jurgen B