Re: How to interpret the performance difference: Tornado vs Django
On Mon, 2009-10-05 at 22:16 -0700, ihomest...@gmail.com wrote: > I read this doc about the performance comparison between Tornado and > Django: http://www.tornadoweb.org/documentation > > I am quite new to both django and tornado (just heard about it). To me > there are a few confusing points about the conclusion that "Tornado > consistently had 4X the throughput of the next fastest framework, and > even a single standalone Tornado frontend got 33% more throughput even > though it only used one of the four cores" Maybe the document could > add more comments about how the experiment is setup. > > The context of this statement is that Tornado runs with 4 frontends on > a 4 core machine. My question is "Could django apps take advantage of > 4 cores?" Is the 4X performance difference due to the setup or is it > due to the reason that Tornado could make a better use of a 4 core > machine? > > Any thoughts? > Thanks. > Once in a while, someone (me included with uwsgi) spit out a new outstanding deploy technology forgetting that 99.999% of bottlenecks are on the apps and not on the webservers. Putting all the efforts on speed is now completely useless, all of this tecnology are heavily based on optimization done by the kernel (epoll, kqueue, sendfile, vector i/o, varouis aio technics), this softwares put them together (mostly in the same manner) and build their copy of an "ultrafast" asynchronous system. Please, stop using "asynchronous" or "evented" as performance mesurement, as Graham already said, an evented environment need that all the players are async/evented. And rarely this happen. Django (and wsgi by the current design) are not asynchronous, so do not spend more time trying to gather more then a 1% performance improvement, and choose the environment looking at first at its robustness and its features. And please,please (and please) stop doing benchmark with an hello world. Even the most under-talented programmer can optimize his work for this kind of app ;) -- Roberto De Ioris http://unbit.it JID: robe...@jabber.unbit.it --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django performance vs others
> Thank you for sharing that! To me it’s very interesting to see no PyPy > advantage on other tests – PyPy claims otherwise: http://speed.pypy.org/ – > but that could be explained by assuming PyPy tests are hand chosen to show > the advantage. PyPy is extremely faster when it can abuse its JIT, this rarely happens on 'classic' webapps where the biggest part of the response cycle is spent waiting for dbs (or external services in general). This is the same reason why benchmarking application servers is generally useless :) -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django performance vs others
Il giorno 05/ott/2012, alle ore 15:08, Moonlight ha scritto: > Roberto, is there a way run uwsgi on pypy? Yes http://projects.unbit.it/uwsgi/wiki/PyPy but there is no particular advantage (and you will lose some advanced features like full threading support and so on...) currently it is no more than a test toy for the pypy guys and their cpyext implementation > I think the article shows best of two words: cpython and pypy and uwsgi > on cpython, while gunicorn on pypy. I do not believe there were attempt to > compare web servers... > oh yes, for sure, i was only giving an example on mis-readed benchmarks, and giving an explanation on why PyPy is (still) not particular 'powerful' in classic web-apps scenario -- Roberto De Ioris http://unbit.it JID: robe...@jabber.unbit.it -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Feature: Support Server-Sent Events
> On Sat, May 30, 2015 at 4:19 PM, Florian Apolloner > wrote: >> ie how would it use Django's current featureset which is basically >> blocking >> everywhere… > > On Sat, May 30, 2015 at 4:40 PM, Emil Stenström wrote: >> The separate process would have none of Django's features, it would just >> be >> a way to send messages to connected clients. > > > take a look on how it's done with uWSGI: [1]. Basically, the http > request arrives to a Django view in the normal way; then it generates > a response with a custom header, which the uWSGI system recognizes > (much like X-Sendfile), and routes the request to a gevent-based wsgi > app that uses an sse package (probably [2]) to keep the connection. > > in the given example, there's no further communication between Django > and the SSE process, but the author then comments it could be done > either with the uWSGI caching framework, or via Redis. > > If I were to implement this today (and in fact, i have an application > that might need this in the near future), i would use basically this > scheme (as I'm using uWSGI for all my deployments), and Redis. The > SSE process would keep in Redis the current set of connected users, > and the Django process would send messages via Redis to the SSE > process. Of course, not only 'broadcast' messages to every connected > user, but user-specific messages too. > > I don't see how would i do it for a reusable app, since it looks most > of the code would run 'outside' Django. Doing it for the Django core > seems even more problematic, since it would also have to be much more > flexible in requirements, both for the WSGI container (does mod_wsgi > support async python code? i guess gunicorn does), and also for the > communications between the 'main' Django views and the SSE part. > (probably the cache API would be appropriate) > > I obviously agree, but take in account that this uWSGI plugin simplified the steps a lot: https://github.com/unbit/uwsgi-sse-offload -- Roberto De Ioris http://unbit.com -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f32688a1ec922e02ca91219c2d608412.squirrel%40manage.unbit.it. For more options, visit https://groups.google.com/d/optout.
Re: Feature: Support Server-Sent Events
> On Sun, May 31, 2015 at 1:23 AM, Roberto De Ioris > wrote: >> I obviously agree, but take in account that this uWSGI plugin simplified >> the steps a lot: >> >> https://github.com/unbit/uwsgi-sse-offload > > > nice. it certainly looks cleaner than having an external gevent > process. does it support sending messages to a specific subscriber > (or subset of subscribers)? > > maybe the easiest way would be to set some variable either in the > router or in the app view function and use it as part of the redis > pubsub channel name. > > -- > Javier > the channel name can be specified via variables, so it should be pretty versatile from this point of view. The plugin is pretty tiny so if you have ideas to improve it, feel free to open a github issue -- Roberto De Ioris http://unbit.com -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0aca01bc3ace1228b4a160300914b485.squirrel%40manage.unbit.it. For more options, visit https://groups.google.com/d/optout.
Re: uWSGI documentation
Il giorno 02/apr/2011, alle ore 16.44, Łukasz Rekucki ha scritto: > On 2 April 2011 13:23, James Pic wrote: >> Hello everybody, >> >> Do you think uWSGI deserves a place in the official django documentation ? >> >> I think it should because it's easier, safer, faster and more secure >> than flup or mod_wsgi. Also, it made my sysadmin life really easy and >> that's something cool to share with the community. >> >> In this case, please consider the attached draft >> (django/docs/howto/deployment/uwsgi.txt): it's not perfect and >> probably not commitable as-is, but I am ready to listen to feedback >> and improve it. Otherwise it'll just make another blog post. > > +1. More docs didn't hurt anybody. At least while there is someone to > maintain them. > >> >> What do you think ? >> > > My first impression is that you're focusing too much on all those > switches. That section got me totally lost. That should be simplified. > Also, do I really need to type all that stuff? I probably won't be > doing that on production, so showing how to place it in a > configuration file would be better. > > I would also drop the whole "advantages" section. The purpose of the > page is to show how to deploy a Django app on uWSGI, not compare it > against other solutions. You also mention some features, but never > show how to enable/use them which is confusing. > > PS. Do you think having a `runuwsgi` command similar to `runfcgi` > would be useful ? > > I have made a tiny runuwsgi implementation: http://projects.unbit.it/uwsgi/browser/contrib/runuwsgi.py it tries to autoload plugins and spawn the embedded http router/proxy on a default port. You can specify the socket=ADDR option to disable the http part and bind the server on a uwsgi socket (for directly pointing your webserver to it) It run multithreaded (8 threads) but i suppose that this could be another configurable option. It requires a 0.9.7.2 uWSGI version (released in a couple of days) or the current mercurial tip. I hope it can be useful -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: uWSGI documentation
> Hi, > How uwsgi is more secure than FastCGI ? I think he is referring to the various included jailing systems (chroot, linux namespaces, posix capabilities...) because if we are talking about protocols there are no really differences between uwsgi and FastCGI, both are unsecure by-design :) > I believe that running manage.py for production deployments is "not > way to go", as it has been noted by django devs previously. > What purpose would runuwsgi command serve ? I see it as a way to easily use the embedded uwsgi module/api before going into production. If a user want to use something like the uWSGI timer/cron system http://projects.unbit.it/uwsgi/wiki/DjangoTimers http://projects.unbit.it/uwsgi/wiki/CronInterface it can just start coding without passing for all the stack configuration. -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: uWSGI documentation
> That said i'd love to *not* have to put a 3 liners module in my > project directory anymore. A runuwsgi command might not be the only > way to solve this need. > Remember that you do not need those file anymore: [uwsgi] env = DJANGO_SETTING_MODULE=mysite.settings chdir = module = django.core.handlers.wsgi:WSGIHandler() ... ... Or you can do magic with placeholder like this: [uwsgi] my_django_app = mysite env = DJANGO_SETTING_MODULE=%(my_django_app).settings chdir = /apps/%(my_django_app) module = django.core.handlers.wsgi:WSGIHandler() (obviously this rules apply to xml,yaml,ldap,command line and so on...) > uWSGI_ supports configuration through: > > * command line switches > * ini files > * xml files yaml is supported too and you should mention environment variables, they are used a lot on already available *BSD init scripts Probably i would add a section about massive hosting of applications using the Emperor (The Emperor doc is probably the only good one of all the uWSGI project as it is not written by me :) ) http://projects.unbit.it/uwsgi/wiki/Emperor One of the most-loved (by me too) feature of mod_wsgi is its virtualhosting capability tied-in with apache. uWSGI in the past forced you to manually manage a instance for every app or use the PITA (but funny and hacky) multiple-interpreters-way. The Emperor solves this problem elegantly and with a lot of attention about clouding/hosting platforms. > > Starting the server > --- > > Starting an uWSGI_ server is the role of the system administrator, > like > starting the Web server. It is *not* the role of the Web server to > start the > uWSGI_ server. This means: > > * the uWSGI_ server can be restarted or reloaded independently from > the Web > server, > * it is the role of the system administrator to make uWSGI_ to start > on boot > or reboot: either through tools like supervisor or daemontools, > either > directly at init level in a file like /etc/rc.local or /etc/conf.d/ > local Nothing to say against this, but Cherokee (as an example) manages the uWSGI processes itself (it is an exception to the rule, i do not know if it is worth mentioning it). > > Patching the daemon > --- > > One of the great advantages of uWSGI_ is its ability to gradually > restart each > worker without loosing any request. For example, uWSGI_ can be > signaled that > worker should reload the code after handling their current request (if > any):: > > kill -HUP `cat /tmp/project-master.pid` You can gracefully reload (in 0.9.7 tree) simply touching a file with the --touch-reload = option and (probably more important) you can reload from the app itself using uwsgi.reload() > > > Tipical gotchas: > > * if the socket is a file: the Web server process should have read, > write and > execute permissions on the socket file you should mention the --chmod-socket option here > * uWSGI_ won't remove the socket and pidfile when it is interrupted, here --vacuum option should be reported, but i will put enphasis on the inhability to remove socket/pidfile if you "kill -9" the uWSGI stack If you have some doubt please ask me or the official uWSGI mailing-list i know that uWSGI official docs are really bad and not synced with the current code :P -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: uWSGI documentation
> To be blunt, you are actually asking a lot for them to host detailed > documentation on uWSGI integration on the Django site for every possible > way > it can be setup. I haven't even managed to get much more than minimal > setup > instructions for mod_wsgi into the official Django documentation. > > I have asked anything, other users spawned this thread, and as the main uWSGI author i am doing suggestions/corrections. -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: uWSGI documentation
> Thanks a lot Roberto and Mikhail for your feedback. > > This update includes the changes you requested, as well as more links > to uWSGI wiki: http://piratepad.net/DISxvZLCdG > > Is there any other action to take ? > > Seems very good to me, the only thing that i would really change is --home to --chdir as --home is used for virtualenv. In my experience using --chdir with django causes less headache to users. Probaly you could add the same example written with a ini file too, only to show users that they not need to write such huge command lines :) Another (maybe important) note to add is that uWSGI does not run on Windows -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: WSGIRequest._stream.read() blocking
Il giorno 14/giu/2011, alle ore 14.54, Jonathan Slenders ha scritto: > Hi all, > > > Using WSGI on production environment: > > In django.core.handlers.wsgi.py is a clear notice that wsgi.input, > which can be an instance of socket._fileobject will hang when reading > past the available count. > > In my case, wsgi.input appears to be of the type 'file', so the > following test fails, and the input is not wrapped in a LimitedStream. > > --- > wsgi.input.__class__ > > > wsgi.input.__class__.__name__ > file > > wsgi.input > > > socket._fileobject > > > type(socket._fileobject) > > > isinstance(self.environ['wsgi.input'], socket._fileobject) > False > > --- > > When I want to read request.raw_post_data, everything hangs. > > It may be worth noting that the CONTENT_LENGTH was zero. (It is sentry > in my case who wants to log another error, tries to access > raw_post_data, and blocks instead of returning a proper 500 error > page.) > This is probably a bug in Django, but I'm not sure where exactly. Even if the read() and read(-1) are controversial, the popular consensus is on having the WSGI server to gracefully manages it. uWSGI 0.9.8 uses the same approach of mod_wsgi (it creates a custom object for wsgi.input), so you are using a old uWSGI version or i did not understand your question :) > > By the way, it would also be great if anybody knows how to use pdb > statements, while running uwsgi on the console. Look here, http://lists.unbit.it/pipermail/uwsgi/2011-April/001769.html the same is valid for pratically all of the other WSGI daemons out there. -- Roberto De Ioris http://unbit.it -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: runfcgi umask unusable without daemonize=false.. why?
Il giorno 09/set/2011, alle ore 16:05, Cal Leeming [Simplicity Media Ltd] ha scritto: > Hi, > > Is there any reason why umask is unusable without daemonize=false? > > This means I can't manage processes within supervisorctl (when having to use > fastcgi due to client not being able to have uwsgi). Not related to your specific question, but remember that uWSGI can natively speaks fastcgi (both in static and dynamic way) static config: uwsgi --fastcgi-socket ... dynamic (apache passing the socket as fd 0) uwsgi --protocol=fastcgi ... -- Roberto De Ioris http://unbit.it JID: robe...@jabber.unbit.it -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
