Afdrukvoorbeeld
Heb de fout gevonden, nu nog een oplossing ervoor vinden. Het ligt aan hetgeen dat ik het IP adres en HOSTNAME van de bezoekers log. De fout zit hem ergens in deze:
De client ip wordt zo aangeroepen:PHP Code:$client_host = gethostbyaddr($client_ip);
Any clue? :) Heb er nu ff tijdelijk een // voorgezet en nu werkt de site gewoon normale snelheid :)PHP Code:$client_ip = $_SERVER['REMOTE_ADDR'];
Hmmm, voor elke request een dns aanroep doen, kost nu eenmaal tijd... maar geen 10 seconden per page. Anders kun je eens naar de load van je nameserver kijken. Misschiern trekt ie het niet.Citaat:
Oorspronkelijk geplaatst door ErikKosters
named 7463 0.0 0.2 37292 3464 ? Ssl Jul07 0:12 named -u named
Check je /etc/resolv.conf op nameservers die dood zijn.
Gaat het cachen van named wel goed? Dat ie 1 keer wat langer duurt, kan ik me voorstellen, maar niet elke pagina. Dan moet het bezoekers ip/hostname al gecached zijn, dacht ik.
Hoe kan ik kijken of dit goed gaat..?
Mijn server lijkt die commando gewoon niet leuk te vinden lijkt ut:
http://www.ek-hosting.nl/include/test.phpPHP Code:<?php
$client_ip = $_SERVER['REMOTE_ADDR'];
$client_host = gethostbyaddr($client_ip);
print "$client_ip<br>$client_host";
?>
Ik ga me resolv.conf ff nachecken:
Blijkt denk ik niet aan mij te liggen maar aan me colo-provider.. ik ga even contact opnemen.Citaat:
[root@server1]# ping google.nl
ping: unknown host google.nl
Gedaan, nu kan ik wel gewoon pingen naar hostnames maar alsnog blijft $client_host = gethostbyaddr($client_ip); raar doen.Citaat:
[root@server2]# ping google.nl
ping: unknown host google.nl
Hmmm... als je colo-p bepaalt of je kunt pingen... het je er waarschijnlijk een firewall tussen zitten. Misschien dat daar nog iets niet helemaal jofel zit? (jeserver <-> dns bv)Citaat:
Oorspronkelijk geplaatst door ErikKosters
Maar.... google.nl staat toch niet in je resolve.conf, mag ik aannemen?
Nee het ip wat in resolv.conf stond (dus ip naar hun dns server / nameserver) was verkeerd..
Dat loggen wordt toch al door apache gedaan.. Weet niet wat je met die gegevens moet, anders kan je het beter achteraf een keer uit laten zoeken en het IP direct opslaan.
Met een beetje relationele database scheelt dat gelijk heel erg veel tijd voor de bezoeker en hoeft er maar 1 keer een naam en een IP bij elkaar gezocht te worden.
Oke, ik zal zelf wel even rond kijken. Bedankt voor het reageren.
't Is nu éénmaal een functie die niet aan te raden is om intensief te gebruiken (en zeker niet als je site druk wordt bezocht)
Kijk zeker ook ff in de commentaar op http://www.php.net/gethostbyaddr
Dit kan ook nog interessant zijn:
<quote>
...gethostbyaddr is very easy get timed-out and the script stucks there forever. Here is a fail-safe alternative, 1 sec max for timeout per IP.
function ar_gethostbyaddr($ip) {
$output = `host -W 1 $ip`;
if (ereg('.*pointer ([A-Za-z0-9.-]+)\..*',$output,$regs)) {
return $regs[1];
}
return $ip;
}
</quote>
Is dit ook later met het IP te doen? Zo ja dan kun je het ook in een cron zetten en eens per dag uitvoeren (bijv. 's nachts). Dan heb je toch de gegevens en niet de trage pagina's.
Ik heb dit ook voor gehad met mijn reseller. Een gebruiker had mambo geïnstalleerd en dit werkte perfect totdat hij 2 skins probeerde te installeren die blijkbaar niet werkten. Kan ook zijn dat hij ze verkeerd had geïnstalleerd, maar alles was toch opgelost na het verwijderen van de mambodatabase. Het kunnen echter nog tal van andere redenen zijn ook. Ik post maar even een ervaring die ik onlangs meemaakte.
Het werkt momenteel weer naar behoren. Misschien was het toch die nameserver..
Nee, het probleem is een IMO verkeerd ontworpen applicatie.Citaat:
Oorspronkelijk geplaatst door ErikKosters
Een haperende of trage nameserver zou een probleem kunnen geven, maar dat probleem heb je niet of minder als je applicatie minder afhankelijk is van dergelijke factoren.