On 13.09.2013 23:04, Carl R. Friend wrote: > >> regarding the sparc 440mhz - well that's low end, just as embedded >> hardware. noone expects a mysql cluster running on pi's (or do they?). >> having an rdbms as backend for icinga web and reporting, you'll get more >> complex data aggregation capabilities left to the rdbms itsself fetching >> the output afterwards. example - sorting in memory on browser call is >> evil. classic ui / cgis do that - they parse the files into memory and >> operate on that. that's quite the same you need to do with livestatus >> json in your php application, sort it like beckham on-call. > I candidly admit that my 440 MHz SPARC is a corner-case, but such > a setup is remarkably useful for detecting things like memory-leaks > that might take weeks to become noticable on a modern multi-gigabyte, > multi-gigaHertz system. On Pi-based systems, there seems to be at > least one guy who was trying it, and if there's one there are more. > > There's no way in creation that I'd recommend such a system (his > or mine) for anything like a production environment, but for > development and R&D they're quite useful indeed. (It turns out that > it was the Apache web-servers that crushed my little machine -- not > the database (which runs on a separate machine.)
true that. if it's the apache, i would look at php and the version included. i've seen installs with php 5.2.6 (iirc that was debian lenny) and once they got php 5.3.x a tremendously performance increasement was to be seen. further, i would suspect that php 5.4 will run even better. and from what i've read about the zend developers integrating their speed-up patches into php 5.5 upstream, i would guess that my debian testing with 5.5.3 does an even more magnificant job here. but still, it's not just the php engine/language operations. i'd also look for the apache version itsself. i did not do any performance comparisons between 2.2 and 2.4 yet (2.4 is in debian testing too - see the icinga.org blogpost about it), but i am highly convinced that using old software with new web interfaces won't be much fun. recently i've suggested to update to php53 packages on sles 11 at a customer - because i do know that it runs faster than the natively shipped 5.2.x (which is end-of-life and might not receive any patches in the future). still, i do know that in the solaris world, you'll stick with what's available. and with 10, it's obviously from 2005 and older. it would be interesting if you'll get boost compiled on it (and icinga2 afterwards). either way, there might still be some space for tuning the applications itsself (apache, php, mysql). the native install method would likely work for the smallest setup (imagine wordpress), but once you'll get into expansion ideas, you'll have 2 options: 1) your strategy contains the "get big and cluster stuff" option already 2) you'll have to rethink/rebuild your strategy. both options work, and both options require man power. here at work (netways) i've seen both happening in projects, and both actually work in the end. guess what will happen when icinga2 becomes ready - have it on your roadmap, follow development now, or step into it later, rethink your strategy? :-) (at work, it's definitely the "now, and prepare for later too" ;-) still, for the original question - as remarked, it may become a backend question somehow. but if you're looking at the services required (nagvis runs with idoutils btw too - https://wiki.icinga.org/display/howtos/NagVis , next to web and reporting), you may have made your decision already. but - and that's a good thing imho - you can still use the icinga guis in parallel, and let even your users decide. and sometimes, classic ui is totally fine running on a distributed slave, e.g. for debugging checks being run, or anything else where a gui would say more than 1000 lines of status.dat ;-) (and with 1.9.x it was made standalone, mainly to interact with icinga2, but also as standalone seperate dashboard). afterall, if it's for the backend - in icinga2, we've got 3 backends for compatibility on our roadmap (try git master): 1) status.dat/objects.cache/icinga1xlog 2) ido db (components which writes directly to the db, no extra daemon) 3) livestatus. So once you'll ask yourself, and then decide for one backend, you will find it in icinga2 for compatibility reasons then too - if that's something you require in planning your monitoring for the next years. i guess, we will have some stuff to showcase during osmc this year in our presentation (http://www.netways.de/index.php?id=3994&L=1), especially the newly designed cluster setup gunnar is currently working on (aka "it just works", heard this week in our dev room ;) ). have a nice weekend! michael -- DI (FH) Michael Friedrich mail: michael.friedr...@gmail.com twitter: https://twitter.com/dnsmichi jabber: dnsmi...@jabber.ccc.de irc: irc.freenode.net/icinga dnsmichi icinga open source monitoring position: lead core developer url: https://www.icinga.org ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk _______________________________________________ icinga-users mailing list icinga-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/icinga-users
