a.txt

search expensive urls in a uwsgi server log.
hits between 3 and 99 seconds:

python check.py uwsgi.log 3000 99999

output:

 GET /api/1/search?q=E => generated 470381 bytes in 3433 msecs (HTTP/1.0 200) 4 headers in 135 bytes (1 switches on core 0)
 GET /api/1/search?q=A => generated 586983 bytes in 4412 msecs (HTTP/1.0 200) 4 headers in 135 bytes (1 switches on core 0)
 GET /api/1/search?q=R => generated 457041 bytes in 3653 msecs (HTTP/1.0 200) 4 headers in 135 bytes (1 switches on core 0)
 GET /api/1/search?q=R => generated 457041 bytes in 3680 msecs (HTTP/1.0 200) 4 headers in 135 bytes (1 switches on core 0)
 GET /api/1/search?q=R => generated 457041 bytes in 3785 msecs (HTTP/1.0 200) 4 headers in 135 bytes (1 switches on core 0)
 GET /api/1/search?q=A => generated 587169 bytes in 4491 msecs (HTTP/1.0 200) 4 headers in 135 bytes (1 switches on core 0)
 GET /api/1/search?q=R => generated 457041 bytes in 3446 msecs (HTTP/1.0 200) 4 headers in 135 bytes (1 switches on core 0)
 GET /api/1/search?q=R => generated 457122 bytes in 3612 msecs (HTTP/1.0 200) 4 headers in 135 bytes (1 switches on core 0)
 GET /api/1/search?q=A => generated 587285 bytes in 4557 msecs (HTTP/1.0 200) 4 headers in 135 bytes (1 switches on core 0)
 
people is using a "search" box with autocomplete in the mobile app. so some fixes are needed in there: hit when str length is > 3, reduces the query, the bytes and the time.
 
 end.

check.py

import sys

with open(sys.argv[1]) as f:
    content = f.readlines()

for line in content:
    parts = line.split("bytes in ")

    if len(parts)>1:
        msecs = parts[1].split(" msecs ")[0]
        msecs = int(msecs)
        if msecs >= int(sys.argv[2]) and msecs <= int(sys.argv[3]):
            print line.split("]")[2]