[ASP.NET] SQL Cache dependency

[Verwijderd]

Ik wil graag caching inbouwen in een nieuwe website, omdat de communicatie met de SQL-server te traag is om aangenaam te werken. Aan de query's ligt het niet, want die functioneren heel snel als ik ze uitvoer. De vertraging zit hem dus echt in de communicatie tussen de SQL en de webserver. Dus caching lijkt mij de ideale oplossing.

Ik volg de tutorial op http://www.asp.net/learn/...utorial61vb.aspx?tabid=63, en daar staat dat je bepaalde commando's moet uitvoeren op de database voor die caching gaat ondersteunen.

Aangezien ik met shared hosting werk, is de kans héél klein dat ik zelf die commando's kan uitvoeren (volgens de site moet je in db_securityadmin zitten).

Mijn idee was dus om de T-SQL die door aspnet_regsql.exe gegenereerd wordt voor caching, om te slaan in een file, en aan de admin van de shared hosting te vragen om het script uit te voeren op de database.

Nu zijn daar wel een paar onduidelijkheden:
1. Volgens http://scottonwriting.net/sowblog/posts/10709.aspx kan ik niet zo maar T-SQL exporteren naar een text-file. Hoe kan ik dit dan wel forceren? De T-SQL die op die site staat kan ik waarschijnlijk niet gebruiken omdat die specifiek voor zijn database zal zijn en niet gaat werken op mijn database.
2. Op dit moment is mijn database nog niet volledig af. Sommige tabellen ontbreken nog. Betekend dat, dat ik nog geen caching kan toevoegen omdat nog niet alle tabellen bestaan? (Ik kan niet voortdurend nieuwe T-SQL's naar de admin sturen elke keer ik een nieuwe tabel aanmaak)
3. Voor het toevoegen van de triggers is er een andere code dan voor het voorbereiden van de database. Moet je voor die triggers ook lid zijn van db_securityadmin? Of kan je dat ook met normale rechten op de database?

Als 3 ook gaat met normale rechten, en 2 ook uitgevoerd kan worden zonder dat alle tabellen bestaan, dan kan ik nu nl. al de database laten klaarmaken, en gewoon de triggers toevoegen van zodra de nieuwe tabellen aangemaakt zijn.

[MrBucket]

Ik wil graag caching inbouwen in een nieuwe website, omdat de communicatie met de SQL-server te traag is om aangenaam te werken. Aan de query's ligt het niet, want die functioneren heel snel als ik ze uitvoer. De vertraging zit hem dus echt in de communicatie tussen de SQL en de webserver.

Als de vertaging in de verbinding naar de database zit, dan zal cachen van gegevens op de database denk ik niet zoveel uithalen, aangezien je dan nog steeds even vaak heen en weer moet fietsen over die verbinding.

Is het probleem niet het aantal roundtrips naar de database? Kun je je queries / stored procedures niet zo schrijven dat je minder roundtrips hoeft te maken (bijv. door alle gegevens die je nodig hebt uit dezelfde tabel in een keer te retourneren)?

--edit
My bad, het cachen zelf gebeurt dus op de webserver, niet op de database. Even goed is cachen een gevaarlijke zaak, omdat je werkt met data die mogelijk niet meer actueel is, wat allerhande vreemde situaties en problemen kan opleveren. Plus dat als je een cache miss hebt, dat je dan alsnog je trage queries zult moeten gebruiken.

[ Voor 18% gewijzigd door MrBucket op 18-06-2007 21:14 ]

[Verwijderd]

MrBucket schreef op maandag 18 juni 2007 @ 20:15:
[...]

Als de vertaging in de verbinding naar de database zit, dan zal cachen van gegevens op de database denk ik niet zoveel uithalen, aangezien je dan nog steeds even vaak heen en weer moet fietsen over die verbinding.

Is het probleem niet het aantal roundtrips naar de database? Kun je je queries / stored procedures niet zo schrijven dat je minder roundtrips hoeft te maken (bijv. door alle gegevens die je nodig hebt uit dezelfde tabel in een keer te retourneren)?

--edit
My bad, het cachen zelf gebeurt dus op de webserver, niet op de database. Even goed is cachen een gevaarlijke zaak, omdat je werkt met data die mogelijk niet meer actueel is, wat allerhande vreemde situaties en problemen kan opleveren. Plus dat als je een cache miss hebt, dat je dan alsnog je trage queries zult moeten gebruiken.

Maar cachen met sql dependency dient toch net om te vermijden dat je niet met data werkt die niet actueel is?
De cache is trouwens enkel bedoelt om tijdelijke performance problemen op te vangen, en op drukke momenten de load op de database te verminderen. Gisterenavond bleek dat de trage performance een probleem was bij de hosting dit weekend. Ze hebben dat maandag aangepakt en de performance ligt nu weer een heel pak hoger. De cache dient dus enkel als "buffer" wanneer er performance problemen zijn met de SQL, of als het heel druk wordt.

[Niemand_Anders]

Als je een langzame verbinding tussen de webserver en database hebt, dan zal de SQL cache weinig helpen. De webserver voert namelijk nog steeds een query uit op de database. Alleen ipv van een resultaat krijgt deze een soort van checksum terug. Als de checksum hetzelfde is, is de content niet gewijzigd en wordt de pagina uit de cache gebruikt en anders wordt alsnog volledig de volledige pagina uitgevoert.

Een structurele oplossing is gewoon achterhalen waarom de verbinding tussen webserver en database zo traag is. Caching is altijd een workaround en nooit een oplossing voor performance problemen.

[Verwijderd]

Niemand_Anders schreef op dinsdag 19 juni 2007 @ 12:59:
Als je een langzame verbinding tussen de webserver en database hebt, dan zal de SQL cache weinig helpen. De webserver voert namelijk nog steeds een query uit op de database. Alleen ipv van een resultaat krijgt deze een soort van checksum terug. Als de checksum hetzelfde is, is de content niet gewijzigd en wordt de pagina uit de cache gebruikt en anders wordt alsnog volledig de volledige pagina uitgevoert.

Een structurele oplossing is gewoon achterhalen waarom de verbinding tussen webserver en database zo traag is. Caching is altijd een workaround en nooit een oplossing voor performance problemen.

Aha, uit wat ik las leek het alsof de polling los staat van het renderen van output.
Ik zag het dus zo:

proces 1: rendert de output naar de client. Als de data in de cache zit, gebruikt hij die data, anders gaat hij naar de database om de data op te halen.
proces 2: pollt continu de database. Als hij merkt dat er data verandert haalt hij die data gewoon uit de cache.

Ik dacht dat die 2 processen dan los van elkaar zouden lopen. Als proces 2 dus heel traag zou functioneren, zou proces 1 nog altijd vlot lopen zolang de data maar in de cache blijft. Pas wanneer de data verandert in de database zou proces 2 die data uit de cache halen, en zou proces 1 eenmalig naar de database moeten gaan voor de data. Leek mij dus perfect mogelijk om als buffer te werken.

Maar dat is dus niet het geval?

[flowerp]

Een andere oplossing is misschien NHibernate gebruiken.

Al je DB benaderingen gaan dan via NHibernate. Deze heeft ook zijn eigen cache. Als echt alle DB benaderingen via NHibernate gaan, dan weet deze ook wanneer data veranderd is en dus wanneer een cache entry stale is.

In dit geval werkt het natuurlijk alleen op deze manier als je 1 web server hebt. Bij meerdere webservers heb je een zogenaamde distributed cache nodig (zoals Oracle Coherence, maar weet niet of deze laatste ook voor .NET te krijgen is).

Daarnaast hoeft ivm caching stale data niet altijd een probleem te zijn. In zekere zin zijn mensen dat ook wel gewend. De pagina die ze in hun browser scherm hebben wordt ook niet real-time via een server-push geupdate. Pas na aan expliciete refresh hebben ze weer de laatste data.

Afhankelijk van jouw situatie kun je misschien enkele plekken aanwijzen waar de data best eventjes mag achterlopen.

Dikwijls kun je bij een cache ook een timeout instellen. B.v. bij een high-traffic site kan een cache life-time van 30 seconden al voor een grote performance verbetering zorgen, als je i.p.v. 100 keer per seconden naar de DB, nog maar 1 keer per 30 seconden dat hoeft te doen.

[gorgi_19]

flowerp schreef op woensdag 20 juni 2007 @ 10:41:
Dikwijls kun je bij een cache ook een timeout instellen. B.v. bij een high-traffic site kan een cache life-time van 30 seconden al voor een grote performance verbetering zorgen, als je i.p.v. 100 keer per seconden naar de DB, nog maar 1 keer per 30 seconden dat hoeft te doen.

Dan kom je al heel snel uit op een OutputCache, al dan niet met een VaryByParam oid met een bepaalde vervaltijd

[whoami]

flowerp schreef op woensdag 20 juni 2007 @ 10:41:
Een andere oplossing is misschien NHibernate gebruiken.

Al je DB benaderingen gaan dan via NHibernate. Deze heeft ook zijn eigen cache. Als echt alle DB benaderingen via NHibernate gaan, dan weet deze ook wanneer data veranderd is en dus wanneer een cache entry stale is.

Ben je dat zeker ? NHibernate gaat niet over asp.net sessies; ik bedoel: de NHibernate ISession van user a kan toch niet weten of user b al eenzelfde object gewijzigd en gesaved heeft.

[flowerp]

whoami schreef op woensdag 20 juni 2007 @ 11:05:
[...]
Ben je dat zeker ? NHibernate gaat niet over asp.net sessies; ik bedoel: de NHibernate ISession van user a kan toch niet weten of user b al eenzelfde object gewijzigd en gesaved heeft.

Voor ASP.NET weet ik dat niet zeker. Sorry, ik had dat even in de vorige post moeten vermelden dat ik vooral ervaring heb met de Java variant van Hibernate. Daar kun je gewoon een cache provider als plugin toevoegen, b.v. Jboss TreeCache of OsCache etc.

Deze caches zijn dan globaal en, afhankelijk van de concrete caching implementatie ook distributed. B.v. Jboss TreeCache doet wel replication, maar is toch nog net geen distributed cache.

ISession's weten inderdaad niets van elkaar (mag ook niet), maar de Objecten (entities) staan ook boven de user. De O/R mapper haalt alleen een Object vanuit de persistence context naar de user toe. Daar kun je er lokaal mee rommelen, maar zodra je deze weer toevoegd aan de persistence context, zal de state voor iedereen gelijk zijn. De volgende die hem ophaalt zal dan ook deze state krijgen. Afhankelijk van de situatie zal Hibernate deze uit de cache halen, of ervoor naar de DB gaan.

Dus, zolang je entity detached is, zal deze achterlopen, maar zodra je hem merged of overnieuw ophaalt krijg je weer te maken met de huidige state.

Dat is feitelijk niet anders dan dat je een gewone query doet, en met die data aan de gang gaat. Terwijl je daarmee bezig bent kan de achterliggende data in de DB ook veranderen.

[Hydra]

Verwijderd schreef op dinsdag 19 juni 2007 @ 09:49:
Maar cachen met sql dependency dient toch net om te vermijden dat je niet met data werkt die niet actueel is?

Caching in de backend wordt vooral gebruikt om de load te verlagen van zware queries die vaak gebruikt worden. Je zegt zelf dat de queries niet het probleem zijn, maar de bangbreedte tussen de applicatie en de database server, dus dan kom je uit op caching aan de applicatie kant.

Je zit kennelijk met een shared hosting oplossing waar een aantal andere sites zo 'zwaar' zijn dat ze jouw sites beinvloeden; dat lijkt me dan vooral een kwestie van je hosting provider eens op z'n vingers tikken en even kijken welke contractuele verplichtingen hij heeft naar jou toe voordat je veel tijd gaan investeren in application-side caching. Dit zal volgens mij niet veel meer zijn dan een band-aid oplossing; dergelijke performance problemen zullen waarschijnlijk ook invloed hebben op het verkeer van je site naar buiten.