Profiling is not working

[bluven]

I'm trying to profile a api of this project. I had followed the instructions of the readme of django-silk, but the profiling page was empty, though i could see files generated under profiles directory which i configured.

The project's address is https://github.com/bluven/py-perf, it's a simple project， the method i profiled is api/views/UserViewSet.list

settings.py

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'silk'
]

MIDDLEWARE = [
    'silk.middleware.SilkyMiddleware',
    'django.middleware.cache.UpdateCacheMiddleware',
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
    'django.middleware.cache.FetchFromCacheMiddleware',
]

SILKY_PYTHON_PROFILER = True
SILKY_PYTHON_PROFILER_BINARY = True
SILKY_PYTHON_PROFILER_RESULT_PATH = os.path.join(BASE_DIR, "profiles")

api/views.py

class UserViewSet(ModelViewSet):
    queryset = User.objects.all()
    serializer_class = UserSerializer
    lookup_field = 'username'

    @silk_profile()
    def list(self, request, *args, **kwargs):
        print('*')
        return super(UserViewSet, self).list(request, *args, **kwargs)

Thanks in advance.

[max-wittig]

Same for me using django-silk==2.0.0. Seems like #161 is back

[dingosaurus]

#meeto

django 2.0, django-rest-framework

    @silk_profile()
    def dispatch(self, request, *args, **kwargs):
        return super().dispatch(request, *args, **kwargs)

[laiyijie]

metoo django 2.02 and silky 2.0.0

[mbeacom]

Bug is present in master as well.

[jasconius]

i am also seeing this behavior

[danielbradburn]

I can't replicate this, does the directory os.path.join(BASE_DIR, "profiles") exist? Perhaps you could try the example project in the silk repository to see if you still have the same issue, for me that works as well as using silk via SILKY_PYTHON_PROFILER_RESULT_PATH

[timthelion]

I have this problem as well. I followed the instructions. Profiling files are created. But the profiling page shows no profiles. And it wasn't just a problem with the page, I loaded up the database with shell_plus and the Profile.objects.all() returned an empty query set. But I knew that some profiling had run, because there was the .prof file sitting in SILKY_PYTHON_PROFILER_RESULT_PATH.

I tried moving around the middle-ware but nothing worked.

But when I tried the example app, and it worked fine.

Then I created a simple view:

@silk_profile()
def status(request):
    status_page = str(datetime.datetime.now()) + '\n'
    status_page += socket.gethostname()
    return HttpResponse(status_page)

and it also worked fine.

Compare that to the view that didn't work:

class RidesDetailsView(TitleViewMixin, RegistrationMessagesMixin, LoginRequiredMixin, TemplateView):
    title = _("Podrobný přehled jízd")
    template_name = 'registration/rides_details.html'
    registration_phase = 'profile_view'

    @silk_profile()
    def dispatch(self, request, *args, **kwargs):
        return super().dispatch(request, *args, **kwargs)

    def get_context_data(self, *args, **kwargs):
        trips, uncreated_trips = self.user_attendance.get_all_trips(util.today())
        uncreated_trips = [
            {
                'date': trip[0],
                'get_direction_display': models.Trip.DIRECTIONS_DICT[trip[1]],
                'get_commute_mode_display': _('Jinak') if util.working_day(trip[0]) else _('Žádná cesta'),
                'distance': None,
                'direction': trip[1],
                'active': self.user_attendance.campaign.day_active(trip[0]),
            } for trip in uncreated_trips
        ]
        trips = list(trips) + uncreated_trips
        trips = sorted(trips, key=lambda trip: trip.direction if type(trip) == Trip else trip['get_direction_display'], reverse=True)
        trips = sorted(trips, key=lambda trip: trip.date if type(trip) == Trip else trip['date'])

        context_data = super().get_context_data(*args, **kwargs)
        context_data['trips'] = trips
        days = list(util.days(self.user_attendance.campaign.phase("competition"), util.today()))
        context_data['other_trips'] = models.Trip.objects.filter(user_attendance=self.user_attendance).exclude(date__in=days)
        return context_data

( context: https://bitbucket.org/pdlouhy/do-prace-na-kole/src/master/dpnk/views.py )

I'm going to venture a guess that the problem is somewhere in the Mixins, but I'll have to delve deeper.

[garyayo]

I'm experiencing this issue as well. Using django-silk=3.0 and django=1.11.10 and cannot generate a profile at all. I just keep seeing Cannot execute silk_profile as silk is not installed correctly. even after following the directions in the readme.

[jasconius]

Any word on this? An above commenter noted that mixins might be to blame but I have no such issue

Even if I put the decorator on a dead simple view, I still get a broken request summary and no profile information.

edit

I manually created the intended profile data directory in my server, and this has resulted in the profile data files actually being created

However, on the silk pages, I still see no profile information, with the standard "No Silk profiling was performed for this request." message

edit 2 if I disable the profiler after these actions take place, my request summaries remain broken, and new requests logged are still broken, with sql query summaries also missing - this leads me to assume that the presence of the decorator itself has something to do with the issue

[quorth0n]

I had the profiling directory pointing to a folder that didn't exist (path was messed up), after fixing it the profiling page works as expected. Running latest silk and django. Snakeviz states that the generated .prof files aren't valid, but they can be viewed in silk's page no problem. I'm not using dynamic profiling which might have something to do with it. The requests also appear as 0 ms until they're completed, though I think this is the intended behavior.

[aj07mm]

it worked here with:

• requirements

Django==1.11.21
django-silk==2.0.0

• settings.py

SILKY_PYTHON_PROFILER = True
SILKY_PYTHON_PROFILER_BINARY = True
SILKY_PYTHON_PROFILER_RESULT_PATH = os.path.join(APP_ROOT, 'profiles')

[Toreno96]

I had the profiling directory pointing to a folder that didn't exist (path was messed up), after fixing it the profiling page works as expected.

It helped in my case 👍

[aj07mm]

One other thing. The problem can happen due to a large amount of data or a long connection on the database. In that case the server gone away can happen.

Try this increasing these numbers if that happens:

• max_allowed_packet: http://dev.mysql.com/doc/refman/5.7/en/packet-too-large.html
• wait_timeout: http://dev.mysql.com/doc/refman/5.7/en/gone-away.html

[brianhwitte]

The code in profiler.py, line 125 looks like this:

    def _silk_installed(self):
        app_installed = 'silk' in settings.INSTALLED_APPS
        ...
        return app_installed and middleware_installed

The Readme, however, instructs users to set up the app like this:

INSTALLED_APPS = (
    ...
    'silk.apps.SilkAppConfig'
)

When I change my project to look like this everything works ok:

INSTALLED_APPS = (
    ...
    'silk'
)

Background:
python 3.8, Django 2.2
I was getting an error in the django console on starting the app, with a stacktrace pointing to silk/profiling/profiler.py lineno: 105. Also, the requests at <project_root>/silk were displaying correctly, but the Profiles tab was empty. I could see a lot of .prof files in my SILKY_PYTHON_PROFILER_RESULT_PATH directory, though.

After changing the INSTALLED_APPS as shown above, the profiles were visible and I was no longer getting the error at startup. The requests tab is still showing data.