I apologize for any mistakes made or dumb questions asked, but this is my first one here.
I tried to search for the solution, but wasn't able to. Here is what's going on.
I have Nginx + virtualenv + Gunicorn + Django project. Django is still in Debug mode.
The thing I can not figure out is why all my Django responses are hardly cached. E.g., if I request a certain Url/View with no URI parameters, it will show me exactly what is coded, but if I then pass predefined parameters, that should be giving me another result, however it still shows the previous one.
As far as I can see, each of such responses is being cached per each Gunicorn worker. So when I restart Gunicorn, I then can see the proper result, however that is also cached right away.
I also tried running Gunicorn with --debug option, but it looks like that is not the solution.
Does anybody know where should I dig to? Thanks in advance for any help.
UPDATE:
If I put...
HttpResponse('abc')
at the very beginning of the view, server will sure give me that as response. If I then change it to...
HttpResponse('def')
the server will still give me 'abc' as a response until I restart Gunicorn in the virtualenv. When I restart Genicorn and check it gives me 'def', it will then be giving me 'def' all the time until I restart Gunicorn again.
Related
I'm currently developing my first app with DRF and I'm pretty impressed by it and the browsable API it has build in. However, when I change the port where I host my application (both in manage.py aswell as in the runserver command), all the buttons stop working. I can still click on links to make sure resources where created, but that's about it. I also can't log in and the POST forms don't appear, which is really the most annoying part. Moreover, when I change the port back to the default 8000, it's still broken.
Don't really know if I can post an example of this. It doesn't seem to depend on anything in the actual code. It just happens when I change the port.
So while I don't know what exactly caused it, a CTRL-reload has fixed it for now. Still pops up from time to time.
I have a small problem with Django settings.
In my page I have some really big input and I got the error:
The number of GET/POST parameters exceeded settings.DATA_UPLOAD_MAX_NUMBER_FIELDS.
took me about 3sec google to find a solution
DATA_UPLOAD_MAX_NUMBER_FIELDS = None # None so it ignores the error -> change to big number results in the same error
In my local develop it works like a charm. On the server I did the same and after that:
service apache2 restart
but i still get the error.
Any ideas?
I found a soultion.
For some reason I don't know apache2 didn't load the whole settings.py.
I just reuploaded the entire App and restartet apache2 after that.
Maybe there was a bad path or something.
It is my first time trying to get a Django application live on the net but I am having an issue with the URls.
The working local URL of my application is
http://localhost:8000/surveythree/ - This works as expected.
However when I upload my project to my hosting account I cant seem to locate the relevant page using the shortened URL as provided by the URLconf, in this case it should be /surveythree/
url(r'^surveythree/$', SurveyWizard.as_view([SurveyForm1, SurveyForm2, SurveyForm3, SurveyForm4, SurveyForm5])),
I can locate the page if I use the full filepath however.
http://www.mywebsite.com/bias_experiment/src/survey/templates/formtools/wizard/wizard_form.html
I thought the benefit of the URLconf was to shorten the URL to something like one of the following
http://www.mywebsite.com/bias_experiment/surveythree/
http://www.mywebsite.com/bias_experiment/src/surveythree/
http://www.mywebsite.com/bias_experiment/src/survey/surveythree/
Is there something simple that I am missing here? If anyone could tell me what the shortened URL should be based on the above it would be great. I have been trying multiple combinations for a while now but I don't know if I am going around in circles or doing it wrong.
Thanks in advance.
It doesn't look like you have actually deployed your site with a proper server. You can't just upload the files to any webserver and expect then to run: you need to configure a wsgi server and connect it to your app.
The documentation is here but to be honest I'd be amazed if your college server supported it at all, if all you have is a shared folder. You may be able to get it to work with FastCGI, but I wouldn't hold out a whole lot of hope.
(And even though you say that going to that long URL "works", I'd guarantee that all you're seeing is the raw HTML template. There's no way that any actual dynamic functionality will be working like that, as you'd see if you actually tried to submit the form at that URL.)
Deploying Django apps is much more complicated. To run in more "production" environment you will need to configure:
virtualenv to keep pip modules which your app required separate from global environment.
nginx for hosting static files ( you can copy them to some folder with ./manage.py collectstatic.
WSGI server: uWSGI or Gunicorn are both nice choices.
supervisor: for running and restarting WSGI and any other apps (for example celery) running in background
It's a lot for a start, so it's good to follow some tutorial and use ready to use config snippets.
I tried to add sleep(30) at the first line of my view. After that I opened this page in two browser tabs. The first tab loaded the page after 30 seconds, and the second one loaded it in 60 seconds. In the meantime I was able to open pages from another pc just fine. So it looks like Django blocks the concurrent requests from the same client.
This is very well for my app. And I'd like to be sure my site will work this way in the future. However I have not found any documentation or articles describing such Django behaviour. So I'm still not sure if this is a feature or just fortune. Could somebody please explain how and why this works?
What I actually need is to block the session while view is processing. Of course I can use some flags or db transactions. But I'd not like to add a feature that is already implemented in Django.
I use python 2.6.5, django 1.4, ubuntu server, nginx and uwsgi. Tried both postgresql and sqlite.
My uwsgi settings:
<uwsgi>
<pythonpath>/home/admin/app/src</pythonpath>
<app mountpoint="/">
<script>deploy.wsgi</script>
</app>
<workers>4</workers><!-- Not sure this is needed -->
<processes>2</processes>
</uwsgi>
I also got same effect with runserver command.
Actually Django does not block simultaneous requests.
If I run two browsers (for example chrome and firefox) with the same session (by copying the sessionid cookie from the first browser to the second one), blocking does not happen. So, this is a browser feature, and it's not related to Django anyhow. This means I still need to add some blocking feature by myself to make the code safe.
My Apache (mod_wsgi) Django app only lists the files of my website/project instead of the actual running website/application. My guess is that it's mod_wsgi that is the culprit but I'm not really sure. What are some of the causes of this?
Don't put your Django site code in a directory Apache can serve up. Right now if I knew the actual site host name, I could get down your Django settings file and get access to your database password information.
Anyway, ensure you have gone and set up a basic WSGI hello world program before you attempt to get Django working under mod_wsgi. In doing this, ensure you use the official mod_wsgi documentation and not some arbitrary persons blog post. As such, go read:
http://code.google.com/p/modwsgi/wiki/QuickInstallationGuide
http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide
Also go watch the video presentation at:
http://code.google.com/p/modwsgi/wiki/WhereToGetHelp?tm=6#Conference_Presentations
as it steps you through basic configuration as well as what to do for Django. It covers all the basic things that people do wrong.
If you still can't get it to work, then heed the comments in:
http://code.google.com/p/modwsgi/wiki/WhereToGetHelp?tm=6#Asking_Your_Questions
about useful information you should supply to any forum to help people solve your problem.