Criminals the game

Citaat:

---

Origineel geplaatst door Flydesign.nl
Heb er helaas ook ervaringen mee. Was een ander wargame, toen nog slecht gescript. Bij een wargame heb je veel load, omdat mensen veel pagina's opvragen. Ga maar na als je zelf een spel speelt, dan klik je ook heel snel door.

Gelukkig hebben we samen met de scripter verschillende dingen kunnen optimaliseren, hierdoor draait het spel nu vlekkeloos. Zelfs nu de populariteit elke dag stijgt.

Denk dat criminals ook een optimalisatie beurt nodig heeft, maar wie durft daar aan te beginnen? Ik heb de code eens bekeken, dat is echt de grootste zooi. Dus ik zou echt nooit het spel op m'n server willen hebben!

---

Bij criminals (en/of wargames) komt de hoge load amper door het aantal bezoekers maar vooral door het aantal cron files en de frequentie waarop ze die laten lopen. Bij ons was dat 1x per 5 minuten maarliefst 10 bestanden. Deze bestanden hadden een hevig aantal loopjes en mysql query's wat voor een load van 3 veroorzaakte.

De klant is inmiddels gewaarschuwd en de site ligt er af.

Citaat:

---

Origineel geplaatst door yourforum


Bij criminals (en/of wargames) komt de hoge load amper door het aantal bezoekers maar vooral door het aantal cron files en de frequentie waarop ze die laten lopen. Bij ons was dat 1x per 5 minuten maarliefst 10 bestanden. Deze bestanden hadden een hevig aantal loopjes en mysql query's wat voor een load van 3 veroorzaakte.

De klant is inmiddels gewaarschuwd en de site ligt er af.

---

dat is natuurlijk onzin. Dat het nou over het algemeen kiddo's van 13 zijn die net met php beginnen wil niet zeggen dat iedereen dat doet. Ook de inzicht in sql en php (joins gebruiken bv, doe ik zelf ook niet :)) is vaak ook niet al te best. Waardoor soms nogal omslachtige situaties ontstaan. Ik hoorde bij mijn host vandaan ook zoiets, waar heb je nou in gods naam iedere 5 minuten een cron voor nodig?

Criminals zelf ik wel een tof spel (jammer dat er zoveel klonen van zijn) maar de code is werkelijk klote. Als je begint met de mysql_fetch_object en de select * te corrigeren draait het al een stuk sneller.

Nochtans zijn er klanten die het zonder problemen laten draaien op onze servers terwijl anderen een load veroorzaken tot in china :)

De meeste load werd tot voor kort bij ons ook veroorzaakt door zo'n game. Meestal gewoon die standaard code die ze draaien. Omdat die code dan nog redelijk 'publiek' was - ik veronderstel dat het criminals was, kende iedereen de locatie crons (persoon had ze niet beveiligd/ van naam veranders) en nadat de persoon ergens vijanden gemaakt had werden de crons vanop een hoop andere servers (10 servers die het bestand om de minuut opvroegen...) geladen. Resultaat: Server down door wargame. We gaan nu veel strenger optreden en dergelijke games meer in het oog houden.

een klant van mij die zoog echt extreem server load op (vooral mysql) ik heb heb gedwonden mysql_close(); onderaan te zetten en de load is toch al 50% terug gedrongen. ik heb zelf ook een wargame waar gemiddeld 200 online mensen zijn maar de serverload schommeld dan tussen de 0.05 en de 0.50 (eigen scripting)

Citaat:

---

dat is natuurlijk onzin. Dat het nou over het algemeen kiddo's van 13 zijn die net met php beginnen wil niet zeggen dat iedereen dat doet. Ook de inzicht in sql en php (joins gebruiken bv, doe ik zelf ook niet ) is vaak ook niet al te best. Waardoor soms nogal omslachtige situaties ontstaan. Ik hoorde bij mijn host vandaan ook zoiets, waar heb je nou in gods naam iedere 5 minuten een cron voor nodig?

---

Met 5 jaar ervaring in php, asp, jsp, VB en C denk ik toch dat ik wel enigsinds weet waar het aan ligt. En nee, dat zijn zeer zeker niet de bezoekers in onze gevallen. Een game met 2000 unieke bezoekers per dag kan prima draaien zonder problemen!

Het gebruik van mysql_result, mysql_close en GOEDE query's (dus niet SELECT * FROM) maakt een game al een stuk makkelijker om te draaien. Wij hebben nu een game lopen die géén load veroorzaakt (niets ongebruikelijks) en toch 4500 unieke bezoekers per dag heeft

Hoe kan je Criminals Game overnemen?

Citaat:

---

Origineel geplaatst door yourforum

Met 5 jaar ervaring in php, asp, jsp, VB en C denk ik toch dat ik wel enigsinds weet waar het aan ligt. En nee, dat zijn zeer zeker niet de bezoekers in onze gevallen. Een game met 2000 unieke bezoekers per dag kan prima draaien zonder problemen!

Het gebruik van mysql_result, mysql_close en GOEDE query's (dus niet SELECT * FROM) maakt een game al een stuk makkelijker om te draaien. Wij hebben nu een game lopen die géén load veroorzaakt (niets ongebruikelijks) en toch 4500 unieke bezoekers per dag heeft

---

Was natuurlijk geen aanval op je. Had het idee dat je de groep 'wargame' over 1 kant gooide. Ik bedoel hetzelfde te zeggen het 2e helft van je bericht. Veel problemen komen simpelweg door onwetendheid.

@Janson:
Ik denk dat je dan even contact op moet nemen met de wargame commissie om dat te regelen. :-D

Inderdaad, Criminials' script is nogal brak :r
Die jongen vroeg me eens te helpen met een nieuwe versie, nou die code van hem was echt onwijs brak, dat het werkte was een wonder :)

Citaat:

---

Origineel geplaatst door full-Patrick
een klant van mij die zoog echt extreem server load op (vooral mysql) ik heb heb gedwonden mysql_close(); onderaan te zetten en de load is toch al 50% terug gedrongen. ik heb zelf ook een wargame waar gemiddeld 200 online mensen zijn maar de serverload schommeld dan tussen de 0.05 en de 0.50 (eigen scripting)

---

Quote 2:

Citaat:

---

De meeste load werd tot voor kort bij ons ook veroorzaakt door zo'n game. Meestal gewoon die standaard code die ze draaien. Omdat die code dan nog redelijk 'publiek' was - ik veronderstel dat het criminals was, kende iedereen de locatie crons (persoon had ze niet beveiligd/ van naam veranders) en nadat de persoon ergens vijanden gemaakt had werden de crons vanop een hoop andere servers (10 servers die het bestand om de minuut opvroegen...) geladen. Resultaat: Server down door wargame. We gaan nu veel strenger optreden en dergelijke games meer in het oog houden

---

Ik ben dus die klant, waarover het onderste bericht gaat.
Ik heb in mijn scripts echter OVERAL onderaan mysql_close(); staan.
Dus verbruik ikzelf 50% minder.
Verder probeer ik * zoveel mogelijk te vermeiden.
Toch krijg ik van mijn host volgende waarschuwing:
Indien de scripts binnen de 24 uur NIET verwijderd zijn of de load niet gereduceerd tot 1 a 3 wordt de gratis hosting voor klasje beeindigd.
Ikzelf gebruik echter niet zo veel en doe zoveel mogelijk om load te reduceren.
Voor 1000 spelers gebruik ik op 20 dagen slechts 8gig. Dit valt nog mee.
Er staan echter andere sites ook op de server, maar toch wordt 1 bepaalde site geviseerd.
Die andere site heeft gewoon een andere naam, en noemt zichzelf geen criminals.
Dus als men zo'n maatregels neemt, moet men niet iemand proberen te viseren die alles eraan doet om load te verlagen.

Hebben jullie nog exacte tips om load te verlagen.
Buiten: mysql_close(); onderaan elke pagina en select * te vervangen door expliciete "select naam1,naam2"

Want ik wil toch graag mijn hosting kunnen behouden!

Ps: nog een opmerking: ik heb meerdere subdomeinen waarop dingen van de site staan, maar mijn webhost heeft de backup functie niet geinstalleerd, bijgevolg kan ik zelfs geen backup maken (buiten manueel, en dat is veel) als ze mijn hosting verwijderen.
Ps2: ik ga nu mijn crons proberen te beveiligen, hebben jullie ook daar expliciete tips voor?

Groeten en alvast bedankt,
Koen Rens
www.klasje.be

"Ps2: ik ga nu mijn crons proberen te beveiligen, hebben jullie ook daar expliciete tips voor?"

Controleer op de host, als de aanroep komt van de server zelf (dus de cron) doe je de handelingen, anders stuur je de aanroep door naar je spel en voer je de handelingen niet uit. Kijk in de $_SERVER variabele voor de mogelijkheden om dit te controleren.

Al gedacht aan het cachen van gegevens? Als 10x iets uit de database gelezen wordt, en je hebt 10x een ander resultaat is dat nuttig. Maar 10x iets lezen en telkens dezelfde resultaten krijgen is vaak niet handig. Met cachen doe je het volgende:
- Zodra de gegevens in de database aangepast worden verwijder je een bestand van de server
- De eerste aanroep die ontdekt dat het bestand niet bestaat haalt het uit de database, verwerkt het tot html en slaat dat op in een bestand
- De aanroepen die het bestand vinden gebruiken rechtstreeks dat bestand.

Deze manier scheelt tijd voor het ophalen uit de database en het verwerken naar html. Dit is natuurlijk alleen nuttig bij iets wat op (bijna) elke pagina weergegeven wordt. Denk aan top10 posters.

Succes ermee.

Cachen is idd zeer handig, hoewel ik niet weet hoe ik er technisch gezien aan moet beginnen.
+ Het feit dat bij een spel, gegevens niet lang hetzelfde blijven.
En er zijn niet veel pagina's waarin hetzelfde wordt aangeroepen...

Groeten en BEDANKT,
Koen Rens
www.klasje.be

Ik dacht de crons te beveiligen via $_SERVER['HTTP_REFERER'], maar deze crons worden vanuit de config file ingeclude.
Bij includes heb je geen referers.

echo $_SERVER['DOCUMENT_ROOT'];
echo $_SERVER['PHP_SELF'];
echo $_SERVER['REQUEST_URI'];
echo $_SERVER['HTTP_HOST'];
echo $_SERVER['HTTP_REFERER'];

Geen enkel van deze variabelen kan kijken van waaruit iets geinclude wordt.
Ik heb het nu zo gedaan:
een wachtwoord in de config, deze roept nadien de cron aan, in de cron kijkt men of het wachtwoord van de config klopt.
Zoniet: exit;

Is het zo veilig genoeg?
Dit is de enigste beveiliging waarmee ik denk ik kan kijken vanaf waar deze cron wordt geopend.

Ik heb voor de zekerheid ook nog dit ingevoegd:
if($_SERVER['HTTP_HOST']!="criminals.klasje.be")
exit;
Maar aangezien dat dit altijd klopt, maakt deze beveiliging denk ik niet veel uit.


Alvast bedankt,
Koen Rens
www.klasje.be

irritante internal server errors!

Zelf heb ik nu ook heel veel last van iemand die Criminals op de server draait. Normaal is de server load overdag rond de 2 a 3 maar nu is hij rond de 6 sinds die klant criminals draait.

Weet iemand of er ergens een verbeterde versie van criminals is te downloaden. Want een klant afsluiten is ook weer zowat.