> On Feb 24, 2016, at 1:53 PM, Jan Sindberg <[email protected]> wrote: > > The more complete solution we offer ... > I want performance but also cheap operations costs. Based on that I accept > our operations choice of hosting. That hosting comes with limited CPU power > and therefore bad performance. We are also an international company, and that > introduces network latency and more trouble for performance. Although I speak > from our experience, I believe that there are many others which are in a > similar situation.
Not sure you have convinced me here. Why should we have to fix the problems that are related to the service provider not having sufficient hardward? But let’s back up… Just how bad are the numbers? And what are the performance targets? The reason I ask, maybe it is fast enough, just something isn’t hooked up right which is slowing things down. I’ll not be in favor of adding on the assumption that it will make things faster. We need hard numbers that then illustrate the problem and give us targets to shoot for. > > On Feb 24, 2016, at 1:53 PM, Jan Sindberg <[email protected]> wrote: > > With homemade caching also comes the trouble of ensuring synchronized data - > in our case the BA opted for a timeout on the cache, otherwise we would have > to hack Commander to send events, or hook into ApacheDS. The drawback of this > solution is that you cannot shut down a user instantly, which I don't think > is in the spirit of best practice security. That depends on the timeout and > therefore you would like a short timeout which then begs the question of what > was gained in perceived performance? > Caching client-side might somehow question the accelerator effort ? > > In summary: > The benefits would be a more "complete" plug'n'play product which guarantees > performance in most circumstances and ensures best practice within security. > Still configurable policies must exist for when network connection to main DS > is lost. Yes synchronization is tricky. Not just with home grown caches. In addition to a caching mechanism we need an event notification system in place too. More weight. Keep in mind I’m not discounting anything you’re saying, but bringing up my concerns. > > On Feb 24, 2016, at 1:53 PM, Jan Sindberg <[email protected]> wrote: > > - the solution with embedded ApacheDS (thanks, Emmanuel, I forgot we already > had that discussion) could act as an emergency brake in case of lost > connection to the main DS in the rare situation where you at the same time > needs to shut down a user or just modify permissions for some high-profile > customer right now - although that has its own twists like running a > commander agaings that or opening Apache Studio and editing the raw entries > directly (not so nice). I’d like to explore this idea as well. Best to solve the problem outside of fortress and put it somewhere that is more capable of handling it and allow fortress to remain - simple. Shawn
