ding 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 gra
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
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 g
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
&q
d. 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, se
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
icorn
>
> 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 messag
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 (
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 autom
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 ema
f 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
tp =
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 I
ks 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
t/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 Goog
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
omq (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 Grou
e 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/gr
aw-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
ginx 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 h
se 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"
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,
--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 rec
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 po
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
ng 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" <robe...@unbit.it> wrote:
>>> Roberto,
>>
>>> it is uWSGI, but can you explain a bit more w
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
robably 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
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 Ior
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
djang
s 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 t
ns:
[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.o
31 matches
Mail list logo