Icinga will spend much less time running your Perl plugins because it no longer forks to execute the plugin (each time loading the Perl interpreter). Instead, it executes your plugin by making a library call.

It greatly reduces the system impact of Perl plugins and/or allows you to run more checks with Perl plugin than you otherwise would be able to. In other words, you have less incentive to write plugins in other languages such as C/C++, or Expect/TCL, that are generally recognised to have development times at least an order of magnitude slower than Perl (although they do run about ten times faster also - TCL being an exception).

If you are not a C programmer, then you can still get a huge amount of mileage out of Icinga by letting Perl do all the heavy lifting without having Icinga slow right down. Note however, that the ePN will not speed up your plugin (apart from eliminating the interpreter load time). If you want fast plugins then consider Perl XSUBs (XS), or C after you are sure that your Perl is tuned and that you have a suitable algorithm (Benchmark.pm is invaluable for comparing the performance of Perl language elements).

Using the ePN is an excellent opportunity to learn more about Perl.

A Perl program that works fine with plain Icinga may not work with the ePN. You may have to modify your plugins to get them to work.

	Important
	Please note that you might introduce memory leaks so you shouldn't run your plugin without having tested/verified it using new_mini_epn (to be found in the contrib folder).

Perl plugins are harder to debug under an ePN than under a plain Icinga.

Your ePN will have a larger SIZE (memory footprint) than a plain Icinga.

Some Perl constructs cannot be used or may behave differently than what you would expect.

You may have to be aware of 'more than one way to do it' and choose a way that seems less attractive or obvious.

You will need greater Perl knowledge (but nothing very esoteric or stuff about Perl internals - unless your plugin uses XSUBS).