[PHP] Server & Client

[BlackWhizz]

hallo.

Ik ben bezig met een script voor een klant. Alleen het probleem is dat hij 1 universeel systeem wil hebben voor meerdere sites op verschillende hosts. Dus nu dacht ik aan een mooie oplossing d.m.v. zoals ik het het noem Server en Client.

Het systeem bestaat dus uit een grote database met films/afbeeldingen.
Server genereert iedere nacht een RSS feed genaamd {gallery_naam}.xml
Client kan dan een vraag doen aan de server waarna de server de xml returnt.

Zover werkt het. Alleen nu wil de klant dus ook nog statistieken welke client het meeste gebruikt wordt en gerewrite URLs.

Eerste oplossing was volgens mij simpel.
Ik gooi ze in een database. Dan kan ik dus van de eigen (client)DB opvragen. Alleen hij heeft ook 'clients' zonder SQL.

Mijn ideeén bus is leeg. Hebben jullie nog ideën?

[Gurbe de n00b]

Om hoeveel data gaat het ?

Misschien wegschrijven naar een tekstbestandje ?

[BlackWhizz]

De server schrijft xml bestanden weg van ongeveer 500 rijen groot (kan minder zijn als er niet meer in de categorie staat). DIt zijn rijen die ongeveer 5 kolommen bevatten.

De server schrijft ze al weg in .xml bestanden om SQL load te besparen.

[ Voor 17% gewijzigd door BlackWhizz op 13-11-2007 21:50 ]

[AndriesLouw]

Ik denk dan gelijk aan frames, of AJAX requests naar de "main server" toe. Hiermee zal die "main server" wel extra worden belast, maar je hebt in ieder geval dezelfde gegevens, en je kunt statistieken verzamelen.

Hierbij neem ik aan dat je PHP gebruikt voor webpagina's, en dat er op de clients ook webpagina's met de gegevens van de "main server" worden geserveerd.

Edit:
Ik zie dat je afbeeldingen/films wel van de "main server" afkomen? Alleen de gallerijen (.html) worden dus vanaf de client geserveerd, en alle afbeeldingen (.jpg) dus van de "main server"? Dan kun je namelijk gewoon statistieken trekken uit het aantal aangeroepen afbeeldingen (en thumbnails).

Of je statistieken lopen alleen via javascript/frame. Hetzelfde dus als Google Analytics doet, daarmee roep je hun javascript aan op jouw pagina. Waardoor hun statistieken opbouwen.

[ Voor 40% gewijzigd door AndriesLouw op 13-11-2007 22:51 ]

[BlackWhizz]

AndriesLouw schreef op dinsdag 13 november 2007 @ 22:47:
Ik zie dat je afbeeldingen/films wel van de "main server" afkomen?

Nee. De database tabel gallerijen heeft liinks naar gallerijen.

Ajax requests voor statistieken. Eigenlijk was mijn bedoeling om het zonder ajax te doen. Als iedere server nou een request doet via die main server dan kan dat zo ook wel worden gedaan. Het is niet moeilijk die statistieken. Er wordt gewoon een tellertje op gehoogd per site. Geen uitgebreide dingen als browser info etc.

Het enige probleem is nog mod_rewrite.

[Voutloos]

BlackWhizz schreef op woensdag 14 november 2007 @ 07:03:
Het enige probleem is nog mod_rewrite.

En wat heb je al geprobeerd? Wat wil je precies als resultaat? Wat lukt er niet?

[YopY]

Ik zou zelf de database server extern bereikbaar maken zodat de 'subwebsites' om het zo maar te noemen allemaal verbinding met éénzelfde database kunnen maken. Via XML zou het ook wel lukken, maar dat is net iets meer werk lijkt mij. Aan de andere kant heb je wel minder beveiligingsproblemen daarmee - een databaseserver die overal bereikbaar is is misschien niet het veiligste.

[AtleX]

Ik zou niet je database extern bereikbaar maken, voordat 1 of andere hobbybob van een externe site je tabellen leegt. Waarom laat je de client niet gewoon in de querystring zijn ID meegeven? dingetjes.xml?client_id=<iets>) Die kan je dan in de DB gooien voor je statistieken.

[BlackWhizz]

Voutloos schreef op woensdag 14 november 2007 @ 07:50:
[...]
En wat heb je al geprobeerd? Wat wil je precies als resultaat? Wat lukt er niet?

Eigenlijk alleen de rewriterules.

Voor de rest vraag ik me af hoe ik die SEO-urls moet aanpakken zodat de client het juiste filmpje krijgt.

[Verwijderd]

AtleX schreef op woensdag 14 november 2007 @ 11:25:
Ik zou niet je database extern bereikbaar maken, voordat 1 of andere hobbybob van een externe site je tabellen leegt. Waarom laat je de client niet gewoon in de querystring zijn ID meegeven? dingetjes.xml?client_id=<iets>) Die kan je dan in de DB gooien voor je statistieken.

Als de topicstarter z'n berichten lees, moet er enkel informatie gelezen worden. Dus waarom geen Mysql-DB gebruiken en de sites laten connecten met een account die enkel leesrechten heeft?
Jou systeem kan ook maar dit is dan ook voor derden toegankelijk.

[BlackWhizz]

Verwijderd schreef op woensdag 14 november 2007 @ 20:51:
[...]


Als de topicstarter z'n berichten lees, moet er enkel informatie gelezen worden. Dus waarom geen Mysql-DB gebruiken en de sites laten connecten met een account die enkel leesrechten heeft?
Jou systeem kan ook maar dit is dan ook voor derden toegankelijk.

Maar dan krijg je heeeeeel veel DB load als er ongeveer 100 sites zijn die ook redelijk wat bezoekers hebben.

Zelf dacht ik iets als dat er RSS word gereturnt.
Bijvoorbeeld:
Client: /pop/mika_-_grace_kelly-250.html
Server: galleries/get.php?type=single&cat=pop&client={clientnaam}&name=mika_-_grace_kelly-250.html

Dan returnt de server RSS. Die kan gecached worden waardoor er minder DB load komt. Iedere dag word de cache geleegd voor het geval dat...

Kan dat?? Of is het onrealistisch?

[Voutloos]

Verwijderd schreef op woensdag 14 november 2007 @ 20:51:
Dus waarom geen Mysql-DB gebruiken en de sites laten connecten met een account die enkel leesrechten heeft?

Ik zou anders niet graag allemaal klanten/derden select rechten geven.
Al je query optimalisaties kunnen de deur uit en je kan ook al nooit meer de db structuur veranderen omdat je op een gegeven moment niet meer alle code van de clients in de hand hebt. Bovendien zijn ook select queries gevoelig voor query injection en kan je met alleen maar selects mysql op de knietjes krijgen, dus er zijn ook wat security issues.
Als je een bepaald soort data wil krijgen, via bepaalde input, dan maak je daar een interface voor.
En dan is er een heel scala aan technieken waar je uit kan kiezen. En om maar alvast een beginnetje bullshit bingo te doen: SOAP, RPC, RMI, RSS, eigen XML of http brouwsel, CSV.... leef je uit (of lees je in ).

[flashin]

Maak een WSDL van je software en maak clientsoftware die dat ophaalt.

MySQL load van 100 sites is echt niet heel boeiend hoor, en als dat wel zo is dan moet je toch maar eens denken om te investeren in een klein serverparkje.

[BlackWhizz]

flashin schreef op donderdag 15 november 2007 @ 09:44:
Maak een WSDL van je software en maak clientsoftware die dat ophaalt.

MySQL load van 100 sites is echt niet heel boeiend hoor, en als dat wel zo is dan moet je toch maar eens denken om te investeren in een klein serverparkje.

Dat weet ik, maar er moet veel ruimte zijn voor groeimogelijkheden. Enfin. Ik ga de oplossng uit de vorige post van mij doen.

[Korben]

Ik aannemen dat je bedoelt dat de server XML returnt, niet RSS. RSS is nogal beperkt, en als je het zou uitbreiden is het geen RSS meer, dus dan kun je net zo goed in XML je eigen formaat bedenken.

Als je de output van die XML wil cachen, dan zul je toch een behoorlijke cache aan moeten leggen, en ik denk dat het minder efficient is om die cache iedere keer te raadplegen (op een inefficiente manier) dan een fatsoenlijk database-ontwerp te maken en implementeren. Een databaseserver doet immers ook aan caching, en vaak op een zeer voor de tabel/data geoptimaliseerde manier.

[flashin]

Gebruik voor de server/client structuur gewoon bestaande oplossingen ipv zelf iets te verzinnen. Je zult merken dat dat uiteindelijk een stuk flexibeler is en qua load vrijwel niks uitmaakt.

[BlackIce]

Daarbij, als er meerdere sites op meerdere hostingpaketten draaien, is het misschien handiger om eens te kijken naar een eigen server (ook ivm de doorgroeimogelijkheden)