I noticed the green line at the bottom started with a database call and is just staying there. Does this means my db call is stuck open or something?
No, this graph is Execution Time over Time and the green line is there due to the existence of some database calls within the period. Its simply an artifact of the graphing itself.
Related
I have one drive synced local folder and the files will be synced with a SharePoint site when we add files to this folder. I also have a Flow that gets triggered for every file added.
The detailed article about what I am achieving here can be found here.
The problem is that it is not triggered all the time. Let's say I added 100 files and the Flow triggered only 78 times. Are there any limitations on the Flow that it can run only this many times in a timeframe? Anyone else faced this issue? Any help is really appreciated. #sharepoint #sharepointonline #flow #onedrive
Finally, after spending a few hours, I got it working with 120 files at the same time. The flow runs smoothly and efficiently now. Here is what I did.
Click on the three dots on your trigger in the flow, and then click on settings.
Now in the new screen, enable the Split On (Without this my Flow was not getting triggered) and give the Array value. Clicking on the array dropdown will give you the matching value. Now turn on the Concurrency as shown in the preceding image and give the Degree of Parallelism to maximum (50 as of now).
According to Microsoft:
Concurrency Control is to Limit the number of concurrent runs of the flow or leave it off to run as many as possible at the same time. Concurrency control changes the way new runs are queued. It cannot be undone once enabled.
For a test, I want to delete an SQLite database file before each run, so that the process that I am testing creates a new one each time. However, it seems that os.remove() is somehow buffered and then executes after the database has already been recreated, deleting the (already partially filled) database in the middle of my test!
Is there any method to ensure that the file has been deleted (on disk)? I do not want to disable io buffering in general, as I want to test the performance of my process in a realistic environment.
I am working on a performance test of Citrix application using Load Runner and Citrix Protocol.
I need to wait for a window to appear, and reading the documentation I see I can use one of those:
ctrx_sync_on_window : Waits until a window is created or becomes active.
ctrx_set_window_ex : Waits a specified time for a window to appear in the Citrix client
But reading their documentation, I don't clearly understand the difference except for the time factor and which one I should use.
I tried each of them, and they are working for me, but I don't know which one is the best.
First Option:
ctrx_sync_on_window("Notepad", ACTIVE, 0, 0, 801, 601, "snapshotXX", CTRX_LAST);
Second Option:
// Wait 5 seconds for Notepad popup to appear
ctrx_win_exist("Notepad",5)
ctrx_win_exist is mostly used, when there is a time frame needed until a windows appears/becomes active;
ctrx_sync_on_window is part of the synchronization options, such as bitmap sync. It will make sure the windows is located on a specified position.
Usually it depends on the script which one is better to be used
I'm currently monitoring files in node.js using fs.watch. The problem I have is for example, let say I copy a 1gig file into a folder I'm watching. The moment the file starts copying I get a notification about the file. If I start reading it immediately I end up with bad data since the file has not finished copying. For example a zip file has it's table of contents at the end but I'd end up reading it before it's table of contents has been written.
Off the top of my head I could setup some task to call fs.stat on the file every N seconds and only try to read it when the stats stop changing. That would work but it seems not ideal as I'd like my app to be as responsive as possible and calling stat on a bunch of files every second seems heavy as well as calling stat every 5 or 10 seconds seems unresponsive.
Is there some more robust way to get notified when a file has finished being modified?
So I did a project last year which required doing "file watching". There is a better library out there than fs.watch. Check out npm chokidar.
https://www.npmjs.com/package/chokidar
Underneath it uses fs.watch, but wraps better improvements around it.
There is a property called awaitWriteFinish. Really it's doing some polling on the file to determine whether or not the file is finished writing. I used it and it really works great.
Setting this property will allow you to work against that file, always ensuring that the file has been completely written. And you don't need to go off and implement your own method of determining if the file is complete. Should save a bunch of time.
Aside from that, I don't believe you can really get away from polling with regard to determining if a file is finished writing. Chokidar is still polling, it's just that you don't need to write the logic to do it. And you can configure the polling interval if CPU utilization is deemed to be too high.
Edit: Would also like to add, to just give it a shot and see how it works. I get you want it as responsive as possible... But having something working is better than having something not working at all. It might be that even with a polling solution it's not even an issue for you. If it's deemed a performance problem, then go address it at that time and seek a "better" solution.
Connection successfully established by nca_connect_server() but i am trying to capture current open window by using nca_get_top_window() but it returns NULL. Due to this all subsequent requests fail
It depends on how you obtained your script, whether it recorded or manually written.
If script is written manually there is guarantee that it could be replayed, since it may happen that sequence of API (or/and its parameters) is not valid. If script is recorded – there might be missed correlation or something like this, common way to spot the issue – is to compare recording and replaying behavior (by comparing log files related to these two stages, make sure you are using completely extended kind of log files) to find out what and why goes wrong on replay, and how it digress from recording activity.