Veel gestelde vragen

Wij raden aan om eerst de relevante dingen uit de 'Quick Start' te lezen.

• SSH en sftp
• FTP

• De rechten van mijn files staan niet goed

<spoiler |Kan ik zelf de applicatieserver (her)starten? > Ja. Indien gewenst kunnen wij hiervoor een mechanisme voor u opzetten op basis van uw opload account en een trucje met ssh. Stel dat uw applicatieserver xxxx01as heet (= de applicatieserver die leeft onder /e/as/xxxx01 dan kunt u, nadat eea opgezet is, uw applicatieserver stoppen/starten door in te loggen op uw opload account en op de shellprompt te typen

ssh stop-xxxx01as

ssh start-xxxx01as
 

</spoiler>

• Waar vind ik de apache acces en error logs?
• Hoe zit de apache logging in elkaar?

• Met een wachtwoord of op basis van IP adress
• Https activeren

• Java: er blijven pagina's in de frontproxy hangen
• Java: Ik zie de prive sessie van iemand anders
• Waarom werkt het installeren van nieuwe builders niet in MMbase?

Stel dat het voor een deel van uw applicatie nodig is dat deze via http iets aan zichzelf, of aan een andere applicatie in dezelfde omgeving vraagt: wat is dan de url?

U kunt externe url (bv http://www.groente.nl/boerkenkoolfeed.xml) gebruiken, maar deze gaat via de frontproxy. Het is ook mogelijk de hit direct op tomcat af te vuren. Hiervoor moet u de naam van uw applicatieserver weten. Stel dat deze xxxx01as is, dan draait de applicatieserver altijd op poort 8888 is de url: http://xxxx01as:8888/ Het kan zijn dat in uw applicatieserver virtual hosting aan staat (als dezelfde applicatieserver gebruikt wordt om in verschillende host contexten meerdere applicaties te draaien (bv www.groente.nl en www.fruit.nl in dezelfde applicatieserver)). In dat geval dient uw applicatie een HTTP “Host:” header mee te geven met de juiste virtual host (bv “Host: www.groente.nl”)

Zoals beschreven in onze tips voor een schaalbare website; PHP vraagt relatief veel resources per connectie. PHP handelt zijn connecties af via 'workers'. Die workers hebben standaard met PHP een geheugenlimiet, wij kunnen dit geheugenlimiet aanpassen afhankelijk van het aantal workers. Wij delen alles op in instanties die maximaal 2 GB geheugen. Dus het aantal workers keer het geheugenlimiet per worker is totaal 2 GB. Bijvoorbeeld, PHP geeft standaard 64 MB:2048/64= 32 workers De kunst is om hier een goede balans in te maken: genoeg workers om veel verzoeken af te handelen en genoeg geheugen per worker zodat PHP geen fouten geeft.

We zien vaak dat beheer-omgeviningen van CMS'en relatief veel geheugen nodig hebben. Te weinig geheugen geeft foutmeldingen. Als je het geheugen zou bijstellen tot bijvoorbeeld 512MB, houdt je maar 4 workers per PHP instantie over. Je beheeromgeving werkt dan misschien wel, maar als je meer bezoekers krijgt op je website gaat het mis. Dan kun je hetzelfde effect krijgen als met brakke mysql queries; je houdt geen workers meer over voor je bezoekers en die zien dan een foutmelding “502 proxy error”. Dit ligt niet aan de frontproxy maar het komt doordat de proxy zijn request niet meer kwijt kan bij de backend. Alle workers zijn bezet en kunnen geen nieuwe requests meer aan.

In het algemeen heeft een bezoeker op je PHP site niet zoveel geheugen nodig per worker, dus voor de bezoekers wil je het liefste een balans met meer workers en minder geheugen. Wij kunnen voor het beheren van een CMS een apparte php instantie inrichten met relatief veel geheugen en weinig workers. Alle verzoeken /admin op je site worden dan door die instantie afgehandeld. Voor de security is het dan vaak ook een goed idee om iets te doen met IP whitelisting of extra authenticatie d.m.v. digests in te stellen.