Startup Management
From KallestadWiki
Overview
Caching the complete set of application variables at startup is certainly desirable, and we can make use of memcached in order to reduce database load and dependency and shrink startup times.
It has occurred to me that initialization routines need to be intelligently managed so that when additional processes are generated during high load times, end users are not suffering response delays due to entirely unused structures being processed before events are handled.
This brings about the subject of whether or not to use a pool of database connections managed through a daemon rather than each process managing it's own database connections directly - there are pro's and cons to each methodology, and it is certainly a concern moving forward to porting the KDF to other platforms. There is also the subject of threading, which types of threads to use, or whether a wheel based event processor is more appropriate. This kind of thinking inevitably makes me sleepy.
Certainly all database platforms can handle 100 concurrent connections, but those sort of numbers generally involve a little bit of tweaking, and if things are optimal database connections shouldn't be required for the majority of requests in a high volume environment - most people would be looking at data as opposed to changing data, and in those cases, popular data should be cached in front of the database. Food for thought.
Kallestad Development Framework Topics
- KDF Home
- Project Overview
- Technical Information
- Licensing
