G
guymills
Guest
Hi, we've got a pool of appservers which expose our business logic to "clients". So far, so normal. However, we store a huge amount of config in the database including: Security Model(s) Licensing How the business logic is obtained (entity meta-data) In general, we just access this configuration whenever it is required for each API call. OpenEdge is nice and quick, especially when running shared-memory to get this sort of stuff - it's generally in the buffer pool. Problem is, we're looking into using dataservers, and suddenly all these many "supporting" DB accesses become an issue. We're generating many SQL queries for data that we would ideally like to come from a cache. I know the SQL server will have some sort of caching itself, but I feel it's wrong that we should constantly be making network requests for the same data repeatedly. I suspect it's also bad from a performance perspective (typically we're seeing dataserver profiles 10x slower than "native" OpenEdge). One approach, I'm considering, is to create temp-tables for this security/config/meta data - and use the temp-tables instead of the database. We could prime the temp-tables on appserver start, and with minimum coding changes we could make use of the "cached" data. Obviously there would be issues regarding the data going stale, but those issues could be dealt with in a variety of ways. One drawback I can see of the temp-table approach, is we have lots of appservers and lots of data that we want to cache - this data will have to be stored somewhere, and AFAIK, OpenEdge doesn't have a way of letting multiple processes share (temp-table) data (which might be nice). So we'll have to ensure that we have enough resources (memory). I was just wondering whether anyone had any other ideas? I'm presuming we're not alone in having this sort of issue, and was wondering how others have got around it. And if you can think of any other drawbacks of the temp-table approach, can you let me know? Any input would be appreciated. Guy
Continue reading...
Continue reading...