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
