Door
Dennis WhoCares
op 26-09-2016 20:27
gewijzigd op 26-09-2016 20:35
3.195 views
Hoi allemaal,
ik ben aan gigantische import aan het doen met een csv file.
Ik upload een bestand mbv een formulier, daarna kan ik dynamisch kiezen welke kolom bij welke tabel field hoort, en dan verwerken.
Dit process bevat importeren, bestanden downloaden, snapshot maken van video's, afbeeldingen bewerken (vierkant maken, en 4 verschillende formaten)
Iedereen begrijpt dat afhankelijk van wat voor soort bijlagen, en het aantal ervan zorgt voor nogal lange duur van uitvoeren. Dus om de timeout te omzeilen houdt alle gegevens bij in een sessie (gekozen kolom->field, filenaam waarmee gewerkt wordt, en de laatst geimporteerde record) en redirect terug naar de pagina (nu ondertussen naar een 2e en 3e))
Helaas geeft mijn firefox en chrome error 310 terug na enige tijd (Ongeveer na 15-18 redirects)
Ik zie het niet bepaald zitten om elke 300 records alles weer opnieuw te doen om m'n browser maar te gehoorzamen. Het moet juist andersom.
Hoe kan ik dit fixen? Ik zit nou al weken hier aan te werken. Eigenlijk voorheen importeer problemen, en het dynamisch maken van importeer mogelijkheden, downloaden van externe bestanden adv een url etc.
Heeft iemand een workaround hiervoor? Ik hoop het ten zeerste
Moet ongeveer 20.000 records doen om te beginnen, en naderhand zullen deze regelmatig ook nog eens een 'UPDATE' ondergaan.
Daarbij: je hoeft het helemaal niet via de browser te doen. Je kunt prima het proces starten in de browser (bijvoorbeeld via een upload), en dan laten overpakken door bijvoorbeeld een cronjob, die op een statuspagina weergeeft hoe ver de import is.
Daar had ik eigenlijk nog nieteens aan gedacht :-$
Thanks! Dat is natuurlijk de beste oplossing.
nohup en & echo $! zorgen dat eea op de achtergrond uitgevoerd wordt.
/usr/bin/php is de plek waar php staat.
Het path naar de scripts voor cli staat in de constante CLI_DIR en print.php het script dat ik aanroep.
omdat we hier geen print.php?type=a&id=10 kunnen gebruiken, staan de argumenten er gewoon achter.
net als je "cp a b" kunt doen om het commande cp te vertellen dat hij iets moet doen, kan dat ook voor een php script.
met > outputfile kun je de output die eventueel komt, wegschrijven naar een file, om later terug te kijken of alles zonder fouten verlopen is.
Je kunt uiteraard ook in de database, of naar een mailbox je meldingen laten versturen.
nohup en & echo $! zorgen dat eea op de achtergrond uitgevoerd wordt.
/usr/bin/php is de plek waar php staat.
Het path naar de scripts voor cli staat in de constante CLI_DIR en print.php het script dat ik aanroep.
omdat we hier geen print.php?type=a&id=10 kunnen gebruiken, staan de argumenten er gewoon achter.
net als je "cp a b" kunt doen om het commande cp te vertellen dat hij iets moet doen, kan dat ook voor een php script.
met > outputfile kun je de output die eventueel komt, wegschrijven naar een file, om later terug te kijken of alles zonder fouten verlopen is.
Je kunt uiteraard ook in de database, of naar een mailbox je meldingen laten versturen.
Hi Ivo,
ik ben idd bekend met parameters doorgeven in CLI aan php.
de $argv array.
Jouw voorbeeld, gebruik je dit met shell_exec($command) ??
Stopt de browser dan wel, maar gaat de shell gewoon door (server side), dus kan de browser gesloten worden?
klopt. browser maakt de pagina gewoon af, terwijl dit proces op de achtergrond draait.
Daarna kun je een andere pagina bezoeken, site verlaten; pc afsluiten etc.
Ik gebruik dit om een stapel van een stuk of 100 pdfs te maken en naar de printer te sturen (door de server). Daar hoeft de gebruiker niet op te wachten achter zijn pc.
klopt. browser maakt de pagina gewoon af, terwijl dit proces op de achtergrond draait.
Daarna kun je een andere pagina bezoeken, site verlaten; pc afsluiten etc.
Ik gebruik dit om een stapel van een stuk of 100 pdfs te maken en naar de printer te sturen (door de server). Daar hoeft de gebruiker niet op te wachten achter zijn pc.
*praise the lord*
je bent geweldig!!!!
moet ik trouwens niet && echo gebruiken ?
[size=xsmall]Toevoeging op 29/09/2016 07:42:41:[/size]
Werkt geweldig! Enorm bedankt Ivo.
Hij is nu gewoon op z'n gemak aan het importeren :)
Houdt ook een log file bij, die ik 'live' kan inzien dmv jquery requests :)
Ik zeg, close topic :)
Nogmaals alle anderen bedankt voor de reacties!
klopt. browser maakt de pagina gewoon af, terwijl dit proces op de achtergrond draait.
Daarna kun je een andere pagina bezoeken, site verlaten; pc afsluiten etc.
Ik gebruik dit om een stapel van een stuk of 100 pdfs te maken en naar de printer te sturen (door de server). Daar hoeft de gebruiker niet op te wachten achter zijn pc.
Hi Ivo,
klein vraagje over deze aanpak. Ik heb op een ander project mijn backend ook gemaakt op het basis van het MVC model en 'seo friendly' urls icm .htaccess
Dit kan ik niet zo aanroepen met de /usr/bin/php commando.
Is hier een workaround voor, of is het gewoon beter om hier ook gewoon een statisch script van te maken?
Het rewriten wordt door Apache gedaan, nog voor PHP door Apache aangesproken wordt. Maar dat is een heel andere benadering.
Niet voor niets staat in mijn voorbeeld ook CLI_DIR, de directory waarin de command line scripts staan. Die staan bij mijn opzet buiten de normale ingang die altijd via index.php loopt.
Het rewriten wordt door Apache gedaan, nog voor PHP door Apache aangesproken wordt. Maar dat is een heel andere benadering.
Niet voor niets staat in mijn voorbeeld ook CLI_DIR, de directory waarin de command line scripts staan. Die staan bij mijn opzet buiten de normale ingang die altijd via index.php loopt.
