Re: Simultaneous access to the tk script (details pitfalls)

Howdy

I tested this approach with 2-3 users simultaneously and it worked. In the real life there would be up to 20 maybe 30 users who would work with this program and probably some of them would start the packed Perl/Tk front-end simultaneously.

Benchmark? That is simulate a 100 users or a 1000 users and see what happens, poke holes in your program, find the squeaky wheel in your design

Are there any pitfalls on this approach?

kinda -- people forget to test for pitfalls, so what may be regular sameness surprises them and they call it pitfall :D

Are there any limits to the number of users who can simultaneously execute a packed Tk script?

Yes, everything has limits :)

If all the users are sharing the server, and all the perl/par is being written to the server (%temp% is on server), then you're limited by server cpu/ram and disk ... 20-30 users/instances seems very very very low

I realize this sounds very generic, but that is the essence/details of the question, sqlite has writeups on performance metrics, Tk is only limited by cpu/ram, par is limited by PAR_TEMP...

go learn how these apply to your setup

Comment on Re: Simultaneous access to the tk script (details pitfalls)

Replies are listed 'Best First'.
Re^2: Simultaneous access to the tk script (details pitfalls) by Anonymous Monk on Jun 03, 2018 at 17:21 UTC
Hi, and thank you very much for your response. I found the PAR_TEMP variable referenced in the PAR::Environment module. In the ende playing with the file who_am_i.txt here yelded a lot. If I see it right, I should make a copy of my executable without -gui argument to see the command line and with a debug print of $ENV{PAR_TEMP} as an addition. Could then $ENV{PAR_GLOBAL_TEMP} be set in the script to change the location? In the above document the variable is set outside the programm. Another question: how (in a nutshell) to benchmark the packed executable with simulation of several users. I did use the calls of subroutines with the Benchmark module. Should it be system calls to the executable in this case? However then I just start many instances of the programm as one user, not as several different users, does it make difference? Another thing - this is a GUI application, it would then open each time? Do you mean, just putting exit at the end of the script would be useful? Sorry for so many questions. I put some in the other replies too since you would not see me reply as Anonymous Monk :-).	[reply]

Replies are listed 'Best First'.

Re^2: Simultaneous access to the tk script (details pitfalls)
by Anonymous Monk on Jun 03, 2018 at 17:21 UTC

Hi, and thank you very much for your response. I found the PAR_TEMP variable referenced in the PAR::Environment module. In the ende playing with the file who_am_i.txt here yelded a lot. If I see it right, I should make a copy of my executable without -gui argument to see the command line and with a debug print of $ENV{PAR_TEMP} as an addition. Could then $ENV{PAR_GLOBAL_TEMP} be set in the script to change the location? In the above document the variable is set outside the programm.

Another question: how (in a nutshell) to benchmark the packed executable with simulation of several users. I did use the calls of subroutines with the Benchmark module. Should it be system calls to the executable in this case? However then I just start many instances of the programm as one user, not as several different users, does it make difference? Another thing - this is a GUI application, it would then open each time? Do you mean, just putting exit at the end of the script would be useful?

Sorry for so many questions. I put some in the other replies too since you would not see me reply as Anonymous Monk :-).

[reply]