Terug naar de voorpagina
Home Nieuw Vraag & Aanbod Forums Artikelen Bedrijvengids Zoeken

Vorige | 1 | 2 | Volgende 11 - 19 van 19

   Bram Brambring, brambring.nl
16 nov 2011 21:19 
De import van kleinere feeds gaat veel beter. Wat dat betreft is 50*4.000 items een stuk beter dan 1x200.000 hier zou de feed opknippen dus helpen.

probleem is echter niet alleen de import van de items maar ook de weergave, dat zijn namelijk nog eens veel 'duurdere' queries.

Maw de timeout limiet is een mooie waarschuwing dat je dingen probeert waarvoor de server niet bedoelt is. Kun je een hoop moeite gaan doen je items TOCH te importeren maar vroeg of laat geeft je host je een 410




   Gerron Mulder, Particulier
17 nov 2011 02:47 
Probleem zit hem niet bij de database. 200.000 zou ook op shared hosting peanuts moeten zijn als je niet super veel kolommen en indexes hebt.

Probleem zit hem in het feit dat de feed waarschijnlijk op XML is gebaseerd? XML kun je niet streamen (wat je wel met csv feeds kunt doen) waardoor je de gehele DOM van een XML feed in het geheugen moet stoppen. Daarvoor heeft het PHP process op shared hosting meestal niet genoeg geheugen. Als je de feed in onderdelen kunt ophalen, wordt het al een stuk makkelijker.

   R. Kapitein, Smoved
17 nov 2011 08:14 
XML Valt ook prima te streamen, dus dat argument gaat niet op. Probleem zit hem eerder in de execution time.

   Bram Brambring, brambring.nl
17 nov 2011 09:08 
XML kun je inderdaad prima streamen en het geheugen gebruik valt dan zeker met datafeeds ( relatief kleine 'elementen' ) mee.

CSV is echter VEEL sneller, daar is een hoop winst te halen.

200K items is voor een dedicated server wellicht peanuts, voor een shared host kan het teveel zijn. Je deelt je resources met een hoop andere websites dus goed kans daat jouw indexen en queries niet lekker in de buffers blijven staan maar elke keer van disk gelezen moeten worden en dat ga je bij grote tabelen merken. En dat geld trouwens ook voor het bijwerken van de indexen tijdens het inlezen van de feeds.


   Martijn Dwars, 2Bytes
17 nov 2011 09:55 
"probleem is echter niet alleen de import van de items maar ook de weergave, dat zijn namelijk nog eens veel 'duurdere' queries."

Zou je ook dat weer voor me willen onderbouwen? MySQL kan met gemak miljoenen rijen aan, dus 200.000 rijtjes zal ook wel lukken. Volgens mij gaat het hier ook helemaal niet om zulke geavanceerde queries. En als je met geoptimaliseerde queries toch nog te lange execution times maakt, moet je misschien je database schema onder de loep nemen. Eventueel kun je query results zelfs cachen, bespaar je weer wat..

   Jordy van D., Particulier
17 nov 2011 10:56 
Ik ben benieuwt wat je precies wilt?
Wil je 200k producten invoegen in een tabel of uitlezen en tonen op je website?

Ik neem aan niet het laatste geval?

   Bram Brambring, brambring.nl
17 nov 2011 11:43 
@martijn

uiteraard kan mysql miljoenen rijen aan, maar dat gaat wel ten koste van executie tijd. En voor grote tabellen is mysql performance zekers een issue. Dan ga je tunen, of zet je de database apart van de webserver.

klein is beter, zelfs big G gebruikt tig-duizenden kleine server ipv een paar grote


   Gert-Jan W, Woudnet
17 nov 2011 16:59 
Bedankt voor alle nuttige toevoegingen!

Het gaat om een productfeed voor een affiliate site, dit is idd een XML feed.
Ik heb de link
http://www.ozerov.de/bigdump/
even in favorieten gezet, ga deze zeker uit proberen.

Ik ben het met R. Kapitein eens dat het hem waarschijnlijk in de execution time zit.
En begrijp nu ook dat deze beveiliging er in zit om de server te beschermen.

   John T., SystemDeveloper.NL
17 nov 2011 23:31 
Het punt van een feed is niet zozeer het downloaden... daar heb je geen snelle disks voor nodig. Het gaat zich erom wat je daarnį met je import gaat doen.

Normaal download je eerst je feed periodiek via een cronjob (kost geen load tenslotte) en dan ga je die feed pas verwerken. Of in zijn geheel, of in delen of parallel.

En juist voor dit verwerken (zoeken, verwijderen, updaten, rubrieken matchen etc.) wil je snelle disks (en cpu power) hebben want dan heb je minder lang een hoge load en dus meer tijd dat je websites soepel draaien.
En ook dit doe je via een cronjob zodat je geen last hebt van execution times of andere onzin en dat je wel controle hebt over de load die je op de server veroorzaakt.

Op shared hosting moet je nu eenmaal wat meer rekening houden met anderen dus 'even' een aantal batches van een paar 100K producten op vol gas de db instampen zal je toch niet in dank afgenomen worden.
Op een goed vps of eigen server ligt niemand er wakker van als je boel 15 minuten plat trekt.

   Robin L., Roboo
18 nov 2011 12:32 
Als je op shared hosting zit kan je vast wel bij je hoster informeren naar mogelijkheden om bijv. de feed te importeren vanuit de shell/console etc..

Daarnaast zou het een optie zijn om met een batch de XML om te zetten naar een SQL import, en deze uit te voeren met bigdump, maar dat is wel een aardig 'primitieve' oplossing..


Vorige | 1 | 2 | Volgende 



 
© Copyright TargetMedia 2001-2012 | Mobile | Premium SMS | Micropayments | Muziek downloaden | Ringtones Bekijk bezoekers statistieken RSS feed