Account by provider geblokeerd door overload
Ik heb een probleem. Mijn provider heeft mijn account geblokkeerd omdat ik blijkbaar voor overlast zorg. Nu weet ik dat wat ik doe best wel zwaar zou kunnen zijn voor de server, maar het is volgens mij niks bijzonder groot wat een provider niet aan zou kunnen.
Concept van mijn website en werking op de database:
De website die ik aan het maken ben is een affiliated site waarin ik alle items in de database heb staan en deze wordt automatisch geüpdate. Dit doet hij door de XML bestanden van de affiliated provider (M4N) in te lezen en dan deze gegevens in de database te zetten en door de items die hier niet meer in staan te verwijderen en ik gok dat hier het probleem zit (zie plaatje).
Nu is mijn vraag ligt het probleem bij mij? kan ik wat veranderen om de load op de server te verlagen Ik draai dit script expres elk uur, om er voor te zorgen dat niet in een keer op de dag de load groot is. Meestal gebeurd er dus niks omdat hij eerst kijkt of de XML wel geupdate is voordat hij het download en inleest.
Ik kan nu helaas niet de bij de script maar zet hier wel even bij wat ik van mijn provider kreeg. Het is ook zo dat als ik mij goed kan herinneren dat deze SQL-statement gewoon in het al bestaande script staan van de XML-reader van M4N.
Ik snap ook niet helemaal wat state en time betekend in de overzicht die ik gekregen heb en of dit iets betekend?
Gewijzigd op 27/05/2012 17:15:37 door Jeroen Kwakkel
Kan je in je code uitzoeken hoe die hele delete-query eruit ziet? Hij lijkt hier afgekapt te zijn. Uitgaande van dat dit alles is (en dat er geen andere kolom-namen in het afgekapte deel staan):
Heb je een index op de kolommen offerid en feedid zitten? Zo nee, dan is dat waarschijnlijk zeker de moeite waard, zeker als je tabel een behoorlijk aantal rows gaat bevatten.
Kan je al deze queries niet combineren tot slechts enkele queries a la DELETE FROM m4n_content WHERE feedid = 90106 AND offerid IN(1, 2, 3, .., X). Als het aantal in die IN-clause heel groot wordt (> ~500) kan je temporary tables gebruiken. Misschien helpt al je delete-queries in één transactie uitvoeren ook wel.
Dit is de originele query DELETE FROM ".$db_name.".m4n_content WHERE (offerid!='' AND offerid='".$read_offerid."' AND feedid='".$SQL_get_feeds_data['id']."') OR (offerid='' AND url='".$read_url."')"
Ik heb geprobeerd offerid en url in een tijdelijke table te zetten. Dit werkt en kan deze table opvullen en probeer dan de gegeven te verwijderen met "DELETE FROM m4n_content WHERE offerid IN (SELECT oid FROM toDelete) OR url IN (SELECT url FROM toDelete);" hierdoor crasht mijn database
heb er nu gewoon je eerste optie gebruikt dus DELETE FROM m4n_content WHERE offerid IN (12323, 1231, 12341, etc) OR url IN (www.url.nl, www.url2.nl, etc);" Voor 7000-8000 gegevens duurt dit zo'n 2-3 seconden dus dit is wel acceptabel.
Toch is het gebruik van een tijdelijke database beter? Hoe werkt dat precies dan?
Wat als je in plaats van een directe delete een waarde in een extra kolom op true set. Op gezette tijden kan je in 1 keer alle rijen deleten die die waarde inderdaad op true hebben staan. De update is een simpele query en de delete dan ook.
Dit is dubbelop lijkt mij.
Ik neem aan dat $read_offerid nooit leeg is. Dan zou je offerid!='' AND uit de query kunnen halen. Dat scheelt weer wat aan tijd.
Edit: Luister naar Jelmer. ;-)
Gewijzigd op 31/05/2012 13:00:54 door - SanThe -
www.url2.nl, etc)" dus nu heb ik er 1 ipv 7000, maar Jelmer zei dat het beter was om een "temporary tables" te gebruiken. Ik heb er dan een normale table van gemaakt omdat het onmogelijk is om twee select statement in één query op een temp table uit te voeren, maar mijn database crashed (of gaat ontzettend sloom) als ik dan de delete statement uitvoer "DELETE FROM m4n_content WHERE offerid IN (SELECT oid FROM toDelete) OR url IN (SELECT url FROM toDelete);"
Is het sneller of is het gewoon netter om een temp table te gebruiken?
Zoals ik al zei mijn query is nu "DELETE FROM m4n_content WHERE offerid IN (12323, 1231, 12341, etc) OR url IN (www.url.nl, Is het sneller of is het gewoon netter om een temp table te gebruiken?