Forum Discussion

ucuber's avatar
ucuber
Occasional Contributor
6 years ago

Slow start of webtests

Hi all,

 

I have a strange phenomenon I do not understand.

 

Assume I start the webtest the first time of the day on a nearly clean system.

For this I have build a wrapping class (python) and actually use the chrome browser:

 

...

  def start(self, name):
      Browsers.Item[name].Run(self.base_url)
      return self

 

Next action is, that I click on a text element on the webpage, identifying it via css-selectors, what works very fast usually.

 

But it nearly always happens, that at the start of the browser the navigating-action is veeeery slow, also the first click on to the element. Sometime both take more than 40 secs!

 

Some time later on the same system: I start the same test, without rebooting it or resetting or s.th. like this. And than - tadaa - everything works fine and fast. What took 40 secs now takes 5 secs ...

 

Does anyone have an idea what happens during this slow first tests? and how to avoid it?

 

Regards

 

Ulrich

  • I agree, most likely it has something to do with caching.  Some recent versions of Chrome actually keep chrome running as a background process (an optional setting) to speed up browsing.  It could be that the first run starts the Chrome process and each run afterwards uses the already started process.

  • My first guess would be that something is being cached on the first pass.  Not sure how to fix it though.

    • tristaanogre's avatar
      tristaanogre
      Esteemed Contributor

      I agree, most likely it has something to do with caching.  Some recent versions of Chrome actually keep chrome running as a background process (an optional setting) to speed up browsing.  It could be that the first run starts the Chrome process and each run afterwards uses the already started process.

  • Just my 2 cents worth.  Yes, I also find that the first time I open the application it is slow.  I use Visual Studio & ASP.net. so your experience may vary, but I'm sure the principles are the same.  Running in debug mode from VS always compiles the site in IIS Express before you start.  If you aren't debugging from VS or similar IDE, IIS creates and caches each page the first time someone opens it and then keeps it cached untill the app pool is stopped, the memory cap is reached or the recycle time is reached (You set these in IIS on the app pool properties)  To decrease this load time, you can ensure that your web config inludes a debug="false" which removes some overhead and makes pages load faster.  What makes much more of an impact is if you can publish the website precompiled.  You can then set your tested app to run off localhost directly.   This means IIS doesn't wait till you want to load the page to compile the website the first time.  It won't eliminate that first cache though.  You can map your pages in namemapping as http://*/Pages/MyPage so you don't end up having to remap everything each time you switch from testing to production servers