Caching Application

[y0dA]

Hi!

Folgendes Problem, ein Kunde hat das Problem dass eine bestehende Applikation sehr sehr langsam ist. Im Detail werden hierbei sehr viele Daten per Webservice kommuniziert welche sehr gross sind etc blah. Jedenfalls kann man in der Middleware nix anpassen und der Kunde wünscht sich dass wir Ein Caching implementieren welche die relevanten Daten aus dem Backend Cached. Hier müssen wir natürlich auch den Cache aktualisieren (mit den Request Daten) etc.
Sprich der User soll nun am Client nicht mehr direkt das Webservice ansteuern sondern unsere Cache Applikation welche dann die relevanten Daten an den Client retourniert sowie den Request ans Backend weiterleitet.
Weiters möchte der Kunde dass die gecachten Daten im Speicher abgelegt werden (10GB-20GB..).Wir
sollen die Request Daten mit staX oder VTD-XML parsen und anschließend in unserem Cache schauen wo dieser Datensatz (hat ne eindeutige ID oder was weiß ich) liegt und selbigen im XML dann anpassen.. Laufen soll diese Caching Application auf einem JBoss.

Hoffe ihr könnt euch eine kleine Vorstellung davon machen wir toll dieses Projekt wird ...

Jemand eine Idee?
Wir haben uns gedacht (ganz jungfräulich):
-) Initial Cache laden machen wir asynchron in der Nacht, hierbei wird das eigentliche Webservice, welches so langsam ist, aufgerufen und der Cache geladen.
-) Dann müssen wir diese Daten im Speicher ablegen --> XSLT --> binary ?
-) Bei relevanten Userrequests müssen wir dann typische INSERT/UPDATE/DELETE Operationen am Cache durchführen --> quasi wieder mit einem XML Parser die Struktur ausm Cache einlesen und die relevanten Stellen suchen und anpassen.

Wie seht ihr das? Bin für jeden Vorschlage bzw. Idee oder Rat offen.

 

[Bernd Hohmann]

Jemand eine Idee?

Ja: den Verkäufer windelweich schlagen der dem Kunden gesagt hat "kein Problem!". Der Knackpunkt ist, dass der Kunde anscheinend keine Möglichkeit hat (Geld und/oder der Entwickler sind weggelaufen) seine App anzupassen. Sowas ist nur mit spitzen Fingern anzufassen.

Im Prinzip muss man "nur" die Seite analysieren, schauen was man statisch für eine gewisse Zeit lokal vorhalten kann und das dann lokal ausliefern (so hab ich das auf meinen Spamtraps wie Geschichtsverein Windecken 2000 gemacht, ggf. paar mal reload drücken).

Sofern der HTML-Code parsebar ist, ist das auch mit etwas Aufwand und anflicken machbar.+

Aber wirklich gut wird das nie laufen.

Bernd

 

[FArt]

Mein Tipp:
1. Gibt es eine genaue Analyse was genau "sehr sehr" langsam ist? Denn nur dort lohnt es sich anzusetzen.
2. Was ist das Backend und wie wird darauf zugegriffen (Anzahl der Abfragen, Datenmenge). Wo liegt da der Hund begraben? Bandbreite zum Backend? Speicherung der "großen" Daten z.B. als BLOB?
3. "Der Kunde wünscht einen Cache, und zwar im Speicher". Das sollte ein guter Berater und Systemanalytiker dem Kunden "austreiben". Der Kunde hat ein Produkt und hat Performanceprobleme gemessen oder anderweitig ermittelt. Er sollte seine Wünsche in Anforderungen packen können, also z.B. 500 Anfragen pro Minute, Anfragen im Mittel in x Sekunden, maximal y Sekunden usw. Dazu noch die Randparamter wie z.B. dass an der Middleware nichts angepasst werden sollte (warum eigentlich, wenn dort mit verhältnismäßig kleinen Handgriffen u.U. eine komplizierte Krücke vermieden werden kann?)

Denkbar wäre m.E. (wenn wirklich alles so gemacht werden soll): die Daten nicht im Speicher halten, sondern in einer DB, evtl. auf einer SSD. Die Kommunikation zwischen "schneller" DB und Backend kann man evtl. über Replikationsmechanismen realisieren (evtl. DB Trigger oder andere). Ein Caching mit EHCache (BigMemory) könnte auch ein Ansatz sein.Dann würde ich aber nicht mit XML hantieren.

Das wichtigste aber ist: die Probleme wurden eindeutig identifiziert, es werden genau diese Probleme adressiert (nicht mehr und nicht weniger) und es gibt klare Anforderungen.

 

[Marcinek]

Generell ist ein Kunde, der mit seinem Dienstleiseter nicht zufrieden ist, zu dir gekommen und möchte ein Problem gelöst haben. Dagegen ist erstmal nichts einzuwenden.

Dann müssen wir diese Daten im Speicher ablegen --> XSLT --> binary ?

Woher kommt dieses Wissen über XSLT?? Mit XSLT kannst du eine XML in eine (normalerweise) andere XML transformieren. Da kann man nix in binary oder bytearray und sonstwas machen.

Bei relevanten Userrequests müssen wir dann typische INSERT/UPDATE/DELETE

Wenn man schon ein JBOSS installieren kann wieso dann keine relationale DB? Diese kann diese Operationen viel effizienter als eine XML Datei.

Ich habe das mal ausprobiert mit rel. kleinen XML Dateien, die mittels WPF (.NET) dann in der GUI visualisiert worden sind. Da hat ein Update der XML Datei bis zu 2 Sekunden gedauert.

==> Also embeddet DB nehmen oder direkt eine richtige DB (DB2, Informix oder sowas installieren)

Die genauen Skalierungen der Software kann man hier natürlich nicht diskutieren, weil wir gar keine Werte haben.

10-20 GB hört sich erstmal nicht viel an.

---

Jenachdem, welche Daten über den Webservice aufgerufen werden, kann man garnicht den gesamten Webservice herunterladen.

Ggf. würde ein inkrementerller Cache ausreichen.

Im Prinzip muss man "nur" die Seite analysieren, schauen was man statisch für eine gewisse Zeit lokal vorhalten kann und das dann lokal ausliefern (so hab ich das auf meinen Spamtraps wie Geschichtsverein Windecken 2000 gemacht, ggf. paar mal reload drücken).

Sofern der HTML-Code parsebar ist, ist das auch mit etwas Aufwand und anflicken machbar.+

Hier soll ein wohlgefortmer Webservice angesprochen werden und keine Website.

 

[Bernd Hohmann]

Hier soll ein wohlgefortmer Webservice angesprochen werden und keine Website.

Jetzt wo Du es sagst...

Bernd

 

[maki]

.. und der Kunde wünscht sich dass wir Ein Caching implementieren..

Das ist IME immer ein Problem, nennt sich Kompentenzüberschreitung.
Kein guter Start für ein Projekt...

Ich sehe das mittlerweile so:
Wenn der Kunde so genau weiss welche detailierte technische Lösung er will, soll er das doch gefälligst selber machen.

Tatsache ist doch, dass der Kunde wohl weniger Ahnung hat als die externen die er zahlt, also soll er die doch ihren Job machen lassen.

 

[y0dA]

Aktuell gibt es beim Kunden ein Backend CRM System und jener sendet Daten an einen anderen Server welcher dann die Daten für den Client (Mobile --> Smartphones, Tablets) aufbereitet und übermittelt.
So die ungefähre Struktur.
Wir sollen uns nun zwischen dem CRM System und dem Server reinhängen und mal testen ob wir mit dem Caching irgendwas beschleunigen können. Natürlich hat der Kunde auch Leute die sich auskennen, deshalb wissen die auch was sie sich ungefähr wünschen/vorstellen. Zum Kunden brauchen wir ja nichts sagen, Sache ist, ich komme eh nicht drumherum hier mal ein PoC zu erstellen.

Also wir bekommen Daten über ein Webservice, selbige Daten sollen wir dann 'in memory' ablegen weil eine RDBMS langsamer wäre und wir hier ja versuchen die Zeiten zu verbessern - Fakt ist, wir werden hier keine "richtige" Datenbank benutzen können. In weiterer Folge sollen wir dann selbige Daten, je nach Request, anpassen oder an den Client übermitteln.

Technologievorschläge meinerseits:
-) XML Parser: VTD-XML (ok ist ein Kundenvorschlag; kenne ich nicht; oder halt staX was mein Vorschlag wäre).
-) Caching: Hierbei habe ich eher an eine embedded DB als Key/Value Store gedacht, sowas wie Oracle Berkeley (hier habe ich aber noch keinerlei Erfahrung).

Bezüglich dem XSLT Zeug, diese Thematik kam nicht von mir sondern habe ich 1:1 von einem neuen Kollegen übernommen, selbiges habe ich natürlich schon evaluiert und nun isses mir klar dass das nicht geht (XSLT habe ich bisher nur für XML Transformation bei Webservices benutzt) - trotzdem hier liegen sicher nicht meine Kompetenzen..

Nochmal betreffend warum keine DB weil selbige alles besser kann als eine bzw. mehrere XML Dateien: Unser Cache soll im eigentlichen Sinne nur XMLs empfangen und XMLs versenden sowie XMLs anpassen. Schon klar dass ich hier das XML nicht in eine Objektstruktur mappe und dann wieder zurück weil zu langsam. Weiters ist eine relationale Datenbank einfach langsamer als bspw. Oracle Berkeley weil weniger Overhead (keine Erfahrungswerte meinerseits! Weiß ich nur von google ;D).

Klar wird von uns jetzt auch noch evaluiert wo genau die Probleme sind jedoch können wir weder im CRM System noch am Server irgendwas adaptieren.. Ich soll hier aktuell eigentlich nur mal prüfen was für so eine Cachinglösung in Frage käme bezüglich Technologien.

Hat jemand Erfahrung mit XML-Databases oder Key Value/Tupel Stores? Was ist hierbei am Besten geeignet? Berkeley DB XML steht ja unter Sleepycat license und kostet somit, in meinem Fall, wohl was..

 

[DerFeivel]

Eine rdbms ist zu langsam?

Was sind hier genau die Richtwerte?

Anstatt nen "Standardaufbau" mit nem rdbms (dessen Zugriffszeiten meiner Erfahrung nach bei ähnlichen Anwendungen wie du sie hier planst im mittleren 3-stelligen Millisekundenbereich liegen)
umzusetzen baut ihr hier ne eigene Lösung (= ich würds jetzt unter den Anforderungen des Kunden als Brücke bezeichnen) um eine andere Brücke schneller zu machen.


@XML DB

Hier ist relativ gut beschrieben, wann eine xml-db sich anbietet:

Why would people use pure XML databases over plain RDBMs? - Stack Overflow

Die meisten rdbms bieten auch Funktionen zur Verarbeitung von XML.


Aus deiner Beschreibung ist mir immernoch nicht ganz klar, wie der Kunde beim Aufruf an die aktuellen Daten kommt (er bekommt den Cache und das Request ändert ja dann erst)

 

[y0dA]

Aus deiner Beschreibung ist mir immernoch nicht ganz klar, wie der Kunde beim Aufruf an die aktuellen Daten kommt (er bekommt den Cache und das Request ändert ja dann erst)

Es geht darum dass wir mit unserem Caching das Backend "entlasten" sollen. Sprich wir halten in unserem Cache, welcher zu gewissen Zeiten (einmal in der Nacht oder was weiß ich) befüllt wird und wir dann alles Clientrequests retounieren, sprich wir liefern dann dem Client das Ergebnis und nicht das Backend. Sprich unser Cache besitzt alle benötigten Daten und es werden INSERT/UPDATE/DELETES sowie SELECTS auf dem Cache durchgeführt gleichzeitig werden die Requests auch ans Backend übermittelt, selbiger braucht aber zum verarbeiten der Daten sehr sehr lange (40min).

 

[KSG9|sebastian]

Ich werd das Gefühl nicht los als das hier ne Mega-Krücke gebaut wird. Vom Kunden kommen irgendwelche Buzzwords, die Externen nehmen das dann als gegeben hin und frickeln irgendwas zusammen.
Wie siehts denn mit Änderungen aus, wie bekommt der Cache das mit? Die Verarbeitung im Backend läuft asynchron?
Warum mit XML rumfrickeln? Ihr müsst Requests bedienen können. Die Informationen die ihr dafür benötigt müsst ihr haben, also irgendwie auf einen Cacheeintrag mappen können. Das Ergebnis wiederum (Wert für den Eintrag) ist dem Cache doch völlig egal.
Wenn ihr im Cache noch fleißig transformieren müsst bezweifel ich, dass ihr wirklich schneller werdet.
Warum ein RDBMS zu langsam ist frag ich mich auch. Lass mich mal raten: Der Kunde hat's gesagt? Derselbe der mit XSLT-Transformation angekommen ist?
Mehrere GB InMemory zu halten ist auch nicht so ganz einfach und schnell...

 

[y0dA]

Die Client Requests fordern aber XML Daten an.. Sowie Bekommt man von den Clients auch XML Daten..

Wir werden auch die XML Daten nicht in Java Objekte transformieren sondern so flach wie möglich damit arbeiten müssen..

Unsere Cache Applikation soll dazu da sein um den Client "schnell" mit Daten zu versorgen während das Backend (von dem wir nur 1 Mal "alle" Daten brauchen) langsam vor sich hin werkelt - selbiges soll dann keinen Einfluss mehr nehmen weil wir davor eh unseren Cache haben welcher die Daten für den Client besitzt und retouniert. Abgesehen davon tut das hier eigentlich nichts zur Sache, mir ist schon klar dass wir hier nichts tolles machen - aber es ist nicht meine Entscheidung..

Mir gehts darum wie ich diese XML Daten im Cache halten kann (key value store, ehcache,..) sowie wie ich am besten in den Daten Suche sowie Teile der XML Daten ersetze..

 

[Bernd Hohmann]

[...] sprich wir liefern dann dem Client das Ergebnis und nicht das Backend. Sprich unser Cache besitzt alle benötigten Daten und es werden INSERT/UPDATE/DELETES sowie SELECTS auf dem Cache durchgeführt gleichzeitig werden die Requests auch ans Backend übermittelt, selbiger braucht aber zum verarbeiten der Daten sehr sehr lange (40min).

Dh ihr müsst auch die Logik des Backends nachbauen. Da alles im Speicher gehalten wird, sind Programmabbrüche recht unangenehm.

Teufel - was macht das Backend da? Ist das etwa diese Applikation?

Bernd

 

[DerFeivel]

Die Client Requests fordern aber XML Daten an.. Sowie Bekommt man von den Clients auch XML Daten..

WTF?

Die Clients sind Smartphones und ihr kommuniziert da über XML?

Wir werden auch die XML Daten nicht in Java Objekte transformieren sondern so flach wie möglich damit arbeiten müssen..
Unsere Cache Applikation soll dazu da sein um den Client "schnell" mit Daten zu versorgen während das Backend (von dem wir nur 1 Mal "alle" Daten brauchen) langsam vor sich hin werkelt - selbiges soll dann keinen Einfluss mehr nehmen weil wir davor eh unseren Cache haben welcher die Daten für den Client besitzt und retouniert. Abgesehen davon tut das hier eigentlich nichts zur Sache, mir ist schon klar dass wir hier nichts tolles machen - aber es ist nicht meine Entscheidung..

Mir gehts darum wie ich diese XML Daten im Cache halten kann (key value store, ehcache,..) sowie wie ich am besten in den Daten Suche sowie Teile der XML Daten ersetze.

Ihr könnt die XML-Daten auch einfach as-is in einer Cache-DB halten und gebt die einfach nur weiter....
Die meisten gängigen DB-Systeme bieten mittlerweile XML-Procressing-Funktionen an (MySql 5.1 und Oracle auf jeden fall), falls ihr auf den Daten arbeiten müsst.


Ums mal zusammenzufassen:

Euer Auftraggeber möchte eine vor allem schnelle & schlanke Lösung möchte aber das Ganze mit einem bunten Blumenstrauß an Technologien?

Nun ja....arme Sau :bahnhof:

Ein RDBMS mit einigen grundlegenden XML-Basis-Technlogien reicht hier m.E. völlig aus.

 

[y0dA]

Hmpf..
1. Wir haben die bestehende Applikation nicht gebaut
2. Das CRM System schickt diese XML Daten an einen Server welcher halt mit XML Daten arbeitet und diese dann für den Client, wie auch immer, aufbereitet. Sprich wir schicken nicht direkt an den Client (habe ich falsch kommuniziert) sondern hängen und nur zwischen die beiden bestehenden Systeme (CRM, Antenna Server).
3. Es ist nicht meine Entscheidung dass wir KEINE RDBMS verwenden sollen.
4. Was spricht gegen einen XML Parser sowie bspw. Berkeley DB als "Cache" - denke nicht dass das zuviele Technologien sind bzw. wenn wir Berkeley XML nehmen würden dann wäre auch der XML Parser obsolet.

Hier gehts nicht darum ob das bestehende, was wir nicht ändern können, schlecht ist etc da wir keinen Einfluss drauf nehmen können, ich will hier eigentlich nur über zu verwendende Technologien diskutieren stattdessen muss ich aber ständig die bestehende - beschissene - IT Landschaft "verteidigen". Ich würde es auch lieber anders bzw. besser machen wollen und halt Ursachenforschung betreiben wollen und das Ding dort verbessern wo es Sinn macht, aber das ist nicht meine Entscheidung..

Der Text sollte eigentlich nicht so pampig klingen nur komme ich hier halt einfach nicht wirklich weiter. Nochmal, vergessen wir einfach wie das alles beim Kunden aussieht etc es geht mir hier nur um Technologien die hierbei Sinn machen würden.

Schon mal jemand mit key value stores gearbeitet, welche sind zu empfehlen? Oder lieber gleich sowas wie eine XML Datenbank (embedded) nehmen wo bspw. gleich XPath oder XQuery enthalten ist? Oder doch lieber selbst die Daten verwalten und mit ehcache und dergleichen arbeiten - Erfahrungswerte?

 

[KSG9|sebastian]

Hi,
das ist keine Kritik an dir, das Problem ist nur, das bei den Anforderungen/Vorgaben/Wünschen selten was gescheites rauskommt.
Ich wollt einen Cache quasi als zweites Middle-Tier mißbrauchen. Dafür ist ein Cache halt nicht gedacht und bevor ihr annähernd damit fertig seit werdet ihr merken das ihr einen großen Teil der Geschäftslogik des eigentlichen Middletier/Backens dupliziert habt unddamit eine Insellösung gebaut habt welche dieselben Probleme hat wie euer eigentliches Backend.
Aver trotzdem ein Vorschlag:
Ich hab gute Erfahrungen mit Hazelcast, Coherence und EHCache gemacht. Evtl könnt ihr die Read/Write-Theough-Funktion für eure zwecke nutzen. Von XML-Parsen würd ich komplett absehen, sonst werdet ihr wohl recht schnell wieder Performanceprobleme bekommen. Falls ihr parsen müsst: Excessive (!!) Tests fahren!!!!!!!

 

[y0dA]

Hi,
das ist keine Kritik an dir, das Problem ist nur, das bei den Anforderungen/Vorgaben/Wünschen selten was gescheites rauskommt.
Ich wollt einen Cache quasi als zweites Middle-Tier mißbrauchen. Dafür ist ein Cache halt nicht gedacht und bevor ihr annähernd damit fertig seit werdet ihr merken das ihr einen großen Teil der Geschäftslogik des eigentlichen Middletier/Backens dupliziert habt unddamit eine Insellösung gebaut habt welche dieselben Probleme hat wie euer eigentliches Backend.
Aver trotzdem ein Vorschlag:
Ich hab gute Erfahrungen mit Hazelcast, Coherence und EHCache gemacht. Evtl könnt ihr die Read/Write-Theough-Funktion für eure zwecke nutzen. Von XML-Parsen würd ich komplett absehen, sonst werdet ihr wohl recht schnell wieder Performanceprobleme bekommen. Falls ihr parsen müsst: Excessive (!!) Tests fahren!!!!!!!

Danke dir!
Naja wie sollte ich ohne XML zu parsen an gewisse Daten kommen welche ich ersetzen oder retounieren soll? Also sollte wir wirklich von einem Key Value Store oder einer XML DB absehen weil ebenfalls zu langsam?

 

[FArt]

Ich verstehe nicht ganz, was daran so problematisch ist. Das Problem ist (unter der Voraussetzung, dass keine großartige Logik über die Nutzdaten benötigt wird) relativ einfach.

Wie gesagt: holt euch vom Kunden echte Anforderungen, keine technischen Lösungsversuche. Ein Kunde wird euren Einsatz mit der Zeit zu schätzen wissen, denn er muss ja mit dem Ergebnis und den Kosten leben. Das kann ich dir aus eigener Erfahrung bestätigen: die Kunden sind erst etwas geschockt, aber spätestens nach einem ersten PoC überzeugt. Sie werden außerdem dazu gezwungen, ihre Wünsche in eindeutige Anforderungen zu gießen. Nur dann ist ein Ergebnis für beide Seiten nachher bewertbar.

Im Prinzip ist m.E. immer noch die beste Lösung (mit den Randparametern wie ich sie verstanden habe) eine schnelle, lokale DB am System und asynchrone Datenbankreplikation ins Backend.
Zu Bedenken ist bei eurer Lösung grundsätzlich die Integrität zwischen "Cache" und Backend, aber sonst ist man sowohl mit den Schnittstellen flexibel als auch was Performance und Antwortzeiten angeht.

Evtl. könne es sinnvoll sein, die Operationen über eine REST Schnittstelle zu kapseln, aber um das beurteilen zu können habe ich zu wenig Einblick in den konkreten Fall.

 

[freez]

Also nach den Anforderungen (kein System verändern, XML fließt zwischen den Systemen, Ein weiteres System soll entstehen, welches sich genau dazwischen hängt und die XML Daten verändert/weiterleitet) bleibt dir ja gar nichts anderes übrig, als XML zu parsen und ich vermute ganz stark, dass sich bei den Datenmengen die Performanceprobleme einfach nur auf euer neue entwickeltes System verlagert. Ihr würdet auf alle Fälle ein besseres System bauen, wenn Ihr eine Seite (z.B. Client oder die Middleware) austauschen / verändern könntet.

Macht doch einfach mal einen Test ... nehmt das riesige XML und versucht mal ein paar Standardaktionen drauf laufen zu lassen. Einfach mal quick and dirty zusammengeschustert. Damit könnt Ihr zum Kunden gehen und der kann dann auch eine Entscheidung treffen, wenn er selbst sieht, wie schlecht doch seine Idee ist. Und ihr seht vor allem, welche Intelligenz ihr aus der Middleware duplizieren müsst.

 

[ARadauer]

Ich hab mir jetzt nicht alles durchgelesen...
aber im Grunde ist es nciht so abwägig gewisse daten zu cache die aus einem anderen system über irgend eine langsame schnittstelle zu laden.

zb in einem verrechnungs system alle kunden aus SAP... natürlich wirds dann kritisch, wenn im verechnunsystem dann auch kunden geändert werden können...

 

[FArt]

aber im Grunde ist es nciht so abwägig gewisse daten zu cache die aus einem anderen system über irgend eine langsame schnittstelle zu laden.

Natürlich nicht. Deswegen gibt es ja auch Lösungsansätze, die man als Quasi-Standard erst mal in Betracht ziehen sollte.

zb in einem verrechnungs system alle kunden aus SAP... natürlich wirds dann kritisch, wenn im verechnunsystem dann auch kunden geändert werden können...

Ja, die Datenkonsistenz muss natürlich berücksichtigt werden. Aber auch hier kann man z.B. Performance herausholen, weil nicht alle Daten zwingend mit einer (verteilten) Transaktion konsistent gehalten werden müssen (ACID). Oft sind das nur relativ wenige Daten. Andere können nach dem BASE Prinzip verarbeitet werden, und das bringt natürlich einiges an Optimierungspotential.

 

[DerFeivel]

Sag mal,

vielleicht habe ich es überlesen:


Möchte euer Auftraggeber im Anschluß ebenfalls die Sourcen eurer Applikation haben?