Hallo Support,

ich muss mal etwas über die 3.0er Version meckern:
Jeden Tag lesen wir zigtausende Logdaten ein. Allein heute früh
wieder 15.000 Zeilen (und das sind eher wenig). Klicken wir dann
nach dem Einlesen auf Okay, dauert es jetzt je nach Zeilenanzahl
etwa 1-2 Minuten(!!), bis der Shop wieder auf Mausklicks reagiert.
Wird denn so etwas nicht mal vorab mit VIELEN Logs getestet??
Da hat uns das 'alte Datenformat' dann doch besser gefallen.
Einen wirklichen Performanceschub auf lokaler Ebene können wir
bisher leider nicht feststellen.

Ansonsten sind natürlich viele neue Möglichkeiten in der 3er drin.
Trotzdem ist ein schneller lokaler Shop (auch bei großen Datenmengen)
immer noch eines der wichtigsten Kriterien für uns. An die relativ lange
Speicherzeit eines größeren Projekts hatten wir uns langsam gewöhnt
(trotz regelmäßigen Löschens sämtlicher Statistiken!!). Jetzt aber auch
noch diese lange Wartezeit beim Einlesen der Onlinedaten - das nervt
jetzt schon ziemlich stark. Macht ein Mitarbeiter das ein paar Mal am Tag,
habe ich ihm eine zweite Frühstückspause geschenkt.

Mein Wunsch daher (schon seit Jahren): auch im lokalen Bereich
optional mit einer 'echten' DB zu arbeiten. Teilweise sind im Shop
bei uns mehr Daten drin als in der WaWi. Und keine gute WaWi
kommt ohne lokale DB-Anbindung aus.

jg

Hallo jg,

guck mal hier:
http://www.shoppilot.net/pf/aktuelle_faq_haeufige_fragen/tutorial_umfangreiche_shops_unter_liveview_mit_mysql_betreiben-t889.0.html;msg3354#msg3354

Hallo dobra,

> guck mal hier: ...
LiveView und Access oder MySQL simuliert nur den _Onlinebetrieb_ auf lokaler Ebene.
Mir geht es jedoch um die direkte Verwaltung der Shoppilotdaten in SP selbst.
Ich meine also die Daten, die gespeichert werden, wenn du im Shop Strg+S drückst.
Jetzt speichert SP damit die Shop-Einstellungen + DATEN. Und genau das hätte
ich gern getrennt.

jg

Nachtrag an den Support:
Natürlich haben wir auch gesehen, dass mit sqlite in eine gute Richtung
gearbeitet wird. Nur sollte das System dann beim Einlesen der Onlinedaten -
wie jetzt bei uns -  nicht noch langsamer werden als früher...
Die *.sqlite-Datei ist übrigens aktuell bei uns 120 MB groß.

jg

Hallo jg,

Zitat
Allein heute früh
wieder 15.000 Zeilen (und das sind eher wenig).

Ich hätte folgende Optimierungsvorschläge:

1. Bei Projekt>Optionen>Logfiles

Hosts ausschließen (funktioniert nur wenn der Server eine Namensauflösung hat)
msnbot.msn.com,inktomisearch.com,googlebot.com,looksmart.com

Browser ausschließen:
crawler,Crawler,miva.com

2. Bei Projekt>Optionen>Automatisierung
Downloadmethode automatisch wählen (ja)
Ab Anzahl umspeichern = 1000


3. Speicherung des Projekts auf einem Netzlaufwerk ist
aus  Gesichtspunkten der Performance nicht zu empfehlen.
Besser ist es man arbeitet per Terminal direkt auf dem  Server.

Gruss hop

Hallo hop,

Danke für die Hinweise -> 1. und 2. haben wir gemacht.
Trotzdem ändert es nichts daran, dass 1000 Zeilen in der 3er Version jetzt
etwa 10-15 Sekunden benötigen, bevor die Maus wieder reagiert.
Und das Ganze läuft bei uns fast immer per 'Terminal' auf dem Server.
Die Speicherung des Projekts an sich scheint übrigens _nicht_ langsamer
geworden zu sein. Es geht also nur um das Einlesen der Onlinedaten.

Kann man das Einlesen der Statistik vielleicht ausschließen oder nur
optional einstellbar machen? Uns wäre generell eine 'Online-Statistik' lieber,
auch weil viele unserer Filialshophändler immer wieder danach fragen.
Lokal sind für uns nur die Änderungen der Artikeldaten, Kunden und
das Einlesen von Bestellungen interessant.

2. Idee: Es gibt doch die Möglichkeit, die Logfiles zusätzlich in einer externen
Datenbanktabelle abzulegen. Uns würde es reichen, wenn die Logfiles
NUR in dieser Tabelle landen und nicht gleichzeitig auch noch im Shopprojekt.

> 3. Speicherung des Projekts auf einem Netzlaufwerk ist
> aus  Gesichtspunkten der Performance nicht zu empfehlen.
> Besser ist es man arbeitet per Terminal direkt auf dem Server.
ShopPilot Enterprise 3.0 BB-OL kostet ohne MwSt. knapp 6500 EUR.
Das können sich nur mittelständische Firmen leisten, die in der Regel
heutzutage auch mit Netzlaufwerken arbeiten. Anders sind optimale
betriebsinterne Abläufe auch nicht mehr zu organisieren.
Wir arbeiten hier bei uns an 9 Rechnern + MS 2003 Server + Linux-FW,
inkl. Kat7 und GB-Netzkarten.
SP wird bei uns schon seit mindestens 1,5-2 Jahren per Remotedesktop
von 2-3 PCs gesteuert, was mich aber seit ebenso langer Zeit auch
nicht wirklich begeistert. Ein echter Terminalserver ist mir
1. zu teuer - ich gehe davon aus, dass Sie den mit Ihrem
'Terminal'-Hinweis NICHT meinten - und
2. halte ich das auch nicht für 'die' Lösung, um mit SP besser arbeiten
zu können. Hier erwarte ich eine Lösung vom Software-Hersteller.
Nur so macht dann auch eine (Mehr)-Benutzerverwaltung erst Sinn,
die wir momentan übrigens gar nicht nutzen, weil ich nicht 4 Mitarbeitern
einen Serverzugang einrichten will und das auch nicht die Lösung sein kann.

Wie gesagt, ich erwarte ja nicht unbedingt Shoppilot als echte Netzwerkversion.
Aber für den o.g. Preis sollte die Software wenigstens auf einem Netzlaufwerk
abgelegt werden können und 'normal' über diverse Arbeitsplatzrechner
bedienbar bleiben. Das ist aus unserer Sicht das Problem.

Grüße, jg

Hallo jg,

ich glaube wir reden aneinander vorbei.
Keines wegs habe ich gemeint, dass man das Shop-Projekt nicht
auf ein Netzlaufwerk liegen kann. Kann man natürlich.
Nur meine ich die etwas schnellere Arbeiitsweise hat man dann,
wenn man sich per Remotdesktop (das meinte ich mit Terminal) direkt
auf dem Server einloggt. Dann brauchen nämlich die Daten nicht
über das Netzwerk verschoben zu werden.

Gruss hop

> ich glaube wir reden aneinander vorbei.
Nein. Ich habe Ihre Ausführungen vorher schon genau verstanden.

> Keines wegs habe ich gemeint, dass man das Shop-Projekt nicht
> auf ein Netzlaufwerk liegen kann. Kann man natürlich.
Sicher, aber mit größeren Datenbeständen ist dann ein normales
und effektives Arbeiten nicht mehr möglich.

> Nur meine ich die etwas schnellere Arbeiitsweise hat man dann,
> wenn man sich per Remotdesktop (das meinte ich mit Terminal) direkt
> auf dem Server einloggt. Dann brauchen nämlich die Daten nicht
> über das Netzwerk verschoben zu werden.
Ist mir völlig klar. Ich hatte dazu auch bereits geschrieben, dass wir
schon seit fast 2 Jahren per Remotedesktop mit Shoppilot arbeiten.
Remotedesktop ist aber nicht dazu gedacht, Mitarbeiter wegen einem
Programm permanent direkt auf einem Netzwerkserver arbeiten zu lassen.
Dafür gibt es nun mal die Clients. Und auch wenn wir Remote arbeiten,
löst das derzeit nicht unser Problem beim Einlesen der Onlinedaten.
Hier hat mit der neuen BETA erstmal eine deutliche Verlangsamung
von Version 2.8 zu 3.0 stattgefunden.
:(

jg

ZitatHier hat mit der neuen BETA erstmal eine deutliche Verlangsamung

Wieso BETA ?
Die Release Version ist doch schon draussen (keinne Mail erhalten ?). Ob es in der BETA noch irgendwelche Probleme gab die
in der Release gefixt sind mag ich nicht ausschließen.

Gruß hop

> Wieso BETA ?
> Die Release Version ist doch schon draussen (keinne Mail erhalten ?)
Doch. Wir verwenden natürlich die neue Release Version.
Ich war nur in Gedanken immer noch bei einer 'Beta'...
jg

Zitat
Trotzdem ändert es nichts daran, dass 1000 Zeilen in der 3er Version jetzt
etwa 10-15 Sekunden benötigen, bevor die Maus wieder reagiert.

Ich habe nochmal getestet. Dieses Verhalten kann ich nicht nachvolllziehen. Ich konnte beim Einlesen von deutlich mehr als 1000 Zeilen überhaupt keine Verzögerung feststellen.

Nichts desto trotz werden wir eine Möglichkeit einbauen, die Funktion zu deaktivieren.

Gruss hop

Zitat von: admin am September 19, 2008, 11:20:43
Ich habe nochmal getestet. Dieses Verhalten kann ich nicht nachvolllziehen. Ich konnte beim Einlesen von deutlich mehr als 1000 Zeilen überhaupt keine Verzögerung feststellen.

Hallo - ich muss auch mal was dazu sagen:

Ich habe das - was JG beschreibt - auch festgestellt.
Bei uns sind es zwar nicht so viele Zeilen - aber nach dem Einlesen und OK dauert es eine gewisse zeit, bis das WC wieder reagiert.
(anfänglich dachte ich erst, das Workcenter hätte sich aufgehangen..)
Gerade 3900 Zeilen eingelesen - OK - 12 Sekunden Stillstand (PC: AMD 64 3000+ 1GB Arbeitsspeicher, SATA, XP)
Bei 15000 Zeilen dürfte das dann etwas länger dauern.

Grüße von Andi

Hallo,

> Ich habe nochmal getestet. Dieses Verhalten kann ich nicht nachvolllziehen.
> Ich konnte beim Einlesen von deutlich mehr als 1000 Zeilen überhaupt
> keine Verzögerung feststellen.
Wir haben heute früh lokal komplett die Onlinedaten gelöscht:
Logfile, Statistik, Suchdaten, Aufträge (bis Ende August)

Jetzt wurden soeben wieder Onlinedaten eingelesen: ca. 2700 Zeilen
Klick auf OK, Dauer bis der Shop wieder reagierte: 1 Minute und 15 Sekunden
(MS Server 2003 mit Intel P4, 3GHZ, 2GB Ram)
Heute früh dauerte es etwa 3 Minuten(!), nachdem die Daten der Nacht eingelesen wurden.
Was wurde denn an dieser Stelle geändert? In Version 2.8 lief das ja
auch bei uns problemlos. Was passiert in dieser langen Zeit...??

noch ein paar Hinweise:
Wir haben etwa 8 Subkataloge mit ca. 50.000 Datensätzen.
Hauptkatalog mit etwa 6000 Datensätzen.
Unsere *.sqlite-Datei ist nach dem Löschen aller Onlinedaten
immer noch 127 MB groß. Darin werden wohl die Statistikdaten
nicht gespeichert, oder?

jg

Hallo jg,

die Statistkdaten werden ab der 3.0 in der SQlite DB gespeichert. Hiermit wollen wir ermöglichen, dass man Auswertungen auch über einen beliebigen Zeitraum machen kann. Wir haben jetzt auch festgestellt, dass das Einfügen von neuen Daten manchmal auch länger dauern kann, daher die Verzögerung. Die Ursache kennen wir allerdings noch nicht genau. Wir brauchen noch ein wenig Zeit und hoffen, dass wir nächste Woche eine Lösung finden.

Gruß hop

> die Statistkdaten werden ab der 3.0 in der SQlite DB gespeichert.
Die Sqlite-Datei wird immer größer obwohl ich im WC die Statistik,
Suchdaten etc. wieder gelöscht habe (ist mittlerweile 142 MB groß).
jg