Ik ben bezig een registratie applicatie voor activiteiten op een school te schrijven.
Dit is de opzet:
Het is de bedoeling dat zo'n 450-550 gebruikers een account hebben. Ze kunnen zich inschrijven voor een door de administrator (in het adminpanel) aangemaakte activiteit/activiteiten. Het is de bedoeling dat bij inschrijving er een pdf (die hun kaartje is) naar het emailadres van de gebruiker wordt verzonden. Deze kan dan bij de balie betalen, om zo een geldigheidsstempel te verkrijgen.
Technisch is dit volgens mij realiseerbaar, ik heb de web-literatuur over php pdf-library's er al op nageslagen (tips zijn, desondanks, welkom!). Echter, wat mij gisternacht (eigenlijk vandaag dus ), in bed te binnen schoot: zou het niet veel serverkracht en diskruimte gaan kosten (500 pdf's * 1-2 mb = +/- 1gb aan maximale ruimte (als iedereen tegelijk de pdf zou requesten, een onwaarschijnlijke situatie, maar het gaat over een inschrijfperiode va een dag of vijf, dus er is redelijk wat capaciteit nodig). Ik dacht eraan de pdf's te verwijderen nadat ze gemaild zijn (schijfruimte besparen). Schijfruimte is redelijk goedkoop, maar ik heb geen verstand van serverbelasting... Wat denken jullie? Is dit haalbaar op een shared servertje, tot een maximum van 3 euro per maand of is het irrealistisch?
Hebben jullie tips voor hostingaanbieders met een krachtige server (tegen een zacht prijsje )?
Hoe meet je serverbelasting (als je nog lokaal test)? Liefst ook voor mac, maar als het niet anders kan kijk ik of ik ergens bij een windows bak kan gaan zitten...
Kan geen kwaad, op mijn werk draai ik soms 3000 excels / pdf's tijdens de nacht op een gewone server (wel .net).
Je moet de bestanden niet opslaan eh, hou de gegevens gewoon bij in een db en verwijder het bestand na het mailen of hou het gewoon ff in het geheugen ipv op te slaan op de schijf.
Je kan ook altijd een soort van queueing schrijven, die houdt dan bij welke gebruikers nog hun mail moeten krijgen en verwerkt dan de queue rij per rij. Op die manier mag iedereen te samen zich inschrijven, de server gaat het dan toch nog 1 per 1 verwerken via een job. Het enige nadeel dat je dan hebt is dat de mail niet direct na het inschrijven verzonden wordt. Maar die tijd kan je zelf wat regelen door de frequentie van de job aan te passen.
Ik zal me in dat queueing gaan verdiepen zometeen.
Ik heb wat vraagjes:
Hoe bewaar je iets "even in het geheugen"? (In c# moest je accoleren, maar hoe zit dat in php?)
Hoe weet je hoeveel geheugen beschikbaar is?
Hoe mail je een bestand dat niet is opgeslagen op de server (als dat in het geheugen kan worden geaccoleerd: hoe roep je het dan aan?)
Bij voorbaat dank voor de moeite!
Die database waarin een record wordt geschreven voor een kaartje vind ik een heel goed plan!
Gewoon een tabel uitgegeven kaartjes:
id
naam_leerling (die moet er voorgedrukt op)
uitgifte_tijdstip
klas_leerling
introducee_janee
introducee_naam
Dat bedoelde u toch? (en dan daarvan uit pdf's genereren...)
nope, moet kunnen. Tenzij je een debiel groot pdf bestand heb, maar dat betwijfel ik. Of je moet echt een slechte server hebben, maar t ergste wat nu gaat gebeuren is dat je een seconde langer duurt als alles tegelijk wilt. Dat is echt niet erg, die hoeveelheden load
Idd, 14 per uur is zeker niet de moeite om queueing toe te passen. Volgens mij geeft dit geen probleem.
Ivm dat opslaan in het geheugen, ik weet het niet zeker meer maar bv bij het maken van afbeeldingen met php kan je de afbeelding in het geheugen bewaren, fysisch komt dit dan in een temp folder op de server, je afbeelding is dan als het ware een variabele die je kan gebruiken om door te mailen of te tonen in de browser. Met afbeeldingen weet ik dat dit lukt, misschien ook met pdf bestanden.
1 a 2 mb voor een pdf is wel enorm groot, wij krijgen binnen het bedrijf bestellingen van 40+ pagina's binnen aan ingescannede files (in 1 pdf) en die zijn nog geen 2 mb groot.
Is misschien inderdaad een slechte schatting (de oningevulde dummy woog dat wel, maar dat kwam, zo blijkt nu, omdat het een op zeer hoge kwaliteit ingesteld CMYK document uit indesign was, die comprimeer ik nog wel een eindje, want het is toch voor consumentenprinters.) Bedankt voor de tip nog.
Naar dat tmp ga ik even kijken, alleen zou ik niet weten welk voordeel het tov een gewone map heeft.
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
), in bed te binnen schoot: zou het niet veel serverkracht en diskruimte gaan kosten (500 pdf's * 1-2 mb = +/- 1gb aan maximale ruimte (als iedereen tegelijk de pdf zou requesten, een onwaarschijnlijke situatie, maar het gaat over een inschrijfperiode va een dag of vijf, dus er is redelijk wat capaciteit nodig). Ik dacht eraan de pdf's te verwijderen nadat ze gemaild zijn (schijfruimte besparen). Schijfruimte is redelijk goedkoop, maar ik heb geen verstand van serverbelasting... Wat denken jullie? Is dit haalbaar op een shared servertje, tot een maximum van 3 euro per maand of is het irrealistisch?
)?
Gesponsorde links
Actiefste leden van de maand
