Initializing
First initialize the mysql database from a previous dump as we did on the PERL virtual box.
|
1 2 3 4 5 6 7 8 9 10 11 |
/etc/init.d/mysql start mysql -e 'show databases' [root@localhost ~]# mysql -e 'show databases' +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | test | +--------------------+ |
|
1 2 |
mysql -e 'create database gumibomba_dev' mysql gumibomba_dev < import.sql |
Install the framework
Check for python version. And if needed install python setuptools. After it install django is very easy and can be done in 5 minutes.
|
1 2 |
# python --version Python 2.6.6 |
|
1 |
# yum install python-setuptools |
|
1 2 |
# curl https://raw.github.com/pypa/pip/master/contrib/get-pip.py | python # pip install Django |
Piece of cake. Definitely one point to Django.
First steps
Django will take care of everything if we put the following rows in command line.
|
1 2 3 4 |
# mkdir /var/www # cd /var/www # django-admin.py startproject mysite # python manage.py startapp gumi |
Again, very easy and straightforward.
Now we have the basic site in out www directory. Let’s run the server to see it’w working. Sometimes the development server failed to server a request. In this case a refresh helped.
Import models from database to Django.
We need to setup the MySQL connection. It can be set in sandbox/settings.py. But first of all we have to install mySqlDb to python.
|
1 |
# easy_install mysql-python |
|
1 |
# python manage.py inspectdb > gumi/models.py |
It is possible that we have to rearrange the order of models in the file according to the foreign keys because the referred class has to be before the referrer class.
Now we have all the models we need. Let’s create the test application.
Create the first application
In the gumi/urls.py file which we can set the to urls we need for the test.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
# cat gumi/urls.py from django.conf.urls import patterns, include, url from django.views.generic import DetailView, ListView from gumi.models import Gumi urlpatterns = patterns('gumi.views', url(r'^$', ListView.as_view( queryset=Gumi.objects.all()[:10], context_object_name='gumi_list', template_name='gumi/list.html')), url(r'^(?P<pk>\d+)/$', DetailView.as_view( model=Gumi, template_name='gumi/detail.html')), ) |
Django was developed in a very “DRY-driven” method which means you can always use the simplest solution for almost everything. In this example we don’t even need a controller (or how django calls it view) to be able to create this two pages. We just import some generic views ( DetailView and ListView) to the config file and write the templates.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
{% if gumi_list %} <table> <thead> <tr> <th>Márka</th> <th>Típus</th> </tr> </thead> <tbody> {% for gumi in gumi_list %} <tr> <td>{{ gumi.g_marka }}</td> <td>{{ gumi.g_tipus }}</td> <td><a href="/gumi/{{ gumi.g_id }}/">show</a></td> </tr> {% endfor %} </tbody> </table> {% endif %} {% endblock %} |
|
1 2 |
# cat templates/gumi/detail.html <h1> {{ gumivariacio.g_marka }} {{ gumivariacio.g_tipus }} </h1> |
Nginx and FastCGI
Again I think there’s no need to go in to details about this. It’s really some copy pasting some default nginx configuration file to be able to do this.
By the way. Test was run with threaded model fastcgi server started from init.d script with manage.py. With this solution there was no failing requests as we had before with the development server built in Django.
Results
The results look very good. Especially if we look on the memory and CPU usage. Shocking how small amount of CPU was used even with 50 concurrent thread. I thought PERL will be much faster with a little more cpu consumption but this results really surprised me. I’ve tested it three times but the numbers didn’t change.
| Index | Show | |
| AB 5 conc | 123,42 | 158,78 |
| AB 20 conc | 118,64 | 167,52 |
| AB 50 conc | 116,92 | 160,34 |
| Memory usage | 7,80% | 6,10% |
| CPU usage | 3,10% | 2,20% |
Recent comments