linkedinattic / mobster Goto Github PK

Right now the port number to communicate to chrome is hard-coded to be 9222. At some point, we might want this to be configurable through command line.

(low priority though)

Doesn't terminate reliably and there are many messages stating that the totalHeapSize cannot be found in responses.

What : We need to re-organize the contents of page metrics table based on page timing and non-page timing metrics

Why : Its convenient to have metrics based on timing under one table as it makes it easy to read the report and helps in automated comparison between mobster reports

How : I propose we have two tables under page metrics (1) Page Timing Metrics (2) Page Metrics

(1) Page Timing Metrics table :

DOMContent Load Time [ available]
OnLoad Time [ available]
Total CSS Time [ available]

(2) Page Metrics Table :

Number of Style Recalculates [ available ]
Number of Paints [ available ]
Total Page Weight [ TBD ] - details in #11
Download Time [TBD ] - details in
Total number of Images [ TBD] - no tickets opened yet

Currently only handles Android Chrome user agent strings, and gives default value for desktop. It should support desktop user agent strings as well.

With the latest changes we have introduced excessive warning message during the execution of Mobster in the console. Please supress these warning messages under normal mode and print them to console only in DEBUG mode.

Sample from Console output

2013-01-09 22:53:26,297 WARNING totalHeapSize
2013-01-09 22:53:26,297 WARNING totalHeapSize
2013-01-09 22:53:26,318 WARNING totalHeapSize

What : We need to provide the total page weight metrics in the Mobster performance report as part of the Page Metrics table

Why : It would be useful for developers to measure the total bytes download (a.k.a. page weight ) for each page. This will help them to understand the potential implication of their feature enhancements on the performance of their pages

How : We already have the size of each component in a page under waterfall . We need to add a functionality in the visualization/reporting module to summarize the size of all the components downloaded in a page to represent the total page weight.

We need some examples which involve multiple pages and actions on pages (e.g. clicking button, filling in form, etc.)

See the attachment. I think this is a bug with chromium, but if they are not able to solve it, we need a way to detect and resolve this in mobster. One potential approach is to look at the start time of the page requested and ignore stuff before it (in the har/waterfall)

We need testing for the core functionality. One way to make this relatively painless would be to use phantomjs, though this needs to be investigated.

would be good to know if requests are served from cache, fail ,etc.

What : We need to provide the total page weight metrics in the Mobster performance report as part of the Page Metrics table

Why : It would be useful for developers to measure the total bytes download (a.k.a. page weight ) for each page. This will help them to understand the potential implication of their feature enhancements on the performance of their pages

How : We already have the size of each component in a page under waterfall . We need to add a functionality in the visualization/reporting module to summarize the size of all the components downloaded in a page to represent the total page weight.

I ran mobster against my desktop. My flow is to go to linkedin, login and go the home page again. This causes mobster to throw the following exceptions sometimes (unfortunately, not everytime):

Exception in thread WebSocketClient:
Traceback (most recent call last):
File "/usr/lib64/python2.6/threading.py", line 532, in __bootstrap_inner
self.run()
File "/usr/lib64/python2.6/threading.py", line 484, in run
self.__target(_self.__args, *_self.__kwargs)
File "/usr/local/linkedin/lib/python2.6/site-packages/ws4py/websocket.py", line 230, in run
if not process(bytes):
File "/usr/local/linkedin/lib/python2.6/site-packages/ws4py/websocket.py", line 283, in process
self.received_message(s.message)
File "/home/rmaheshw/git/mobster/src/linkedin/mobster/webkitcommunicator.py", line 61, in received_message
for callback in self._domain_callbacks[response['method'].split('.')[0]].itervalues():
RuntimeError: dictionary changed size during iteration

Some messages like these do not have 'timing' information, thus causing mobster to fail with an exception. Example callback and message (using print callback, message):

<bound method NetworkEventHandler.process_event of <linkedin.mobster.har.network.NetworkEventHandler object at 0xa82310>> {u'params': {u'timestamp': 1357698104.2517059, u'frameId': u'77.6', u'requestId': u'77.133', u'loaderId': u'77.12', u'type': u'Document', u'response': {u'status': 0, u'mimeType': u'text/html', u'url': u'data:text/html,chromewebdata', u'statusText': u'', u'connectionId': 0, u'connectionReused': False, u'headers': {}, u'fromDiskCache': False}}, u'method': u'Network.responseReceived'}

We could fix it by checking for this condition in har/network.py. Can you recheck if this is a valid fix? Are we missing any info by doing this:

git diff src/linkedin/mobster/har/network.py

diff --git a/src/linkedin/mobster/har/network.py b/src/linkedin/mobster/har/network.py
index 3f7dfd1..10c1e99 100644
--- a/src/linkedin/mobster/har/network.py
+++ b/src/linkedin/mobster/har/network.py
@@ -170,6 +170,9 @@ class NetworkEventHandler(object):
 
     # timings are not included for about: url's
     if not self._requests[request_id]['url'].startswith('about:'):
+      if not 'timing' in params['response']:
+        print "No timing"
+        return
       provided_timings = params['response']['timing']
 
       self._request_start_times[request_id] = provided_timings['requestTime']
@@ -230,4 +233,4 @@ class NetworkEventHandler(object):
     if start == -1 and end == -1:
       return -1
     else:
-      return int(end - start)
\ No newline at end of file
+      return int(end - start)

If you start Chromium, the first time you run Mobster, it will not terminate. If you kill the mobster process and start mobster again, you will no longer have problems. The same issue may exist for mobile.

With the iOS debug proxy it should be possible for Mobster to work with iOS.

Right now mobster waits for 5 minutes (300 s) in utils.wait_until(). Its a loooong time. Lets make it something more reasonable.

Right now, if you want to add to mobster the capability to use a new remote debugging command, you have to add a method (or multiple methods) which have unique behavior. We need a more general way of representing commands so additions in the future are simple.

Initial report load shows the waterfall of the first page, but if you have multiple pages in your flow, clicking on the waterfall link for any other page stops showing any waterfall.