How to Speed up Loading the First Page of Django Project?

[flora.xia...@gmail.com]

Hi,

I am deploying a Django project on Apache2. The Apache is running using mod_wsgi daemon mode. The first page of the website usually loads so slow. Before loading the first page (html, css) the user's identification should be verified (check the variable they pass through GET). When checking the developer tools I find that it is the verification that takes 10 to 20 seconds. The most of time is stuck in waiting (TTFB). An Apache process is created for each user. On the server, the very slow load corresponds with a 100% CPU use.

I find similar question here (https://stackoverflow.com/questions/1702562/speeding-up-the-first-page-load-in-django). However, revising the configuration file is not helpful.

Is there anyone who has an idea of the problem? Or do I need to provide more information about the problem? Thanks.

[Jason]

I would suggest you post the configuration file here as well as the server specifications and average CPU/memory usage.  Because what you're describing is definitely not normal and is most likely related to how Apache is configured.

A point of clarification: does the first page always load slowly, or is it just the first page after you restart the server?

[flora.xia...@gmail.com]

Thank you for your reply. The first page always loads slowly while the rest of the pages loads at a normal speed. Whether I restart the apache or not doesn't affect the speed of loading the first page - always slow.

Below is the configuration file in the sites-available folder under apache. My apache is 2.4.

<VirtualHost *:80>

        ServerAdmin webmaster@localhost

        DocumentRoot /var/www/html

        <Directory />

                Options FollowSymLinks

                AllowOverride None

        </Directory>

        <Directory /var/www/html>

                Options Indexes FollowSymLinks MultiViews

                AllowOverride None

                Require all granted

        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

        <Directory "/usr/lib/cgi-bin">

                AllowOverride None

                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch

                Require all granted

        </Directory>

ErrorLog /var/log/apache2/error.log

        # Possible values include: debug, info, notice, warn, error, crit,

        # alert, emerg.

        LogLevel warn

        CustomLog /var/log/apache2/access.log combined

    Alias /doc/ "/usr/share/doc/"

    <Directory "/usr/share/doc/">

        Options Indexes MultiViews FollowSymLinks

        AllowOverride None

        Require all granted

        Allow from 127.0.0.0/255.0.0.0 ::1/128

    </Directory>

Alias /static path/to/my/project/static

        <Directory path/to/my/project/static>

                Require all granted

        </Directory>

  <Directory path/to/my/project>

        <Files wsgi.py>

                Require all granted

        </Files>

        </Directory>

  WSGIDaemonProcess myproject python-path=path/to/my/project:path/to/my/project/lib/python2.7/site-packages

  WSGIProcessGroup myproject

  WSGIScriptAlias / path/to/my/project/myproject/wsgi.py

</VirtualHost>

Thank you!

在 2017年11月17日星期五 UTC-5上午8:27:24，Jason写道：

[flora.xia...@gmail.com]

And this is the first few lines of requests in the network section in developer tools. You can see that the first step to verify the user's identification takes so long.

When multiple users pop in, the memory usage of the server will be very high.

在 2017年11月17日星期五 UTC-5上午8:27:24，Jason写道：

I would suggest you post the configuration file here as well as the server specifications and average CPU/memory usage.  Because what you're describing is definitely not normal and is most likely related to how Apache is configured.

[Antonis Christofides]

Hello,

How does the verification work?

Regards,

Antonis

Antonis Christofides
http://djangodeployment.com

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/4cb4d8a9-6709-4f89-923f-bf5cc311e05a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[flora.xia...@gmail.com]

Hi,

The worker id and hit id are passed via GET. (It's a website for amazon mechanical turker to finish tasks.) And views.py checked their worker id and hit id to see whether they are valid. If they're valid, then the turker will be directed to the following pages.

[Jason]

Does that worker call execute slowly each time you call it?  Or is it just the once?

I'd copy that URL and try calling it several times with an REST API client like Postman.  Does the request execute that slowly each time you call it, or is it just the initial call that is slow?

[flora.xia...@gmail.com]

Hi Jason,

Thanks for your help! I just solved the bug. 

The reason of the bug is that in the first step after I verify the worker's identification, I should put them in the database. And in django default setting, PASSWORD_HASHERS is set to PBKDF2 to hash the password for each worker. It is a complex algorithm, slowing down the speed to put users in the database. So I change PASSWORD_HASHERS to SHA1P. In this way, the user is put in the database faster, thus the first page is loaded faster.

[Jason]

That is not a good solution.  There's a reason why the default password hashing algorithm is complex.

And I find it hard to believe that a password hash is the culprit here.  Maybe a quarter second or so added to a response, but 10 seconds?  that's definitely not the cause.

[flora.xia...@gmail.com]

But that's all I revised of the code. The configuration file of server engine and all the other things keep the same.

[Jason]

Regardless, your solution is not a good one, because you shifted from a password hashing algorithm that enables protection against brute-force attacks to a different algorithm with no similar protection.

I would highly suggest you read https://docs.djangoproject.com/en/1.11/topics/auth/passwords/