A caching technique (idea really)

[abraxas77]

I created a cache system ( vault link ). It spawned from a conversation with Grinning Fool which ended, "the next step would be to write Save/Restore cache fuctions."

I was thinking about that recently ... using the cache to access data from a DB. My thought was to cache the data that needs to be written to the DB, then setup a timer (heartbeat) system that periodically writes X amount of data to the DB and clears the write request from the cache. Likewise, the same could be done for read requests.


I'm still pondering the legistics: would it be worth writting? Is anyone doing this (or similar) now?


I reckon such a system would serve best as an incremental backup system: periodically and continuously writting bits of data over time rather than writting it all at once.

As far as reading DB data ... (I'll first say my SQL knowledge is rather limited atm) ... it seems feasible that a proc could take a large request, return a short answer (so nwscript can continue), then periodically return sets of data as it's recalled from the DB. Obviously, this would require some careful scripting to ensure the data is there when you need it. But it seems feasable.


Thoughts?

{edit: I appoligize if this isn't the proper place to post this ... It seems the best place to get nwnx developer's opinions ... and seemed mostly relevent to the forum topic}
_________________
aka. twp_andrew

:: Lead Script Design :: The World of Paladium II ::

[amphiprion]

Cache system is always difficult to realize and have always many "bug" or "bad use" issue.

I think it's not a good idea for NWN2 developement, you have many chance with a cache to introduce many problem, and very few advantage for the majority of scripters

[Papillon]

Well, the question is what performance gains you expect. If you take a look at the performance measurements in the ODBC2 documentation, you will see that 500 reads took around 20 milliseconds. Now the questions is, under what circumstances would you read this many rows ? Probably only at module startup, and performance is not critical there. If you read fewer rows in normal situations, you will probably spend max. 1 millisecond (that is greatly exaggerated) reading from the database, meaning you could repeat the same operation at least 200-300 times before the server would start lagging...

Or, to put it another way: If your DB processing takes only 1% of a second (10ms) , and the other stuff the server does takes the rest (at 100% load), and you implement a cache that is 50% faster than direct access, you would gain only a 0,5% overall performance increase.

I have used a small caching system in Avlis, GetCachedString and so on, just for the convenience functions, not for the whole SQL data. I think for some frequently read data (like in heartbeats), this can make sense. On the other hand, I have heard that the engine gets slow if you store too many values on a single object, so as always: It depends.

In general, I think there are two alternative ways to work with in-memory data:

1) memory tables (I know SQLite supports this, I guess MySQL should, too)
2) a plugin that connects to a memory (not disk) based hash that can be reached via IPC or TCP/IP sockets by multiple modules.

These would probably be used for simple data storage and retrieval, not for complex queries. These are just thoughts from the top of my head, that I want to explore (much) later on.
_________________
Papillon

[abraxas77]

Thanks for the responses.

I think I'm just going to use the cache for incremental writes to the DB (backups). My other cache implementations are strictly for the sake of convience. The cache makes many complicated tasks easier. Since, I wrote the cache, data integrety isn't an issue for me (at least, not yet) ... though it's hard to say if the same is true for anyone else.
_________________
aka. twp_andrew

:: Lead Script Design :: The World of Paladium II ::