Re: New way to run your Django projects
Il giorno 19/mar/2012, alle ore 15:46, Alexander ha scritto: > Kurtis, > > There is nothing wrong with using uwsgi protocol instead of FastCGI > but you still have to run uWSGI server and it doesn't fit "simply > using nginx" description. And I wouldn't call it "out of the box" > either if I'd have to rebuild Nginx instead of using one shipped with > my Linux distro (Debian Squeeze has Nginx with uwsgi module in > backports and uWSGI is only available in unstable branch). > > I didn't say gevent-fastcgi is best way to run WSGI application. > Yes, but when you release a software, be prepared to answer the most useless, provocative and rageous questions :) Expecially if your project is pretty 'unique'. You are lucky (for now), the questions you got are all 'gentle' :) Your project is really funny, but you will need to fight with two factors: few users/developers understand non-blocking/async programming (albeit a lot of them use, and blindly suggest, such technologies) webservers support for multipexing fastcgi requests is practically non-existent or buggy, on which webserver you have tested your project ? In addition to this, Django is not the kind of framework/platform you can - easily - adapt to non-blocking/async paradigm :( -- Roberto De Ioris http://unbit.it JID: robe...@jabber.unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Problems with Virtualenv and Django 1.4 -- deployment on uwsgi.
> Since I've upgraded the version of Django and started a new project on > it, I cannot make it work properly with uwsgi. > > The problem is that django doesn't import apps from project tree. My > settings.py looks like this: > > INSTALLED_APPS = ( > 'django.contrib.auth', > 'django.contrib.contenttypes', > 'django.contrib.sessions', > 'django.contrib.sites', > 'django.contrib.messages', > 'django.contrib.staticfiles', > # Uncomment the next line to enable the admin: > 'django.contrib.admin', > # Uncomment the next line to enable admin documentation: > # 'django.contrib.admindocs', > #Practical apps: > 'engine.blog', > ) > > My config for uwsgi looks like this (parsed by yaml): > > uwsgi: > uid: www-data > gid: www-data > socket: /tmp/wsgi_dev.sosek.net.sock > module: django.core.handlers.wsgi:WSGIHandler() > chdir: /home/sosek/nginx/dev.sosek.net/apps/engine > env: DJANGO_SETTINGS_MODULE=engine.settings > virtualenv: /home/sosek/.virtualenvs/dev.sosek.net > pythonpath: /home/sosek/nginx/dev.sosek.net/apps > you should update your module directive to module: engine.wsgi Check latest official Django docs on uWSGI https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/uwsgi/ -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django nginx uWSGI
> Hi, I am attempting to get nginx and uwsgi running on my local box, I
> followed any number of tutorials and this one had the most complete
> information.
> http://gekicstart.ca/tech-posts/nginxuwsgidjango-stack/
>
> It is written for Debian\Ubuntu so I had to transpose a bit. I got through
> most of it and I got to the section on creating the daemon for uwsgi that
> loads a specific project. It creates a /etc/init/projectX.conf file that
> it
> loads the uwsgi specific information from. I didn't know enough to create
> a
> daemon in arch so I opted for running the command by cli.
>
> /usr/bin/uwsgi socket /root/Workspace/Eclipse/sockets/projectX.sock
> --chmod-socket --module wsgi_app --pythonpath
> /root/Workspace/Eclipse/projectX/uwsgi -p 1
>
> I also extended the relative paths to absolute from the example code, so
> far so good. but when it loads the below file.
>
> when I run this it craps on the django import
>
> #!/usr/bin/python2.7
> import sys
> import os
> import django.core.handlers.wsgi
> sys.path.append("/Eclipse/")
> os.environ['DJANGO_SETTINGS_MODULE'] = 'projectX.settings'
> application = django.core.handlers.wsgi.WSGIHandler()
>
>
I suggest you to follow official docs/quickstart
http://projects.unbit.it/uwsgi/wiki/Quickstart
Most of the blog-posts out-there refer to very particular configs that could
make mess in your mind.
By the way, it looks like you have built uWSGI for a different python
version.
>From its source directory do
make clean
python2.7 uwsgiconfig.py --build
to be sure the correct python version is used (the first command is used
for cleaning files from the previous build)
When uWSGi starts it print a good amount of log-lines, try to always read
(or report) them to fastly get help.
--
Roberto De Ioris
http://unbit.it
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: [help] Server Config: django + uwsgi + nginx
> I have this file that was created for me by one of the users in django's > irc channel. I edited to have the right information inserted but I"m not > sure what I'm doing wrong to not make it work. I've spent some time trying > to understand each line by searching the web. There's still a thing or two > that's missing from the puzzle. Maybe it's the server config that has a > flaw or the way I went about it. I haven't done a fresh install of uwsgi > and nginx yet. However, please take a look to see if there's an error or > solution that could work. Thanks. > > Link to code: http://www.dpaste.org/wWVd3/ > I suggest you to not start with such a complex scenario. I would go step-by-step with a very simple setup involving only uWSGI: http://projects.unbit.it/uwsgi/wiki/Quickstart Then, change the http protocol to the uwsgi one (simply replace http = with socket = ) and put it behind a simple nginx config (like the one you will find following the uWSGI quickstart). Then move to the 'upstart' part, adding the script to the /etc/init directory. Finally start playing with caching (it can be the most challenging part) -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: [help] Server Config: django + uwsgi + nginx
> i followed the django-http+uwsgi quick start and ended up with an error. > ImportError: no module named django.core.handlers.wsgi \n unable to load > app ... > here's the error log: dpaste.org/BM5BW Are you sure you are not using a >=1.4 django version or a virtualenv ? If you are uging a virtualenv, add virtualenv = to the uWSGI config file > > On Sunday, April 29, 2012 11:31:43 AM UTC-7, Roberto De Ioris wrote: >> >> >> > I have this file that was created for me by one of the users in >> django's >> > irc channel. I edited to have the right information inserted but I"m >> not >> > sure what I'm doing wrong to not make it work. I've spent some time >> trying >> > to understand each line by searching the web. There's still a thing or >> two >> > that's missing from the puzzle. Maybe it's the server config that has >> a >> > flaw or the way I went about it. I haven't done a fresh install of >> uwsgi >> > and nginx yet. However, please take a look to see if there's an error >> or >> > solution that could work. Thanks. >> > >> > Link to code: http://www.dpaste.org/wWVd3/ >> > >> >> I suggest you to not start with such a complex scenario. >> >> I would go step-by-step with a very simple setup involving only uWSGI: >> >> http://projects.unbit.it/uwsgi/wiki/Quickstart >> >> Then, change the http protocol to the uwsgi one (simply replace http = >> with socket = ) and put it behind a simple nginx config (like the one >> you >> will find following the uWSGI quickstart). >> >> Then move to the 'upstart' part, adding the script to the /etc/init >> directory. >> >> Finally start playing with caching (it can be the most challenging part) >> >> -- >> Roberto De Ioris >> http://unbit.it >> > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-users/-/73nF9MjDBvYJ. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django & uWSGI best practices
> Hi. > I'm going to deploy a few (8-12) Django projects on my VDS with Ubuntu > 12.04 and nginx. And I wonder how should configuration look like, to be > explicit, simple and easy-to-understand for others (it will be maintained > by another dude). > Should I use emperor-mode for such a small amount of sites? Should I add > web specific-user, or it could be run as www-data (this is it's usecase, > right?) and in /var/www? Should I use single uWSGI-instance from sudo > apt-get install uwsgi or pip install for every project? Anyone use some > sort of django > conventions<http://blog.zacharyvoase.com/2010/02/03/django-project-conventions/>may > be? > One more my wish is the easy-to-deployment (and easy-to update) sequence, > because I planning to write a script for automatic deployment and apply it > for my other servers, which would have the same anount of sites. In near > future. > I suggest yout to always use the emperor. Choose a directory for your app config files (like /etc/uwsgi/apps), and put a config file for each uWSGI instance. Fill each config file with comment for each directive (the other dude will thank you for that). Use a different uid for each app (if you can) Regarding application directory or virtualenv usage i have no particular suggestion, for me it is a matter of taste. What i very-strongly suggest you is NOT USING virtualhosting mode. I know it is funny but it is very complex to manage and secure. Finally give a look at --idle,--cheap and --cheaper options, they could help you in maintaining resources low. -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Any clue why Facebook iframe would be blank?
> On Fri, Jun 22, 2012 at 3:59 AM, Gabriel - Iulian Dumbrava < > gabriel.dumbr...@gmail.com> wrote: > >> Hi, >> I think something similar happen to me when I set the width of the >> iframe >> to be too narrow. I'm not very sure, but maybe you cand check it out. >> >> Gabriel >> > > Hey Garbiel, > > I actually figured out the issue on my end. From what I gather, uWSGI > doesn't handle small POST data sizes well. I had to change a couple of > uWSGI configuration parameters (as seen on Stackoverflow). > As far as I can tell -- my stuff is all good now, both in the Fluid and > fixed-size layouts. > > If you need any help debugging yours, let me know! And thanks for the > feedback. > > This is a common problem in all of the proxied setup: http://flask.pocoo.org/snippets/47/ The real fix is always reading POST datas when they are available (even if you are not interested in them). Not reading them means your communication socket with the webserver will be clobbered soon or later. If you do not want to change your code you can use the uWSGI --post-buffering option that will automatically buffer post data in memory (or to disk). -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Using os.fork() in a Django view
Il giorno 19/ago/2011, alle ore 08:46, Kevin ha scritto:
> Hello everyone,
>
>
> Here's the code I will be needing to run in a os.fork():
> from django.core.management import setup_environ, call_command
> import settings
> setup_environ(settings)
> call_command('', **kwargs)
>
> So this would be in a separate function and called from a view which
> uses os.fork(), or should I place os.fork() in the same function as
> this code. Of course the sys.path will be re-written before any
> imports are done. I plan on integrating Virtualenv with this. The
> model in the management Django project will contain the directories
> and such that point to the Virtualenv.
>
> If anybody is interesting in helping with such a project, I am very
> much open to any help. I hope that this project may open Django to a
> wider world of users, if the command-line Django admin stuff can be
> done through a nifty web interface. I have a server which it can be
> developed and tested on as well.
>
IMHO, this is the wrong approach from a security/sysadmin point of view.
All of your django instances will run under the same uid. bad: all of your
users will be able
to destroy other instances.
If you want to call a setuid after each fork() you have to run the django panel
as root. even badder.
As a rule, do not allow users generating fork(). You will need to implement a
throttling system (and this could be a pita).
Even if modern os are stronger against fork bombing, you can destroy a whole
server easily.
The most secure approach would be enqueing the tasks (you can use celery, uWSGI
spooler, or a dedicated daemon or whatever you want)
and execute one by one (this solves fork bombing problem). You will lose
real-time, but you will gain security.
Each task should run as a specific uid, so for each customer run another daemon
waiting for event (it will really run manage.py and runfcgi for you).
Lot of work to do, you should take in account that the uWSGI project is built
with this target in mind (ISPs), and has systems to easily administering
multi-uid environments:
http://projects.unbit.it/uwsgi/wiki/Emperor
http://projects.unbit.it/uwsgi/wiki/FastRouter
http://projects.unbit.it/uwsgi/wiki/LinuxNamespace
http://projects.unbit.it/uwsgi/wiki/UseCgroups
the main idea (already used by more than 20 ISPs worldwide) is having the
"panel" generating config files (they can be even taken via http dynamically)
After you have a user instance running, you could add an embedded app on it to
launch tasks (so it will be the user app itself executing processes)
Another (rawer, but funny, used by rosti.cz) approach is this one:
https://github.com/creckx/uWSGI-Manager
You can even start from the ground and re-implement all of this concepts in
pure-python (in this case i suggest you to try gunicorn as it is more simple to
integrate [being in python]).
Or you could follow the old-raw-way of dinamically generating apache
virtualhosts file for each customer and let mod_wsgi+daemon_mode do the hard
work.
Well, returning to the os.fork() problem, if you really need it, be sure that
it will be the user slice/area/instance calling it (so you can limit with the
various jailing technics) and not your main control panel.
--
Roberto De Ioris
http://unbit.it
JID: robe...@jabber.unbit.it
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Creating a WSGI Request for another uWSGI Django App
> Hello,
>
> You guys are always so helpful so I thought I'd come here with my
> crazy problem I'm trying to solve.
>
> I have a Django Application Cluster. We use subversion for our code.
> The only type of a post-commit hook we have is an HTTP Request with
> JSON at a URL we define. Essentially what I want to do is to use this
> post-commit hook to trigger a cluster-wise reload of the uwsgi
> service.
>
> The problem is that I don't really want to implement a fancy script
> that uses SSH or anything along those lines. First off, there are
> security issues. Secondly, I want it to be relatively quick and
> integrated into our app for easy replication as we add and remove
> nodes.
>
> I started off with some code -- just trying to play around the idea. I
> want to have two views. The first view is titled "svn_hook". This view
> is tied to the URL that is called from the post-commit hook by our SVN
> Hosting Provider. The second view is titled "uwsgi_reload".
>
> svn_hook()'s job is to simply open a connection with each of the nodes
> and call their uwsgi_reload() views. uwsgi_reload()'s job is to simply
> execute /etc/init.d/uwsgi... reload.
>
> Unfortunately, I have *no* idea how to get this thing to work. I tried
> approaching it with some RPC code in MoinMoin that I was forwarded to
> by a nice guy in #wsgi. But, as it turns out, I have no idea what I'm
> doing :)
>
> I think if I can get the servers to talk to each other, then I can
> handle the rest. If you guys have any ideas on either how to fix this
> code, or a better way of approaching this problem, I would really
> appreciate the input.
>
> By the way, I understand that WSGI is a completely different protocol
> from HTTP. I tried to understand the code the best I could and had no
> idea what was going on exactly with the key/value pairs I saw in the
> MoinMoin code. Hopefully someone can understand what I was trying to
> accomplish there
>
> Thanks again!
> -Kurtis
>
> from django.http import HttpResponse
>
> # View for URL Called by SVN on Post-Commit Hook
> def svn_hook(request):
>
> # Resources
> # import urllib # Used in example code, not here yet...
> from httplib import HTTPConnection
>
> # List of IP Addresses to Reload
> #
> hosts = ('192.168.1.1', '192.168.1.2')
> port = '7999'
>
> # Hit the Server
> """
>
> Note:
> I was going to do more here ... but I can't
> even get the thing to work without stalling or throwing
> errors. I wanted to check for a 200 Status from each
> host and eventually log if any fail.
>
> """
> for host in hosts:
> client = HTTPConnection(host, port, False, 30)
> client.request("GET", '/reload')
> response = client.getresponse()
> body = response.read()
> body = body.decode('utf-8')
>
> # Done
> return HttpResponse(status = 200)
>
> # Temporarily set as /reload for testing purposes.
> def uwsgi_reload(request):
>
> # Execute /etc/init.d/uwsgi reload
> # and any other logic that may need to be performed
> # I'll do this later, after I get the actual WSGI call
> # working.
>
> return HttpResponse(status = 200)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
Are your servers on a multicast-enabled network ?
If they are you can use this
http://projects.unbit.it/uwsgi/wiki/Clustering
Your svn hook will be only a one-line:
os.system("uwsgi --cluster-reload ")
--
Roberto De Ioris
http://unbit.it
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Simple task dispatching (How heavy is celery + RabbitMQ)
Il giorno 28/nov/2011, alle ore 12:14, Gelonida N ha scritto: > Hi, > > I'd like to use a light weight dispatching system for a web server. > > Basically some django post requests might require processing, which > should be done in the back ground due to its run times. > > The results would be added to the django data base. > > The browser could verify via AJAX requests whether the task is finished. > > > The server would be running on a rather weak virtual machine with rather > low memory (nginx / uwsgi / django ) > > ( For testing I run the server on windows with one of the following > setups (depending on what I'd like to test) > - django runserver > - twisted - django > - cygwin/nginx - fastcgi - django > > > Celery is very good, but as you will run uWSGI in production you can look at http://projects.unbit.it/uwsgi/wiki/Spooler and its abstraction: http://projects.unbit.it/uwsgi/wiki/Decorators#spool (check https://github.com/jaysonsantos/django-uwsgi-mail for a real-world usage) If you want to go lower-level, check for mules: http://projects.unbit.it/uwsgi/wiki/Mules Even django-zeromq (as already suggested by someone) is very good. Another solution is using python thread queues: http://projects.unbit.it/uwsgi/wiki/Example#threadqueue -- Roberto De Ioris http://unbit.it JID: robe...@jabber.unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Django gracefully shutdown
> > Hello! > > After lot of work I'm ready to deploy my site on production. I'll use > Nginx > with uWSGI or fastCGI (not sure yet), and my doubt is how can I shutdown > my > production Django app gracefully (for make changes for example). Of course > I can kill django-python-fcgi processes and restart everything again but > is > that correct? Can someone give me some hints please? > > Thanks! > There are various way to accomplish that in uWSGI. As always there is no 'one fit for all' solution so you have to evaluate yourself. For example lot of people are satisfied with simple 'binary-patching' approach (sending SIGHUP to the master) where the sockets are not closed between reloads. Other people (generally the ones with very high-loaded sites) cannot tolerate the slowdown of the application during the reload, so they prefer to spawn a whole new stack (with the new code) and simply move the connections to the new one as soon as the new app is ready (and eventually move back to the old instance if something is wrong) This second approach requires a bit of effort (compared to the simple SIGHUP approach) but is fore sure the most versatile. Regarding fastcgi (read: flup, as fastcgi is only a communication protocol) i do not think it is still "on par" with more modern solutions like uWSGI, gunicorn and mod_wsgi. Again, if you want a simple pure-python application server, gunicorn is a better solution than flup (IMHO) -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Multiprocess and Global State
> I all, > > Environment: > - Django 1.5.1 > - mongoengine 0.8.1 > > I use mongoengine to store and manage user accounts authentication. > > it work fine with the development server and uwsgi : only if I use a > single > process or thread mode. > > If i use more than 1 process, sometime ( when i refresh my application ), > i > am redirected on my login form. > > All my request must be authentified, i use a middleware to do this : > > from django.http import HttpResponse,HttpResponseRedirect >> class AuthenticationMiddleware(object): >> >> _LOGIN_PATH = "/accounts/login_view/" >> >> def process_request(self, request): >> if (request.path != self._LOGIN_PATH) and not request.is_ajax(): >> if not request.user.is_authenticated(): >> return HttpResponseRedirect( self._LOGIN_PATH+'?next=%s' >> % >> request.path) >> return None > > > I think , there are unshared data between the processes who causes this > problem. > > What do you think? > > > Note : it works well with gunicorn > > Ch. > If it works well with gunicorn it could be a problem with how (or better 'when') you open the connection to mongodb. Add --lazy-apps to uWSGI options to load the application after fork() (like gunicorn) -- Roberto De Ioris http://unbit.it -- 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+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: request_finished signal not being called with Django 1.5.1 with uwsgi
> I've created a ticket https://code.djangoproject.com/ticket/20537 > > Not sure if this can be fixed in Django or a stern warning in the > documentation can suffice. Honestly (i am the main uWSGI author) whoever is using a uWSGI version < 1.2.6 should be worried by dozens more things (no more support, no more security updates, known bugs, basically broken newrelic support, broken threads and i do not even know what scary things you can find in it ...) We are talking about a package of 2 years ago... and this specific problem is caused by a (serious) bug in ancient uWSGI releases with WSGI specs, so why django should bother ? -- Roberto De Ioris http://unbit.it -- 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+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: supervisor
> Hi, > > Anyone could share a good process control system software name to use > with uwsgi ? Apart from supervisor, I couldn't make it work : > - can't stop it only kill it > - bug on supervisorctl reload.. Even when using the last version. > > Thank you > Are you sure you need one ? uWSGI Emperor is way more capable (in terms of monitoring and management of bad-behaving apps) and easy to manage (just drop files in a directory) By the way, if you cannot use distro-included process managers (upstart or systemd), i find circus a great alternative to suprvisord. I have seen lot of users happy with 'god' too (it is a ruby app) -- Roberto De Ioris http://unbit.it -- 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+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/f1a0778bda3a30ab9c9d09522b171797.squirrel%40manage.unbit.it. For more options, visit https://groups.google.com/groups/opt_out.
Re: SystemError from django.conf.settings
> As suggested on #django yesterday I swapped the site over to manage.py > runserver and also tried gunicorn and they are both stable so it looks > like a problem with uwsgi. As already suggested it looks like a Python c api problem, do you mind to fill a bug report in the uWSGI wiki with all the relevant information ? (mainly how python is compiled, as most of the time this kind of errors are related to python excessive optimizations) > > Gunicorn is also surprisingly fast, beating uwsgi on a httperf test to > one of the heavier pages on the site. oh yes, and you will see tons of comparison reporting the opposite, others showing mod_wsgi is better and so on... Please try to understand that WSGI bridges/gateways/servers are pratically irrelevant in your app performance. Gunicorn works for you ? Perfect ! you have found your WSGI server ;) -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: django 1.3 timing out on empty POST request
> @Karen, I tried the patch, and it doesn't seem to help. Do you have > any ideas when is the 1.3.X scheduled to be released? > > @Bruno, using nginx + WSGI + DJANGO is the setup. If you mean mod_wsgi for nginx, i am not able to help you, but if you mean nginx + uWSGI, you will probably only need to enable post-buffering in uWSGI (--post-buffering 4096 will be enough). Remember to use 0.9.8.1 (latest stable) as it contains a much better wsgi.input implementation. > -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: django 1.3 timing out on empty POST request
> Roberto, > > it is uWSGI, but can you explain a bit more what the post-buffering > would help me do? > Would it help me debug with pdb? > -mehdi Before starting a pretty long and boring explanation, can you double check if you are using the 0.9.8.1 version of uWSGI ? It should manage POST data in a safer way avoiding blocking calls. -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: django 1.3 timing out on empty POST request
Il giorno 27/giu/2011, alle ore 22.07, mehdi ait oufkir ha scritto: > Roberto, I'm actually using uWSGI 0.9.6.5. > > Can you tell me what is the issue with the previous version. I can > stop by on uwsgi IRC if you want to take the conversation off google's > groups. > > -mehdi Versions < 0.9.8 expect a fully compliant (read: very simple) WSGI behaviour. Actually the world is a bit more complex than this so in 0.9.8 i added a more "tolerant" wsgi.input object. (pratically it is the same technic of mod_wsgi for apache with some addition) Upgrading to 0.9.8.1 can bypass the issue or eventually throw an error pointing to what it is wrong in django code. > > On Jun 26, 9:47 pm, "Roberto De Ioris" wrote: >>> Roberto, >> >>> it is uWSGI, but can you explain a bit more what the post-buffering >>> would help me do? >>> Would it help me debug with pdb? >>> -mehdi >> >> Before starting a pretty long and boring explanation, can you double check >> if you are using the 0.9.8.1 version of uWSGI ? It should manage POST data >> in a safer way avoiding blocking calls. >> >> -- >> Roberto De Iorishttp://unbit.it > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-users@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Some thoughts on a package/stack compile system for easy distribution of webapps..
Il giorno 06/lug/2011, alle ore 21.03, Cal Leeming [Simplicity Media Ltd] ha scritto: > Hi all, > > After seeing the Facebook video about how their development team > compiles everything into a single binary for easy distribution between > thousands of servers, I totally fell in love with the idea. Although > their approach is to compile PHP into C, the same principle applies. > > The end result will be a single binary which will contain your webapp > + static resources + web server + application server, easily > deployable to many servers, and reduced time spent in managing the > stack (YMMV). Although I'm only going to be focusing on our needs to > begin with, there's no reason this concept couldn't be extended in the > future to include PHP, 32bit, other OS's etc. > > Some features I'm thinking of: > > * CLI based menu to build compile package (ncurses based). Easy to > use. Incorporates all features available in nginx/uwsgi. Comes with > 'basic' config mode (the bare minimal questions asked - for beginners > - which makes it almost impossible to build a broken package) and > 'advanced' mode which lets you change everything (with more risk ofc). > * Support for nginx + uwsgi + python2.6 + python2.7 + debian 64bit. > * Expose some sort of API which lets you query all aspects of services > running within the package (like nginx stats). > * Enable ability for nginx/uwsgi/python to log out to a syslog server > of some kind) > * Ability to obfuscate py code using various techniques. > * Maybe a test-run feature to test your package. > * Maybe some sort of MemoryError detection and reporting of such events. > > I'm probably going to make something like this for companies own > internal use, but wanted to see if anyone else had an interest in > seeing this go open source. > > Cal Hi Cal, you may be interested in Ian Bicking's Silverlining project/idea: http://cloudsilverlining.org/ -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Some thoughts on a package/stack compile system for easy distribution of webapps..
> 2011/7/8 Bjarni Rúnar Einarsson > >> >>http://pagekite.net/wiki/Floss/PyBreeder/ >>https://github.com/pagekite/PyBreeder >> >> It's basically a small tool for combining multiple .py files into one. >> It's trivial I know, but I looked all over and couldn't find anything >> quite >> like it, so I ended up writing my own. Breeder is not very smart and it >> does not handle any binary dependencies, but it might still be capable >> of >> packaging up a working django server in some cases. :-) >> > > Nice script; but i (and also i guess Cal) were thinking more in the terms > of > having a single binary. > > [DISCLAIMER] i still have not tried pybreeder Having a single blob file (the .py file generated by pybreeder) will allow us to "link" it to the uwsgi binary generating another binary with python code embedded. This is pretty easy to accomplish. I will try it in the next few days. -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Limiting the address space of any other binary..?
> Hi Roberto, > > Wonder if you might be able to give me some advice.. > > Is there is a way to limit the address space of any other binary, > without relying on /etc/security/limits.conf?? > > For example, is it possible to do something like this: > > ./magic-here --limit-as=256M -- /usr/sbin/some-legacy-binary-here > > ^^ that would then wrap the binary, enforcing a maximum address space of > 256M. > > As you gave the option --limit-as to uwsgi, which can apply to any > python webapp, I was wondering if it's possible for us to do the same, > but without compiling the original binary into uwsgi. > > Let me know if the above doesn't make any sense lol. > > Cal > you can use the --worker-exec option. This is used to run php-fastcgi (or other software requiring specific environment) under the uWSGI environment uwsgi --limit-as 256 --worker-exec /bin/ls As others have already said to you, remember that limits set by a parent are inherited by all of the children. So running apps via fork+exec or via attach-daemon in uWSGI will set their limit automatically. -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Some thoughts on a package/stack compile system for easy distribution of webapps..
> >> > > I assume _start / _end / _size are references to the address space (within > the binary) where these embedded binaries (in symbol form) are kept?? yes, exactly > > Is there any sort of restrictions on maximum allowed symbol size? (looked > on > Google, but couldn't find anything) it is arch-dependent, so on 32 bit you will be limited to about 4gb (and obviously the whole binary must not be bigger than this). On 64bit the problem is irrilevant. > > >> >> Now you can reference this data with all the uWSGI options taking >> file/path >> >> ex: >> >> uwsgi --socket :3031 --import sym://embedme_py --import >> sym://uwsgidecorators_py >> >> or >> >> uwsgi --ini sym://myfile_ini >> > > Really like the "sym://" protocol reference, that will make CLI usage very > easy. forgot to say that sym:// works in module aliasing too: --pymodule-alias foobar=sym://pippo_py -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Scaling to 30k requests (malcolm box blog)
> >> The stack they have used is quite interesting. Although they are using >> Apache w/ mod_wsgi (which tends to be a lot slower than using nginx with >> uwsgi), they still seem to have got some decent performance out of it. > > > Indeed, it's on the to-do list to try comparing the performance of > Apache/mod_wsgi with nginx/uwsgi, but my gut feel is that the webserver + > WSGI container makes only a marginal difference to the overall site > performance. Of course, I Could Be Wrong. > >> >> After 2 years of continuous development on uWSGI, i can confirm you that performance impact is pratically non-existent (most of the time, when you see extreme favorable benchmark for uWSGI/gunicorn/fapws/flup/.../ against mod_wsgi they are caused by the lack of apache skills of the guy doing the benchmark) Obviously you can tune uWSGI a little bit more that the others, but what is the purpose of gaining 3% on a Hello World ? As a proof, gunicorn and fapws, even if being coded in pure python are perfectly comparable in performance with c-based solutions. "Benchmarkers" should focus on other things (even ease-of-use if they want uWSGI to poorly lose, or on all the other things if they want uWSGI to easily win :P) So, stop wasting time measuring already discovered things :) -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: https / nginx / uwsgi / django problems with authentification
> Hi,
>
> I'm not sure whether I have to change my django configuration or my
> nginx cofiguration.
> (Thus posted to gmane.comp.python.django.user and to
> gmane.comp.web.nginx.english)
>
> I have following setup:
>
> - nginx listening on https
> - most static contents like .css .js images served by nginx
> - everything else forwarded to django
>
> all .html files are in fact templated and should thus be treated by
> django. Additionally I wanted to grant access to the contents onlyy to
> authorized users.
>
>
> djangu urls.py setup
> ---
>
> from django.contrib.auth.decorators import login_required
> from django.views.generic.simple import direct_to_template
>
>
> url(r'^(?P.*\.html)$',
> login_required(direct_to_template),
> ),
>
>
> nginx is configured with
> -
>
> location ~ \.*.html$ {
> uwsgi_pass django;
> uwsgi_param QUERY_STRING $query_string;
> uwsgi_param REQUEST_METHOD $request_method;
> uwsgi_param CONTENT_TYPE $content_type;
> uwsgi_param CONTENT_LENGTH $content_length;
>
> uwsgi_param REQUEST_URI$request_uri;
> uwsgi_param PATH_INFO $document_uri;
> uwsgi_param DOCUMENT_ROOT $document_root;
> uwsgi_param SERVER_PROTOCOL$server_protocol;
>
> uwsgi_param REMOTE_ADDR$remote_addr;
> uwsgi_param REMOTE_PORT$remote_port;
> uwsgi_param SERVER_PORT$server_port;
> uwsgi_param SERVER_NAME$server_name;
> }
>
> uwsgi is called with
> --
> uwsgi -s host:port -H virtual_env_python --pidfile uwsgi.pid \
> --pp ..-w wsgi_module
>
> The problem is, that the first request to
>
> https://mysite:myport/index.html
>
> is detected as non authenticated access. (that's what I want)
> and thus django tries to redirect to redirected to the authentification
> page (that's also what I want)
> which should be
>
> Django should redirect to
> https://mysite:myport/accounts/login/?next=/index.html
>
> Unfortunately it redirects to
> http://mysite:myport/accounts/login/?next=/index.html
>
>
> Therefore I get the error message
> "400 Bad Request The plain HTTP request was sent to HTTPS port"
>
> Is there any variable that I can use to tell django, that the protocol
> is https and not http for the login pages
>
> Ideally I would like to have something like an nginx parameter being
> passed, such that django knows whether the request is coming from an
> nginx https server ( all redirects should be https:host:port )
> or from an nginx http server.
>
>
> Does anyone have a similiar setup or has some ideas?
>
You can force the protocol using the HTTPS variable (standard, but not
enabled in nginx) or you can force the protocol to htts using the
UWSGI_SCHEME variable
http://projects.unbit.it/uwsgi/wiki/uWSGIVars
--
Roberto De Ioris
http://unbit.it
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Read write config from a file. How?
On Apr 3, 4:31 am, hollando wrote: > Yes. Thanks for your replies. > > I have one more question. I want to put all my configures into one > file and pass the file name by command line. > My django is deployed as in uwsgi, so I pass the command line by -- > pyargv '-c /etc/myconfig.ini'. > In django, how can I retrieve this command line file name? If I set it > by os.enviroment, how to retrieve it? > Thanks. > Hi, why not using the embedded uWSGI config parser ? You can put all the uWSGI option in a ini file with your custom options: [uwsgi] ; uwsgi related options socket = :3031 module = django.core.handlers.wsgi:WSGIHandler() master = 1 ; and here your custom options my_funny_option = pluto foo = bar The in your code you can access all the options with the uwsgi.opt dictionary: import uwsgi uwsgi.opt['socket'] uwsgi.opt['my_funny_option'] -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: can not download file from my site ( django + uwsgi )
> Hi all, > > If the site is started by './manager runserver', I can download file from > the site successfully. But the strange is that I can not download file > from > it when it deployed using nginx and uwsgi. It just return part (25KB) of > the whole file(1MB). > does anyone know how to fix this? > You are referring to static files served by nginx or dynamic pages served by uWSGI ? or both ? -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: can not download file from my site ( django + uwsgi )
Il giorno 12/apr/2011, alle ore 04.05, Lei Zhang ha scritto: > the static file is returned by nginx, and it is works well. > But the file returned by dynamic pages does't works very well. You have a pretty standard configuration. Check the uWSGI logs (they report the response size) to see where is the problem -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Problem with uwsgi
> Hi all, > > We are running our website with nginx and uwsgi at the moment. It is a > django 1.7.4 application and it has been running perfectly for a couple of > months. Now however we are getting some errors that I can't really > explain. > > The errors always appear after uwsgi has done a respawn of a process. Then > we can get 4-5 errors with very strange behavior. Things like "dict has no > method 'startswith'". They aren't errors in the code because the code will > run perfectly before and after these errors. We also used to get these > when > we deployed a new version of the website and then restarted uwsgi (by > sending a kill signal to the main process). > > Has anyone had the same problems and if so, does anyone know how to remedy > it? We are getting a lot of false error mails and it's starting to get > annoying. Also I don't know how our customers are affected when this > happens, but it's probably not good. > > Regards, > > Andréas > Hi, ensure you are running a stable uWSGI version 1.4.x or 2.x, older versions have serious bugs. Eventually paste your uWSGI configuration -- Roberto De Ioris http://unbit.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+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/acdaac41963c810109952aaf8e18e3c3.squirrel%40manage.unbit.it. For more options, visit https://groups.google.com/d/optout.
Re: Graceful Reloading for Schema Changes - UWSGI - Gunicorn?
> > > Hello Djangonats, > > How do you reload Django script changes with UWSGI? I know `touch-reload > <http://uwsgi-docs.readthedocs.org/en/latest/Options.html#touch-reload>` > exists with UWSGI however I was looking more into what uwsgi does when the > schema(s) in the models change? How do you handle database changes without > affecting or rebooting the server? Rebooting UWSGI does not sound like a > good idea. > > A Load Balancer (HAProxy) ? > > *More Questions* > > Does something like that exist in Gunicorn? > > Regards, > > Shapath. > > The topic is huge and there are dozens of approaches, but basically every WSGI server requires a new (updated) process address space after code change (included schema changes if the model is already loaded into memory). So, even if it may look "extreme", reloading the whole WSGI server is the only reliable solution (in fact used by everyone). If you are scared about potential downtimes check this article: http://uwsgi-docs.readthedocs.org/en/latest/articles/TheArtOfGracefulReloading.html But take in account that 99% of the times/cases a simple graceful reload is more than enough. -- Roberto De Ioris http://unbit.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+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/c444f30b5e1e079782ec3d8b21caaf5b.squirrel%40manage.unbit.it. For more options, visit https://groups.google.com/d/optout.
Re: Flup vs Guicorn vs uWsgi on Nginx
> Hi Folks, > We are in our initial deployment stage, and have decided to deploy > django(1.6.X) on Nginx, and trying to decide which WSGI server to use. > I am positive all have something to offer and may not be fair just to > throw out "which one to use", but I was hoping to get some guidance on the > following items Unfortunately no-one can give you a satisfing answer, because lot of things come into play. I will focus on uWSGI and gunicorn as flup is basically a dead project (afaik) > > 0. Handle high concurrent requests both uWSGI and gunicorn support multiprocessing. As you are using django i will not suggest you using async approaches (like gevent) even if both support them. uWSGI has strong multithreading support too, and gunicorn is working on it (probably should be ready in the next release). If you are app is not cpu-bound, multiple threads are a good solution in python (i bet you will find tons of posts regarding the infamous GIL, but you can ignore them, as the GIL is released during I/O operations) In both threads and multiprocessing, do not choose their number using silly math (like cpu * 2). Start with a low-number (like 4) and constantly monitor your app to see if you need to raise or decrease them. New-relic could be a great toy for it. > 1. Performance / less transnational overhead, this is nothing related to WSGI servers, your app will be the bottleneck. Always. > 2. Compatible with django/Nginx, in a sense easy configuration both have now pretty decent documentation for newbies, but gunicorn is way simpler from an architectural point of view, so probably you will find easier to start with it. On the other side uWSGI is more sysadmin-oriented so it has dozens of features for app monitoring and to manage and detect critical conditions. > 3. Large number of users with mod_wsgi they are the three most used servers, so i would not waste time on this point. There is a lot of documentation about all of them. And remember you can proxy an apache+mod_wsgi in embedded mode behind nginx too. Lot of users prefer this approach. Apache can be a good application server. (disclaimer: i am the uWSGI lead developer) -- Roberto De Ioris http://unbit.it -- 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+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/eef4aa58de830c3e68a4a0eeaf7bc66f.squirrel%40manage.unbit.it. For more options, visit https://groups.google.com/d/optout.
Re: Mapping SSL certificates to django users
> Hi tomaso > > Did you maybe found the solution? We have the same issue. > > Best regards > Mitja Both apache and nginx can set the HTTPS_DN/other_names_as_well variable to the distinguished name of the x509 peer. Just add SSLOptions +StdEnvVars I use it as a decorator to protect some view: https://github.com/unbit/uwsgi.it/blob/master/uwsgi_it_api/views.py#L19 this works in mod_wsgi and variables/cgi based proxies like FastCGI,SCGI or uwsgi -- Roberto De Ioris http://unbit.it -- 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+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/8df707a6291a2e0f9d12db9b3d40e9b6.squirrel%40manage.unbit.it. For more options, visit https://groups.google.com/groups/opt_out.
