Topic
  • 7 replies
  • Latest Post - ‏2013-01-20T13:26:16Z by SystemAdmin
SystemAdmin
SystemAdmin
7615 Posts

Pinned topic Concurrent users

‏2012-10-26T12:03:38Z |
Hi,

Is there any limit on the number of users who can run single process app concurrently?

How many users can use a single login to run an application concurrently?

Thanks and Regards,
SreeDeepya.
Updated on 2013-01-20T13:26:16Z at 2013-01-20T13:26:16Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Concurrent users

    ‏2012-10-29T14:51:18Z  
    There is not a software limitation to this. What you can achieve will be largely based on the following -

    1. The hardware and infrastructure of you system. If you have good network, alot of CPU and memory on the application server, and a real beefy backend DB, you can get way more concurrent users than on a system where 1 or more of those are not true.
    2. What the process is doing. There is a big difference in the server load if all you are doing is showing the user a screen that says "When you have done this task, click this button" and one where you need to grab, combine, and display data from 4 different legacy system.
    3. The type of interaction you users will have in the system. Once they open a task, is that up on their screen with little interaction for an hour or 2? Or is the interaction once the task running very complex with a signficant ETL layer and mutliple UI components? How many times are users going to refresh their inbox in an hour? What types of queries are you giving them to use, just the OOTB searches or custom searches that leverage Business Data?
    4. What is an acceptable response for the end user. There is a huge difference on all of the above if your target is 0.5 seconds for the screen to render vs. 5 seconds.

    In the end IBM BPM is just a tool to allow you to create a business process. IBM does have some papers out where they have measured the performance of their product on a specific process on certain hardware. But the goal of these is to be able to compare 2 releases and show how the throughput improved based on their investment in testing and optimization. There isn't a good way to say "How does my particular process compare to the one they used?"

    Asking this openeded a question is like saying "How many users can use the java application I just deployed to WebSphere?" That depends on what you wrote and how well you wrote it. If you wrote something where all the users wind up having to call into a single resource to get things done, and that resource is singly threaded, then your throughput is going to be bad...

    Andrew Paier | Director of Special Operations | BP3 Global, Inc. www.bp-3.com
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Concurrent users

    ‏2012-11-22T07:07:31Z  
    There is not a software limitation to this. What you can achieve will be largely based on the following -

    1. The hardware and infrastructure of you system. If you have good network, alot of CPU and memory on the application server, and a real beefy backend DB, you can get way more concurrent users than on a system where 1 or more of those are not true.
    2. What the process is doing. There is a big difference in the server load if all you are doing is showing the user a screen that says "When you have done this task, click this button" and one where you need to grab, combine, and display data from 4 different legacy system.
    3. The type of interaction you users will have in the system. Once they open a task, is that up on their screen with little interaction for an hour or 2? Or is the interaction once the task running very complex with a signficant ETL layer and mutliple UI components? How many times are users going to refresh their inbox in an hour? What types of queries are you giving them to use, just the OOTB searches or custom searches that leverage Business Data?
    4. What is an acceptable response for the end user. There is a huge difference on all of the above if your target is 0.5 seconds for the screen to render vs. 5 seconds.

    In the end IBM BPM is just a tool to allow you to create a business process. IBM does have some papers out where they have measured the performance of their product on a specific process on certain hardware. But the goal of these is to be able to compare 2 releases and show how the throughput improved based on their investment in testing and optimization. There isn't a good way to say "How does my particular process compare to the one they used?"

    Asking this openeded a question is like saying "How many users can use the java application I just deployed to WebSphere?" That depends on what you wrote and how well you wrote it. If you wrote something where all the users wind up having to call into a single resource to get things done, and that resource is singly threaded, then your throughput is going to be bad...

    Andrew Paier | Director of Special Operations | BP3 Global, Inc. www.bp-3.com
    Thank you Andrew
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Concurrent users

    ‏2012-11-23T14:47:07Z  
    Hi,

    Let me just add that obviously, after finding whatever the limit of your system is, you have several different ways of tuning and scaling it. Both can lead you to support more load and/or achieve better performance. The difference is that with tunning you use the existing resources to do it (but probably spend more time and need more knowledge) and scaling you'll be adding resources either physical, logical or both.

    Cheers,

    Frank
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Concurrent users

    ‏2012-11-24T17:30:16Z  
    I would like to add one more point here that we came across in our IBM BPM projects, though not directly related to the technical aspect of concurrency. If multiple users are performing read/write operations on the same BPD instance, then we have to be cautious about functional concurrency. As a result , the state of the system when the user opened a process homepage may not be the same by the time he made changes and attempted to submit them back. We had scenarios wherein the task will be no longer with the user while he's working on the page.

    Thanks.
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Concurrent users

    ‏2012-12-31T09:51:12Z  
    I would like to add one more point here that we came across in our IBM BPM projects, though not directly related to the technical aspect of concurrency. If multiple users are performing read/write operations on the same BPD instance, then we have to be cautious about functional concurrency. As a result , the state of the system when the user opened a process homepage may not be the same by the time he made changes and attempted to submit them back. We had scenarios wherein the task will be no longer with the user while he's working on the page.

    Thanks.
    Thanks to all of you for throwing some light.
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Concurrent users

    ‏2012-12-31T09:51:15Z  
    I would like to add one more point here that we came across in our IBM BPM projects, though not directly related to the technical aspect of concurrency. If multiple users are performing read/write operations on the same BPD instance, then we have to be cautious about functional concurrency. As a result , the state of the system when the user opened a process homepage may not be the same by the time he made changes and attempted to submit them back. We had scenarios wherein the task will be no longer with the user while he's working on the page.

    Thanks.
    Thanks to all of you for throwing some light.
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Concurrent users

    ‏2013-01-20T13:26:16Z  
    Thanks to all of you for throwing some light.
    Throwing a little more light on this item.

    We recently ended up with the sizing activity with IBM for proposing the infrastructure to one of our clients. IBM asked us about the nature of the business usecase at hand, the no. of user accessing the application concurrently, the total no. of users who will be interacting with the application, etc. Based on this, IBM came back with some X no. of PVUs and the recommended CPUs for the same. This was pretty confusing at the outset, but this is how it works, IMHO.

    1. IBM has benchmarked workflows(template, say) based on the nature of the business problem at hand (the implicit assumption here is that we follow the best practices and end up creating assets accordingly).

    2. For an identified template, IBM seem to have a catalogue of how many PVUs will be incurred based on the no. of users on the system.

    3. IBM also seem to have a lookup catalogue on the hardware recommendation to match the required PVUs.

    4. Once we have the hardware in place following the point#3 above, its left to our custom requirements on how we will set it up (no. of nodes, clusters, etc.) to match the system load.

    Per my understanding, there is no golden rule around this. It boils down to experience and adherence to best practices. We will still have to size our thread pools, etc. to make the application really deliver the NFRs.

    Thanks.