join the community conversations

active members

Performance in iPMC



  • Avatar
    Joakim Abrahamsson

    Hi Marek,

    It's not that easy to answer such question in a generic way. Performance in inRiver is depended on many things. How the model is built, the amount of entities and fields etc. Together with the amount of extensions (as you refer to plugins).

    And continue on that line, I don't have any numbers in general how to build an extension to match your model perfectly. Something that can works for one customer, might not work for another because their models looks different and there is different complexity in the integrations etc.

    Please reach out to the support, and setup a meeting with one of our experts in building models etc. Together you will most likely find the best setup for you.

    Kind regards,

  • Avatar
    Per Bolmstedt | Kodexe ☕

    From my experiences with iPMC;

    • Server extensions process synchronously and run a greater risk of creating noticeable performance degradation.
    • Scheduled extensions typically don't slow anything down.  
    • Connector states don't scale well beyond hundreds-of-thousands of states. 
    • iPMC generally scales alot better than 6.x volume-wise.
    • Inbound extensions have significant per-request overhead, so process in batches.

    A common outbound pattern that scales well seems to be

    • Listener extensions create events using connector state as queue
    • Scheduled extensions dequeue events


  • Avatar
    Matt Munson

    We did something similar but used azure queues in-between.  The PIM performance is about 10x slower than the other system so we had concerns about messages being lost.   
    PIM -> Azure (inbound) -> ERP
    PIM <- Asure (outbound) <-ERP
    This also helps for troubleshooting or when a system is down or needs to be service restarted.


Please sign in to leave a comment.