Keine gzip-Komprimierung bei PlentyMarkets?

[samenhaus-admin]

Hi zusammen,
ich bin mal wieder dabei, unsere Synesty-Kosten zu optimieren.

Ich war dann recht überrascht davon, dass unser teuerster Flow einer ist, der nur einen PlentyGetVariations mit allen Parametern abfeuert, und in einen Datastore schreibt.

Der macht 700MB Traffic pro Durchlauf, und läuft mehrmals täglich:

Da sind alle „zusätzlichen Felder“ aktiv, außer Artikelbilder. Abruf ergibt ca 43.000 Varianten.

Was mich jetzt stutzig gemacht hat: der verursacht so viel Traffic, aber wenn ich den Datastore exportiere in den ich alles schreibe, hat der nur 320 MB.

CSV, also plaintext, unkomprimiert. Wenn ich das wiederum gzippe, kommen ich auf 31 MB. Bisschen Overhead ist natürlich immer, aber so krass kann ich mir kaum vorstellen.

Umgekehrt gibts aber auch nur wenige Spalten aus dem Call, die ich zwar abrufe, aber nicht speichere:

klick

IsMain
CustomsTariffNumber
PropertiesInherited
TagsInherited
ParentVariationID
ItemPropertiesJSON
ItemPropertiesWithGroupsJSON
AvailabilityUpdatedAt
AdditionalSkuUpdatedAt
BarcodeUpdatedAt
BundleComponentUpdatedAt
CategoryUpdatedAt
ClientUpdatedAt
DefaultCategoryUpdatedAt
ImageUpdatedAt
MarketUpdatedAt
MarketIdentNumberUpdatedAt
SalesPriceUpdatedAt
SkuUpdatedAt
SupplierUpdatedAt
PropertyUpdatedAt
WarehouseUpdatedAt
TagUpdatedAt
CommentUpdatedAt
VariationAccountMarketSkus
VariationPropertiesJSON

Die Spalten für ItemProperties und VariationProperties sind sicher recht lang (und werden dann verworfen), aber auch die sollten ja mit gzip egtl gut komprimieren. Kurzum: ich würde egtl viel weniger Traffic erwarten für diesen Abruf.

Könnt ihr das mal prüfen, ob hier unkomprimiert übertragen wird?
Die API von Plenty kann auf jeden Fall content-encoding gzip, das habe ich grade mal mit Postmann geprüft. Aber wirds auch genutzt?

Ich hab grade mal einen Durchlauf mit Debug-Log durchgeführt, runID ist 0197c275-cdf1-7ef6-9b8f-78a21a0a7c85, Flow heißt SH_getItemData_REST. Rein schauen kann ich aber selbst nicht mehr…

Danke im Voraus, Daniel

[synesty-Torsten]

Hallo Daniel,

@samenhaus-admin

Kurzum: ich würde egtl viel weniger Traffic erwarten für diesen Abruf.

Wir entfernen wirklich relativ viel aus den response Daten raus. Ich vermute, das ein Großteil bei den Übersetzungen (der Artikeltexte, Kategorien, Merkmale, Eigenschaften, … ) liegt. Hier kommen in der Response immer alle Übersetzungen mit. Wir reduzieren das dann auf die ausgewählte Sprache im Step. D.h. wenn man 10 Sprachen hinterlegt hat, werden 9 aus der Response verworfen.

Der „lang“ Parameter der PIM Route hat leider keinen Einfluss (mehr?) auf die vorhandenen Übersetzungen der Response. Der Parameter bezieht sich scheinbar nur noch auf andere, sprachabhängige Filter.

REST API

@samenhaus-admin

Könnt ihr das mal prüfen, ob hier unkomprimiert übertragen wird?
Die API von Plenty kann auf jeden Fall content-encoding gzip, das habe ich grade mal mit Postmann geprüft. Aber wirds auch genutzt?

Ja, wird von uns auch genutzt.

@samenhaus-admin

Ich hab grade mal einen Durchlauf mit Debug-Log durchgeführt, runID ist 0197c275-cdf1-7ef6-9b8f-78a21a0a7c85, Flow heißt SH_getItemData_REST. Rein schauen kann ich aber selbst nicht mehr…

Ich leider auch nicht Der debug log vom Run 0197c275-cdf1-7ef6-9b8f-78a21a0a7c85 ist so groß, das ich beim Download Versuch immer in timeout laufe. Kannst du mir eventuell nochmal einen erstellen, der nur ein paar Varianten (limit ca. 100 sollten reichen) enthält. Dann kann ich nochmal genauer schauen, was bei euch den overhead erzeugt.

VG Torsten

[samenhaus-admin]

Hi Torsten,

@synesty-Torsten

Ich vermute, das ein Großteil bei den Übersetzungen (der Artikeltexte, Kategorien, Merkmale, Eigenschaften, … ) liegt. Hier kommen in der Response immer alle Übersetzungen mit. Wir reduzieren das dann auf die ausgewählte Sprache im Step. D.h. wenn man 10 Sprachen hinterlegt hat, werden 9 aus der Response verworfen.

Sprachen kann ich tatsächlich ausschließen, wir haben nur eine konfiguriert.

@synesty-Torsten

Der „lang“ Parameter der PIM Route hat leider keinen Einfluss (mehr?) auf die vorhandenen Übersetzungen der Response

Mensch, Plenty

@synesty-Torsten

Ja, wird von uns auch genutzt.

Alles andere hätte mich auch gewundert

@synesty-Torsten

Ich leider auch nicht Der debug log vom Run 0197c275-cdf1-7ef6-9b8f-78a21a0a7c85 ist so groß, das ich beim Download Versuch immer in timeout laufe. Kannst du mir eventuell nochmal einen erstellen, der nur ein paar Varianten (limit ca. 100 sollten reichen) enthält.

Hehe. Schau mal Run 0197c688-3424-7e0f-9842-f23e5d760585, hab ich grade abgefeuert, mit nur 100 Varianten. Ist deutlich kleiner

Grüße

[synesty-Torsten]

Hallo Daniel,

@samenhaus-admin

Hehe. Schau mal Run 0197c688-3424-7e0f-9842-f23e5d760585, hab ich grade abgefeuert, mit nur 100 Varianten. Ist deutlich kleiner

Danke dir, das hat super funktioniert. Ich habe mal grob drüber geschaut.

• Das wichtigste zuerst: gzip wird verwendet
  

  

• Beim Abruf der Varianten wird folgender Call gemacht:
  GET /rest/pim/variations/scroll?with=base%2Ccategories%2Ccategories.category%2Ccategories.categoryBranch%2CdefaultCategories%2Cimages%2Cimages.image%2Cclients%2Cskus%2Ctimestamps%2Cwarehouses%2Cbase.stock%2Cbarcodes%2CmarketIdentNumbers%2Cbase.texts%2Cunit%2Cmarkets%2CattributeValues%2CattributeValues.attribute%2CattributeValues.attributeValue%2Cbase.item%2Csupplier%2Cbase.shippingProfiles%2CsalesPrices%2Cbase.characteristics%2Cproperties%2Ctags%2Ctags.tag%2Cbase.crossSelling&lang=de&itemsPerPage=100&cursor=null

Diese Response ist schon > 5 MB (json, ohne gzip). Beim scrollen über die response ist mir aufgefallen, dass ein großer Teil aus Kategoriedaten (Texten) besteht. Es kommen pro Variante immer die kompletten Kategoriedaten aller verknüpften Kategorien mit. Das erzeugt eine Menge overhead, da wir im Step Output nur die Namen der Kategorien ausgeben. Eventuell kann man da irgendwie ansetzen, um Traffic einzusparen. Eventuell kannst du

Ich schau mir auch nochmal an ob, wir im Step irgendwie einen reduzierteren Kategorie Abruf (z.B. nur die verknüpften IDs) hinbekommen. Dann könnte man die Kategorienamen ggf. auch per MappingSet, KeyValueSpreasheet erzeugen.

In unserem Testsystem (wir haben nicht so toll gepflegte Kategorietexte) braucht der Step ohne „Varianten Kategorien“ nur noch 1/4 des Traffics.

Du kannst den Call auch gern nochmal im Postman ausprobieren. Falls dir noch etwas auffällt kannst du mir gern Bescheid geben.

VG Torsten

[samenhaus-admin]

Hi Torsten,

@synesty-Torsten

Diese Response ist schon > 5 MB

Das ist verrückt

@synesty-Torsten

Eventuell kann man da irgendwie ansetzen, um Traffic einzusparen. Eventuell kannst du

Hier ist dir der Text abgebrochen

@synesty-Torsten

Ich schau mir auch nochmal an ob, wir im Step irgendwie einen reduzierteren Kategorie Abruf (z.B. nur die verknüpften IDs) hinbekommen. Dann könnte man die Kategorienamen ggf. auch per MappingSet, KeyValueSpreasheet erzeugen.

Das würde uns auch vollkommen genügen, ich brauche wirklich nur die verknüpften IDs. Noch nicht mal die Namen dazu.

@synesty-Torsten

der Step ohne „Varianten Kategorien“

Das wäre der nächste Punkt: ich bin mir grade gar nicht ganz sicher, ob ich die Kategorien denn überhaupt brauche

Das ist halt ein „Cache Flow“, ich rufe da „alles was die API hergibt“ ab, um dann auf dutzenden anderen Flows darauf per Querverweis zuzugreifen, statt die Daten dort jedes mal wieder frisch abzurufen. Die Idee war, darüber Kosten (und Laufzeit) zu sparen, aber du siehst ja unsere Rechnungen: ich bin nicht sicher, ob das bei den Kosten für diesen Flow noch gegeben ist

Wie könnte ich denn am besten raus finden, ob irgendwo überhaupt ein Querverweis auf die Kategorie-Spalte im Datastore durchgeführt wird?

Da führt ihr nirgendwo einen Graph drüber, oder?

Dann… Volltextsuche. Der Querverweis enthält in jedem Fall irgendwo den String der Spalte (AllCategoryIDs), entweder direkt in seinem Feld, oder in einer Variable. Das sollte klappen.

Den Fall dass ich den Wert einer anderen Spalte dort referenziere, und die den String enthält würde mir als Fallstrick noch einfallen, aber sowas hab ich eher nicht gebaut. Hoffe ich.

Kann ich die Suche noch irgendwie einschränken nur auf die Felder von Querverweisen? Oder könntet ihr das vllt einmalig irgendwie aus eurer Datenbank (oder so) ermitteln für uns?

Wenn nicht, muss ich mich halt durchwühlen

Wenn ich die Kategorien eh nicht nutze, wär das auf jeden Fall noch die beste Lösung fürs Problem: einfach raus damit. Bin vorsichtig optimistisch

Beste Grüße Daniel

[synesty-Torsten]

Hallo Daniel,

@samenhaus-admin

@synesty-Torsten

Eventuell kann man da irgendwie ansetzen, um Traffic einzusparen. Eventuell kannst du

Hier ist dir der Text abgebrochen

Upps, wollte schreiben das du dir die Kategorie IDs / Name eventuell über irgendeinen Plenty Export holen kannst. Bin da allerdings nicht so tief drin, was es da aktuell an Möglichkeiten bei Plenty gibt.

@samenhaus-admin

@synesty-Torsten

Ich schau mir auch nochmal an ob, wir im Step irgendwie einen reduzierteren Kategorie Abruf (z.B. nur die verknüpften IDs) hinbekommen. Dann könnte man die Kategorienamen ggf. auch per MappingSet, KeyValueSpreasheet erzeugen.

Das würde uns auch vollkommen genügen, ich brauche wirklich nur die verknüpften IDs. Noch nicht mal die Namen dazu.

Das habe ich mir gestern schon angeschaut. Wir bauen eine Möglichkeit in den GetVariations Step ein. Kommt voraussichtlich nächste Woche.

@samenhaus-admin

Dann… Volltextsuche. Der Querverweis enthält in jedem Fall irgendwo den String der Spalte (AllCategoryIDs), entweder direkt in seinem Feld, oder in einer Variable. Das sollte klappen.

Den Fall dass ich den Wert einer anderen Spalte dort referenziere, und die den String enthält würde mir als Fallstrick noch einfallen, aber sowas hab ich eher nicht gebaut. Hoffe ich.

Die Flow Volltextsuche mit „AllCategoryIDs“ sollte dir alle Steps anzeigen, bei denen diese Spalte verwendet wird (auch im Mapper bei Quelle, Wert Feld oder in den Spaltenfunktionen wie Querverweis).
Es gibt ein paar Fallstricke (z.B. bei passthrough Modus im Mapper oder wenn Freemarker verwendet wird), die du damit wahrscheinlich nicht findest.

@samenhaus-admin

Kann ich die Suche noch irgendwie einschränken nur auf die Felder von Querverweisen? Oder könntet ihr das vllt einmalig irgendwie aus eurer Datenbank (oder so) ermitteln für uns?

Wenn du in der Flow Volltextsuche "field":"AllCategoryIDs" als Suchbegriff verwendest, sollten nur noch die Querverweise mit dem Rückgabefeld „AllCategoryIDs“ im Ergebnis kommen.

Vielleicht hilft dir das weiter.

VG Torsten

[samenhaus-admin]

@synesty-Torsten

Wenn du in der Flow Volltextsuche "field":"AllCategoryIDs" als Suchbegriff verwendest, sollten nur noch die Querverweise mit dem Rückgabefeld „AllCategoryIDs“ im Ergebnis kommen.

Sehr cool, danke, genau das hatte ich gesucht

Leider verwende ich die Kategorien dann doch auch an einigen Stellen, deshalb

@synesty-Torsten

Wir bauen eine Möglichkeit in den GetVariations Step ein. Kommt voraussichtlich nächste Woche.

werde ich darauf warten! Einfach nur Abruf der IDs, ohne hintenrum mit Namen anzureichern, das wäre großartig.

Und um an die Namen zu kommen, könnte ich dann immer noch einen Datastore per PlentyGetCategories befüllen und von da quer verweisen. Da reichen ja dann auch seltenere Updates.

Ich hab auch schon mal geschaut: ohne Abruf der Kategorien macht mein Flow nur noch 250 MB Traffic statt den 720 zuvor. Das ist ne sehr nette Ersparnis. Und doppelt so schnell läuft er dann auch noch

Dann warte ich mal auf das Feature, vielen Dank Torsten!

Grüße

[synesty-Torsten]

Hi Daniel,

die Auswahl für die Kategorie-IDs ist jetzt im GetVariations Step vorhanden.

VG Torsten

[samenhaus-admin]

Sehr cool!

Habs direkt umgebaut: 60% weniger Traffic, 10 Durchläufe jeden Tag. Das wird sich deutlich bemerkbar machen in der Rechnung <3

Vielen Dank Torsten + Team