1. PDQ Deploy & Inventory Help Center
  2. Community
  3. PDQ Deploy
 

Important Notice: On February 29th, this community was put into read-only mode. All existing posts will remain but customers are unable to add new posts or comment on existing. Please feel to join our Community Discord for any questions and discussions.

Make UI (PDQDeployConsole.exe) Asynchronous and Multi-Threaded

Avatar
William Rolison

Hi,

It seems that the main UI (PDQDeployConsole.exe) is NOT Asynchronous.

I say this because when working with large data set. Think 20,000 deployments and each deployment with a few hundred computers.. The main UI freezes. 😦

Would be nice if it would NOT freeze and show instead a status window of some kind.

Also it seems it is single threaded which kills performance of course. As I notice when PDQ Deploy does lock up with loading those large data sets, it only uses 1 core CPU. Bummer.

I realize it's a huge request. Thinking version 18 for sure. Or perhaps even version 19 or 20.

Thanks,

Will

0

Comments

2 comments
Date Votes
  • Avatar
    Colby Bouma

    I talked to our development team, and they assured me the consoles actually are multi-threaded. In fact, one of the issues is that they may have too many threads! 😃

    Our development team has a large list of improvements they want to make in the near future, many of them performance related. Here's just a few of the issues they are looking into:

    • Bottlenecks that result in threads waiting on each other.
    • Slow updating of the UI due to how certain windows are composed.
    • Slow updating of the UI due to how many separate elements are being updated at the same time.
    • Non-ideal composition of the elements being updated (e.g. spinning wheel).
    • OS overhead (due to too many threads).
    • The way we interact with SQLite causes various threads to fight each other for access to it.
    0
  • Avatar
    William Rolison

    Sounds good. Appreciate your time and reply. Thanks!

    But I'm positive the UI is not multi-threaded as I watched with Process Explorer and can see only 1 thread being used and maxed out at 100%.

    Pretty easy to duplicate. Just push a few hundred different deployments to a 10,000 machines and watch UI freeze, lockup, etc. and watch it's process with process explorer. Process is only using 1 core of CPU. I typically have about 14,000 to 20,000 deployments running.

    The freezing, lockup, etc is mainly because the main UI is running on the same 1 main thread as the underpinning UI elements. They all need to be separated out and ran in an Asynchronous non blocking fashion.

    Basically the secondary UI elements need to run on separate threads. And really needs to be multi-process design.

    Something like how Chrome handles it: https://chromium.googlesource.com/chromium/src/+/master/docs/threading_and_tasks.md

    Basically the UI and IO threads are separated out so they don't lock each other up. Like what is happening now. The main thread is so busy doing IO that it locks up the UI. Pretty much expected when it's process is maxed out 100% and only has 1 CPU core to work with.

    0