projekt kivitendo

Mach bitte mal in der Config unter debug folgendes an:

[debug]
global_level = REQUEST_TIMER TRACE

und gib mir für die jeweiligen Requests die lange dauern die Ausgabe in der Logdatei, dann schau ich mal woran das liegt. Leider sind immernoch viele Ecken im Programm nicht darauf ausgelegt, dass man sehr viele Kundendaten hat. Ein paar zigtausend Belege oder Waren sind ok, zuviele Kunden dagegen schlecht getestet, weil kaum jemand solche Mengen hat.

Hallo
ich hab das debuglog als Datei angehängt.
hab zwei Positionen eingegeben.
Werner

Ich habe nur ganz kurz draufgeschaut, es scheint an _get_customers in SL/Form.pm zu liegen, da werden einmal alle Kunden aus der Datenbank ausgelesen, und es gibt dort auch noch eine Vertreter-Klausel im Query, wobei ich nicht weiß, ob das in dem Fall aktiv ist. Das lässt sich jedenfalls garantiert optimieren.

Jo, das hab ich erwartet.

Falls Du das machen willst Geoffrey, ich hab das vor Jahren schonmal in der Hand gehabt. Das Problem war da, dass die multibox für Kunden erst beim template rendern entscheidet ob sie Dropdown oder Textinput anzeigt. Deshalb ist ein Limit zu dem Zeitpunkt noch nicht bekannt. Ich würde da wie folgt rangehen:

1. Rausfinden wo im Programm überall get_lists(customers => ...) benutzt wird, was ja untendrunter _get_customer aufruft. Vor allem welche actions das triggern, ich meine da gab es irgendeinen wirren case mit update().
2. Rausfinden wie man die so bauen kann, dass sie schon da wissen wieviele sie maximal brauchen (alle ist niemals sinnvoll)
3. Das dann sinnvoll beschränken.

Auch: 80000 Kundendaten? Wtf?

Die andere Alternative wäre auf Customerpicker umzusteigen, was langfristig eh das Ziel wäre, dann wäre diese Arbeit auch überflüssig. Aber ich vermute das in allen Masken anzupacken wäre derzeit noch mehr Arbeit als das get_lists zu verbessern.

Customerpicker wäre toll, ist aber nicht einfach zu machen weil der update Mechanismus auf check_name basiert. Und der check_name Code ist genauso gut anzuschauen wie das Innere der Bundeslade.

Gibt es eine Möglichkeit die Performanzverbesserung schon vorher zu messen?

Z.B.:
Schritt 1: Einen Kunden fest auswählen.
Schritt 2: Position hinzufügen
Schritt 3: sub check_name übergehen (direkt ein return 1 am Anfang setzen)

Mich würde in diesem Schritt einfach die maximal erreichbare Einsparung interessieren.

Hilft es ansonsten die multibox für diesen Fall hart mit dem Wert "Freitextfeld" zu verbinden? Sodass diese Abfrage überflüssig wäre?

Andere Idee, rein zur Analyse: Was passiert wenn man in is.pl in sub form_header die customers erst gar nicht abholt. Also so:

$form->get_lists("taxzones" => ($form->{id} ? "ALL_TAXZONES" : "ALL_ACTIVE_TAXZONES"),
"currencies" => "ALL_CURRENCIES",
# "customers" => "ALL_CUSTOMERS",
"departments" => "all_departments",
"price_factors" => "ALL_PRICE_FACTORS");

Hier wäre es auch schon intelligenter die Liste nicht bei jedem Aufruf der Form neu zu generieren (jaja, altes konzeptionelles Problem).

Jan: Was dann passiert ist, dass es schnell und kaputt ist. Die falsche Antwort schnell zu kriegen ist aber nicht sonderlich schwer.

Das korrekt und schnell zu machen, ist die Herausforderung die ich oben beschrieben habe.

Ja, das ist richtig. Mir geht es nur um eine Einschätzung inwiefern man hier näherungsweise "rankommt".

Nein. Nicht näherungsweise.