capisco, grazie. In effetti piu' di un computed field non era settato per memorizzare i dati nello lo storage annotation.
Provero' cosa cambia impostando questo storage. byez 2008/11/27 Yuri <[EMAIL PROTECTED]> > SauZheR at gOOgle ha scritto: > >> salve a tutti. >> >> Mi son trovato alle prese con una di quelle applicazioni lampo (noi qui le >> chiamiamo panzerotti) di raccolta dati, messo su in un paio di gg. Plone3, >> buildouts e company. >> >> Ho messo su il prodottino creando un ATContentType. Ma di particolare >> questa volta c'era un aggancio piuttosto stretto con un db relazionale e ho >> creato una decina di ComputedField agganciati a Zsqlmethod, e ho aggiornato >> gli indici/metadata del portal_catalog >> per avere tutto pronto durante le validazioni e viste varie. >> >> Il gruppo di dataentry (8 persone) sta lavorando da 3 gg e ha caricato >> circa 7000 oggetti. E tutto sembra funzionare da dio coi complimenti dei >> dataentry. >> >> Il problema (relativo) e' che il Data.Fs tende a crescere molto, nel giro >> di 8 ore supera i 2 giga, ma un pack lo riporta ad appena 60 mega!! >> >> I dataentry non fanno altro che "aggiungere nuovo elemento" (un campo >> matricola) e al salvataggio i computed field recuperano tutti i campi >> rimanenti. Non ci sono variazioni di workflow, modifiche agli oggetti (se >> non 1 ogni 50 o 100 inserimenti), insomma nn c'e' ragione che il data.fs >> possa crescere in questa maniera. >> >> Si puo' pensare che venga eseguita piu' volte una stessa operazione... ma >> anche se l'inserimento di un oggetto produce 10 modifiche (quindi 10 >> transazioni) sul data.fs ... questo sarebbe 10 volte piu' grosso (600 >> mega).... io qua ho 2 giga confrontati con 60 mega e rimango alquanto >> disorientato. >> >> > Prova su una copia dell'applicazione ad eliminare portal_factory per quel > content type. Inoltre è normale con archetype avere transizioni inutili e > quindi una crescita inutile del Data.fs. > > http://article.gmane.org/gmane.comp.web.zope.plone.devel/18462 > > >> We'd need more benchmarks and objective debugging to be sure, though. >> > > Some basic calculation: in our ZEO setup we have a throughput of roughly > 2-3 MB/second when reading from ZEO - writing is likely slower. If a > transaction size of let's say 100KB you can easily calculate how much write > per second > you can get in the best case (without having considered other bottlenecks). > So if someone raises the question "can Plone handle 100 concurrent users", > the answer is likely: no. > > Andreas > > > Possibly related to versioning. The transaction size reduces to 20KB >> with versioning disabled. But isn't versioning an explicit operation (you >> have to will out the "change not" field?..but anyway 20K is still too much. >> > > > Agreed this is still too much, but after packing the database without > versioning the size reduces to just a few bytes more, with versioning > enabled it stays considerably larger. > > In the default settings versioning is an implicit operation. Whenever you > change an item (be it using inline-edit or the edit screen) a new version is > created. The 'change note' is additional metadata you can provide. > > etc etc :) > > Vi siete mai trovati in una situazione del genere? >> >> alessandro. >> >> -- >> bye >> SauZheR >> ************************************ >> l'iterazione è umana... >> la ricorsione, Divina! >> ************************************ >> reply to: sauzher AT gmail DOT com >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Plone-IT mailing list >> [email protected] >> http://lists.plone.org/mailman/listinfo/plone-it >> http://www.nabble.com/Plone---Italy-f21728.html >> > > > _______________________________________________ > Plone-IT mailing list > [email protected] > http://lists.plone.org/mailman/listinfo/plone-it > http://www.nabble.com/Plone---Italy-f21728.html > -- bye SauZheR ************************************ l'iterazione è umana... la ricorsione, Divina! ************************************ reply to: sauzher AT gmail DOT com
_______________________________________________ Plone-IT mailing list [email protected] http://lists.plone.org/mailman/listinfo/plone-it http://www.nabble.com/Plone---Italy-f21728.html
