[Clarence]

Ursprungligen postat av klein

Jag har inte märkt någon kraftminskning, dock kör jag inte det i webhotell miljö. Har fundera på att ha 2 tabeller , en stor tabell med alla blockerade IP och sedan en cache tabell där man lagra besökta ip och med flagga om det goda eller onda IPn.

Men som sagt , det vara ett snabbhack, det går för sköna.. Eller så kanske man kan få sitt webhotell att sätta upp en lokal version av stoppaspam.

Nackdelen som jag ser med t.e.x frågor, är man kan få modeifera koden ganska mycket... Cookie lika så.. Det är ganska mycket arbete på implemtera det. Fördelen med den här koden, är att man kan lägga den central i någon header, så är det up and running.

Jag trodde det skulle prestanda problem, med söka igenom att en tabell på 180k IP, men har inte märkt av det och då är mysql standard uppsatt på maskinen. Webhotellen har oftast optimerade DB maskiner..

Det finns en del andra problem med din kod också. De tre jag ser direkt är:

Kolumn-typ för ip-adressen. Lagras denna som varchar(15) tar den upp till 46 bytes med utf8. Alternativet heter INT, kör du ipv4 har du det redan klart i MySQL med INET_NTOA()/INET_ATON(). Med en unsigned int rymmer du alla ipv4 adresser på 4 bytes.

Det andra är att du har en primär-nyckel på ett id för IP-adressen (!?). Det enda det gör här är att göra inserts/updates långsammare. Lägger du istället primärnyckeln på int-representation av ip-adressen blir det mycket kvickare. Sedan bör du använda select banIP och inte select *. På så sätt kan du läsa hela ditt svar från index och behöver inte göra disk-reads (förutsatt att db-servern mår bra).

Du har gjort dig direkt beroende av en tredje part för hela din sajt. Vad händer när de får prestanda-problem, du får routingproblem mot dom eller deras site går ner kl 4 på natten?