On Fri, Feb 1, 2013 at 9:08 PM, Olivier Hanesse
<olivier.hane...@gmail.com>wrote:
>
> We really need to think about this "N broker" stuff.
> - n brokers / realm (so each broker can deal with one module)
>
In fact we already got N brokers / realm. The good one is n
brokers/scheduler.
But you show the real point here : module dedicated broker. It's strongly
linked to the n brokers / scheduler.
> - 1 broker / realm, with potential broker in higher realm
>
> By the way, I don't know (shame on me) how exactly WebUi is working
> internally, but why not using Livestatus as a backend for Webui ?
>
I will ask a LOT of code and time.
> I know having all object in memory is a great thing for speed, but I'm
> using Livestatus Uis every day, and the speed of the LiveStatus stack isn't
> an issue at all.
> We will lose (maybe) some 'micro-seconds' of reactivity, but scalability
> will be much easier. And we could have a wsgi env.
>
Let's look at real case about performances. How is a WebUI performing with
N sub schedulers? First let's bench it before asking lot of new code :)
Jean
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
