Shopsystem ShopPilot
ShopPilot => Allgemein => Thema gestartet von: jg am September 18, 2008, 08:29:41
-
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 (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,
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
-
Hier 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
-
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
-
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
-
Hallo,
im Downloadverzeichnis liegt nun die ShopPilot Version 3.00.01.
Die Zugriffszeiten auf die Langzeitstatistik wurden in dieser Version um einiges optimiert.
Bei einigen unserer Testdaten dauerte das Eintragen der Daten anstatt 4 Minuten nun nur noch 5 Sekunden :)
Ausserdem kann die Langzeitstatistik nun begrenzt und auch ganz deaktiviert werden (Online-Daten > Langzeitstatistik > Einstellungen).
Zur Grösse der SQLite-Datei:
Die bisherige Option "Statistikdaten löschen" beeinflusst die Langzeitstatistik nicht.
Über die oben genannte Zeitbegrenzung kann die Dateigrösse aber konstant gehalten werden.
Bevor die nächsten Schreckensmeldungen eingehen: ;)
Mit der neuen Version wird die alte SQLite-Datei erneut anwachsen.
Das ist aber nicht weiter dramatisch, da innerhalb der Datei eine ganze Menge wieder als frei markiert wird.
Bei den nächsten Eintragungen wird dann erst mal der so markierte freie Platz verbraucht, bevor die Dateigrösse wieder wächst.
-
Hallo ahe,
> Die Zugriffszeiten auf die Langzeitstatistik wurden in dieser Version um einiges optimiert.
Das hat wirklich geklappt. Vielen Dank!
Jetzt haben wir noch das Problem, dass mit den automatischen Importoptionen
falsche Zeichen im Shop dargestellt werden. Auch hier würden wir uns natürlich
über eine baldige Lösung sehr freuen.
jg
-
> Jetzt haben wir noch das Problem, dass mit den automatischen Importoptionen
> falsche Zeichen im Shop dargestellt werden. Auch hier würden wir uns natürlich
> über eine baldige Lösung sehr freuen.
Hallo Support,
ich wollte noch einmal nachfragen, ob sich nicht doch eine Lösung für unser
Problem finden lässt? Autoimport läuft seit unserem Update auf 3.x nicht mehr
richtig, heisst, wir müssen jetzt (manchmal mehrmals) täglich den Import
händisch erledigen -> Hauptkatalog, Kundenkatalog und 9 Subkataloge....... :/
Grüße, jg
-
Hallo jg,
mal eine "dumme" Frage von mir ;)
hast Du die Batch-Datei angepasst?
C:\Programme\IBO-Internet-Software\ShopPilot-Enterprise2\bin\spilot.exe /AutoDownload /....
auf
C:\Programme\IBO-Internet-Software\ShopPilot-Enterprise3\bin\spilot.exe /AutoDownload /....
-
Hallo dobra,
ja, ist bei uns immer dasselbe Verzeichnis (ich deinstalliere vorher immer).
Der Autoimport läuft ja soweit auch, nur werden die Sonderzeichen
in falsche Sonderzeichen umgewandelt.
Das klappt beim händischen Import der Kataloge problemlos
(mit denselben Access-Abfragen!). Und auch vorher mit der
2.8.x Version von SP lief der Autoimport immer zuverlässig.
jg
-
Hallo jg,
Der Autoimport läuft ja soweit auch, nur werden die Sonderzeichen
in falsche Sonderzeichen umgewandelt.
Das klappt beim händischen Import der Kataloge problemlos
(mit denselben Access-Abfragen!). Und auch vorher mit der
2.8.x Version von SP lief der Autoimport immer zuverlässig.
Ich habe versucht dieses Problem nachzustellen indem ich die Artikel und Seiten aus der liveview.mdb
importiert habe. Vorher habe ich einige Sonderzeichen rein gebracht.
Alle Sonderzeichen wurden korrekt übernommen, sowohl händisch als auch per AutoImport.
Technisch gesehen ist es auch so, dass der manuelle Import und der Autoimport den
gleichen Programmcode verwendet und es da kein unterschiedliches Verhalten geben
dürfte.
Ich habe absolut keine Ahnung, wo ich suchen sollte, zumal in diesem Bereich auch nichts
wesentliches in der dreier Version geändert wurde.
Jg können Sie das Verhalten bei einem der Demoshops reproduzieren und mir diesen zukommen lassen,
weil ohne den Fehler zu sehen, werde ich ihn wohl kaum finden können.
Bitte auch nochmal folgendes überprüfen. Wird tatsächlich bei beiden Imports die gleiche Datenquelle benutzt,
denn ODBC Treiber können ggfs. auch den Zeichensatz umwandeln.
Gruß hop
-
Hallo hop,
Ich habe versucht dieses Problem nachzustellen indem ich die Artikel und Seiten aus der liveview.mdb
importiert habe. Vorher habe ich einige Sonderzeichen rein gebracht.
Alle Sonderzeichen wurden korrekt übernommen, sowohl händisch als auch per AutoImport.
Das Problem tritt bei uns nur beim Import von Subkatalogen auf,
in benutzerdefinierten Feldern des Subkats und in den Subkat-Seitentiteln
und Subkat-Seitenbeschreibungen.
Autoimport Hauptkatalog klappt. Der ist bei uns Deutsch und die Sonderzeichen
darin werden auch richtig importiert.
Jg können Sie das Verhalten bei einem der Demoshops reproduzieren und mir diesen zukommen lassen,
weil ohne den Fehler zu sehen, werde ich ihn wohl kaum finden können.
Vielleicht können wir das Probleme per 'DeskShare' zeigen/lösen?
Das macht sich m.M. nach am Livesystem besser.
Bitte auch nochmal folgendes überprüfen. Wird tatsächlich bei beiden Imports die gleiche Datenquelle benutzt,
denn ODBC Treiber können ggfs. auch den Zeichensatz umwandeln.
Beim Autoimport nutzt SP bei uns dieselbe ODBC-Quelle wie auch beim
händischen Import. Das ist doch fest im WC gespeichert, wenn SP geschlossen ist.
Mit ImportProfil-Dateien arbeite ich nicht.
Grüße, jg