Running unit tests on VS2012 is lately very slow, when I run them it takes about 12 seconds before they start actually testing.
When I debug it is the same story before I hit the first breakpoint.
I hooked up process monitor and then I found this:
CreateFile \\WORKSTATION*\MAILSLOT\NET\NETLOGON SUCCESS
WriteFile \\WORKSTATION*\MAILSLOT\NET\NETLOGON BAD NETWORK PATH
After that it stays 9 seconds quiet.
CloseFile \\WORKSTATION*\MAILSLOT\NET\NETLOGON SUCCESS
What on earth is going on here? I cannot find any relation between MAILSLOT and Visual Studio at all, but it is going on for about 2 weeks now.
I had the same issue, using VS2012 Update 1. Based on the suggestion in http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/20eb50e9-3e68-4d29-bcdd-a4fc166b9c00 I disabled NetBios over TCP on my NIC. The tests now start up immediately, and procmon shows the time waiting on \MACHINE*\MAILSLOT\NET\NETLOGON dropped from 5 seconds to about 40 microseconds.
Visual Studio update 1 is now available and apparently addresses some speed issues with unit testing, whether it's related to Mailslot or not I don't know but presumably that's possible if it's in use as a communication mechanism by mstest somehow, from the MSDN forums:
In the upcoming Visual Studio quarterly release (ref http://blogs.msdn.com/b/visualstudioalm/archive/2012/10/08/visual-studio-2012-update-1-ctp.aspx), we have made some performance improvements. In short, we changed the underlying storage mechanism to improve the discovery/run time.
Download links and info here:
http://blogs.msdn.com/b/visualstudioalm/archive/2012/11/26/visual-studio-and-team-foundation-server-2012-update-1-now-available.aspx
This may not be related, but I noticed in some testing I was doing today that my Unit tests seemed to be running slower and slower. By chance I exited/restared Visual Studio and my tests are much faster now. There may be some sort of memory leak or other resource problem in the Unit Test mechanism. I am running update 1.
Related
I have Android Studio project that needs 20-40 seconds to build after running clean task. It depends on CPU temperature, NTFS filesystem cache state and maybe something else.
BUILD SUCCESSFUL in 23s
38 actionable tasks: 38 executed
Sometimes I'm working on battery with reduced notebook performance and I want to save time and battery energy.
I started searching for solutions to speed up Gradle Build and I found this:
org.gradle.caching=true # added to gradle.build file
After enabling Gradle cache my build is significantly faster:
BUILD SUCCESSFUL in 4s
38 actionable tasks: 14 executed, 24 from cache
During programming/debugging work, the increase in performance will probably not be that significant, but it will probably be noticeable.
Question:
What can go wrong if I'm using it? Why this is not enabled by default?
I've used it always and haven’t run into any issues so far. But,
if cache files become corrupted it could cause build issues
you might end up with version compatibility issues when multiple projects share the same cache
increased disk space usage.
It might not be enabled by default due to these reasons. Enable it and use it for a while to see whether it impacts the build. In that case just clear the cache and things should get back to normal. But I highly recommend using it since it significantly improves the build time cause time is money!
i'm learning how to use jetpack compose in android project.
i just created new project and choose empty compose activity template,
after build finished i run application on Android Emulator.
it successfully run but in Run logs it keep showing info log as
I/Choreographer: Skipped 75 frames! The application may be doing too much work on its main thread.
i'm worried about this issue.
can anyone please help me for this issue i will be very thankful.
log error snapshot
That's nothing to worry about. Emulator performance isn't necessarily representative of real device performance and is often slower due to the overhead of running a second operating system (Android) within your operating system. This is especially true if you don't have the emulator's various hardware acceleration options enabled.
Also, apps run from Studio are debuggable, which disables a number of the optimizations that ART (the Android runtime) would be able to perform on a release app. Plus it needs a bit to load the code into memory and perform just-in-time compilation of the Compose framework.
Bottom line: Don't worry about performance unless you see issues in release mode on a real device.
I've upgraded a laptop (Windows 10 Enterprise, Version 1803) and 2 VMs (Windows 10 Enterprise, version 1809) with MicroFocus' UFT version 14.53. The previous version of UFT was 14.02.
The performance of script execution is annoyingly slow. Here are some details about the environment:
Two AUT were developed using J2EE and Angular JS, respectively
A script that took 18 minutes to run on the laptop is now taking 20 minutes
The same script is now taking 30 minutes on the VMs
The scripts are being run in fast mode from the GUI
The windows 10 machines have been set to Best Performance
Every time the script starts, the Windows is running low on resources
popup appears
The browser on which the app is being run is IE11
RAM on the laptop is 16GB and 8GB on the VMs
Anybody else experience these pains who can offer any solutions or suggestions? Unfortunately, our support vendor has been no help.
Thank you!
1) Depending on what kind of object recognition you perform, there might be noticeable differences depending on how many windows are open on the windows desktop.
It might be that in you Windows 10 sessions, there are more windows open, maybe invisible, that UFT needs to take account when locating top-level test objects.
For example, opening four unneeded (and non-interfering) browser instances and four explorer instances greatly impacts the runtime performance of my scripts. Thus, I make sure that I always start with the same baseline state before running a test.
To verify, you could close everything you don't need, and see if runtime improves.
2) Do you use RegisterUserFunc to call your functions as methods? That API has a big performance hole: depending on how much library code you have (no matter where, and no matter what kind of code), such method calls can take more time than you expect.
I've seen scenarios where we had enough code that one call took almost a second (850 milliseconds) on a powerful machine.
Fix was to avoid calling the function as a method, which sucks because you have to rearrange all such calls, but as of today, we are still waiting for a fix, after it took us months to proof to MicroFocus that this symptom is indeed real, and really fatal because as you add library code, performance degrades further and further, in very tiny steps. (No Windows 10 dependency here, though.)
3) Disable smart identification. It might playback fine, but it might need quite some time to find out which "smart" identification variant works. If your scripts fail without smart id, you should fix them anyways because your scripts never should rely on smart identification.
4) Disable the new XPath feature where UFT builds an XPath automatically, and re-uses this XPath silently to speed up detection. It completely messes up object identification in certain cases, with the script detecting the wrong control, or taking a lot of time to detect controls.
5) Try hiding the UFT instance. This has been a performance booster for years, and I think it still is, see QTP datatable operations *extremely* slow (much better under MMDRV batch executor)? for info on this, and more.
6) Certain operations do take a lot of time, unexpectedly. For example, Why does setting a USER environment variable take 12 seconds? completely surprised me.
Here are things to consider that have been tweaked to speed up my scripts in the past, hadn't had any problems with UFT 12.x on VM machines or VDI's and using Windows 11. I'm just starting with UFT 14.53 on Windows 10. Check Windows 10 for background applications or services that are running prior to even opening UFT or executing a script. In UFT check the Test Settings and UFT Test Options for the following:
Object synchronization timeout - Sets the maximum time (in seconds) that UFT waits for an object to load before running a step in the test.
Note: When working with Web objects, UFT waits up to the amount of time set for the Browser navigation timeout option, plus the time set for the object synchronization timeout. For details on the Browser navigation timeout option, see the HP Unified Functional Testing Add-ins Guide.
Browser navigation timeout - Sets the maximum time (in seconds) that UFT waits for a Web page to load before running a step in the test.
When pointing at a window, activate it after __ tenths of a second - Specifies the time (in tenths of a second) that UFT waits before it sets the focus on an application window when using the pointing hand to point to an object in the application (for example, when using the Object Spy, checkpoints, Step Generator, Recovery Scenario Wizard, and so forth).
Default = 5
Add ____ seconds to page load time - Page load time is the time it takes to download and display the entire content of a web page in the browser window (measured in seconds).
Page load time is a web performance metric that directly impacts user engagement and a business’s bottom line. It indicates how long it takes for a page to fully load in the browser after a user clicks a link or makes a request.
There are many different factors that affect page load time. The speed at which a page loads depends on the hosting server, amount of bandwidth in transit, and web page design – as well as the number, type, and weight of elements on the page. Other factors include user location, device, and browser type.
Run mode - Normal -> or Fast ->
Hope some of this helps, good luck...Aimee
You can try Run a Repair UFT installation on Windows 10, see if something was wrong on installation of the uft 14.53.
This worry me a lot, since we gonna change in a couple of days for laptop with Win10.
Try see here if something can help you.
Regards
I'm making app with using XF pcl.
on iOS, Thread finished count does not match started count.
I said this because there is a log output and it prints like "Thread started: #55" and "Thread finished: #55" when I debug with iPhone device.
I counted them but started log counts are about 300 and finished log counts are about 100.
Is this can be any clue that my app has some problem that some of started threads were not finished normally?
Or what's the better way to check this issue deeply?
Thanks.
If you're counting the threads correctly, it really seems that you have a leak somewhere. In your situation, I'd turn into profiling tools and the thread window provided by the IDE. Here are the steps you should take:
Both Xamarin Studio (outdated screenshot) and Visual Studio have a Threads window in the debugger pane that can be used to investigate currently running threads in detail. Use them to verify that you actually have an abnormal amount of active threads.
If you have an Enterprise subscription, use the Xamarin Profiler to find out performance bottlenecks in your application. This will very likely help uncover problems in your code as well as in 3rd party code.
Use Xcode Instruments to do the same as above, if you have access to a MAC. Here's how to use them with Xamarin.iOS.
After these steps, you should have at least verified that there is a problem. It's also quite likely that you've found the cause of that problem and fixed it.
UPDATE: I've figured it out. See the end of this question.
I have an Azure App Service running four sites. One of the sites has two deployment slots in addition to the primary one. Recently I've been seeing really high CPU utilization for the App Service plan as a whole.
The dark orange line shows the CPU percentage. This is just after restarting all my sites, which brought it down to this level.
However, when I look at the CPU use reported by each site, it's really low.
The darker blue line shows the CPU time, which is basically nothing. I did this for all of my sites, and all the graphs look the same. Basically, it seems that none of my sites are causing the issue.
A couple of the sites have web jobs, so I took a look at the logs but everything is running fine there. The jobs run for a few seconds every few hours.
So my question is: how can I determine the source of this CPU utilization? Any pointers would be greatly appreciated.
UPDATE: Thanks to the replies below, I was able to get more detail into what was happening. I ended up getting what I needed from SCM / Kudu tools. You can get here by going to your web app in Azure and choosing Advanced Tools from the side nav. From the Kudu dashboard, choose Process Explorer. The value in the Total CPU Time column is not directly useful, because it's the time in seconds that the process has run since it started, which might have been minutes or days ago.
However, if you make a record of the value at intervals, you can look at the change over time, and one process might jump out at you. In my case, it was my WebJobs process. Every 60 seconds, this one process was consuming about 10 seconds of processor time, just within one environment.
The great thing about this Kudu dashboard is, if you can catch the problem while it is actually happening, you can hit the Start Profiling button and capture a diagnostic session. You can then open this up in Visual Studio and get some nice details about where the CPU time is being spent.
Just in case anyone else is seeing similar issues, I'll provide more details about my particular case. As I mentioned, my WebJobs exe was the culprit, and I found that all the CPU time was being spent in StackExchange.Redis.SocketManager, which manages connections to Azure Redis Cache. In my main web app, I create only one connection, as recommended. But Since my web jobs only run every once in a while, I was creating a new connection to Azure Redis Cache each time one ran, which apparently can lead to issues. I changed my code to create the Redis Cache connection once when the WebJob process starts up and use the existing connection when any individual WebJob runs.
Time will tell if this really fixes the issue, but I think it will. When the problem occurred, it always fit the same pattern: After a few days of running fine, my CPU would slowly ramp up over the course of about 12 hours. My thinking is that each time a WebJob ran, it created a connection object, which at first didn't produce trouble, but gradually as WebJobs ran every hour or two, cruft was building up until finally some critical threshold was met and the CPU usage would take off.
Hope this helps someone out there. Best wishes!
May be you should go to webApp scm?
%yourAppName%.scm.azurewebsites.com;
There is a page, that can show you all process, that runned now on your web app. (something like Console > Process).
Also you can go to support page (from scm right corner).
You can find some more info about your performance there, and make memory dump (not for this problem, but it useful for performance issues).
According to your description, I assumed that you could leverage the Crash Diagnoser extension to capture dump files from your Web Apps and WebJobs when the CPUs usage percentage is higher than the specific threshold to isolate this issue. For more details, you could refer to this official blog.