As Vijay said, most of the performance of a web app (in any framework) is database access. With django, you can use the Django Debug Toolbar <https://github.com/django-debug-toolbar/django-debug-toolbar#django-debug-toolbar> or the db.connection.queries <https://docs.djangoproject.com/en/1.7/faq/models/#how-can-i-see-the-raw-sql-queries-django-is-running> object to find out where those queries are being made and then use the select-related <https://docs.djangoproject.com/en/1.7/ref/models/querysets/#select-related> and prefetch-related <https://docs.djangoproject.com/en/1.7/ref/models/querysets/#prefetch-related> features of the ORM to reduce them to a minimum.
It is also worth noting that for many applications, the speed at which a programmer is able to work effectively matters more for the success of the project than the speed of the language. Of course, the two aren't completely unrelated; If your unit test suite runs slowly, that will slow down your development workflow. If you have a need to do high-performance analysis of really large scale data sets, python has a variety of tools like blaze <http://continuum.io/blog/blaze-datasets>, pandas <http://pandas.pydata.org/>, and numba <http://numba.pydata.org/> and is pretty widely used in scientific computing for this reason. On Tue, Feb 24, 2015 at 5:59 PM, Vijay Khemlani <[email protected]> wrote: > It's true that the Global Interpreter Lock will prevent threads from a > single process from running concurrently, but your server (uWSGI, gunicorn, > etc) will spawn multiple process that don't conflict with the GIL. > > Also, if you need some form of multiprocessing celery is a good choice, > and one that also doesn't collide with the GIL as it is a different process. > > Finally, web apps are mostly limited by I/O (database access), so the > actual stack used usually is not that important unless you are scaling a > lot (StackOverflow-level "a lot"). > > I've worked with both Django and ASP.NET MVC (although an older version) > and even though ASP.NET MVC is amazing in the level of the IDE > (VisualStudio) and query language (Entity Framework / LINQ) it's still a > little cumbersome for my taste (and I also prefer Linux enviroments...) > > On Tue, Feb 24, 2015 at 8:52 PM, Alex Mandel <[email protected]> > wrote: > >> On 02/24/2015 03:30 PM, Benj wrote: >> > Hi, >> > i'm going to invest lots of time and energy in various web projects >> (mostly >> > community web sites), and want to pick up a language / framework and >> invest >> > heavily on it. >> > I've spent a lot of time evaluating the various options, and narrowed my >> > choice to 2 stacks: C sharp asp.net MVC or Python / Django. >> > >> > I'm more attracted to Python / Django combo, because of the Python >> > language, and high level framework Django. I really want to use these. >> > My only concern is speed. I read that Python can't run concurrent >> tasks, is >> > this true ? So a multi-processor with hyperthreads won't benefit the >> stack >> > and even slow it down ? >> > I have no clue how this translates in reality, but should I expect >> > noticable performance difference on a same server, shall I use Python / >> > Django than if I had C Sharp Asp.net ? >> > I don't want to invest lots of time and efforts only to discover in the >> end >> > that the site is slow. >> > You that have real world experiences with running sites, what are your >> > conclusions ? >> > >> > >> > I expect sites to be medium traffic: could be handled by a good >> dedicated >> > server or average cloud ressources. >> > >> > Benj >> > >> >> Use a good WSGI like uwsgi or gunicorn and don't use sqlite as your db. >> Those WSGI containers are threaded. Don't confuse running python >> directly which is different (and there are ways to use multicores even >> then). >> >> Plenty of examples of big websites running django out there. >> >> http://blog.disqus.com/post/62187806135/scaling-django-to-8-billion-page-views >> >> Enjoy, >> Alex >> >> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> 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/54ED0EB9.2020505%40wildintellect.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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/CALn3ei0T%2B7HokGppre4z7JhPc6P1%3DkLW%2BJ2o1vAtG0v5DD8MtA%40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CALn3ei0T%2B7HokGppre4z7JhPc6P1%3DkLW%2BJ2o1vAtG0v5DD8MtA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CA%2By5TLYOihmvq1hUqETnWwY4vBaBFmttsm_ZkKoUzctFFg7JVQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
