On Tue, Oct 16, 2012 at 11:15 AM, Guido Notari <[email protected]> wrote: > The heavy cpu use is most likely related not to the framework itself, but to > the use you make of it. > Don't throw away your time and money trying to switch, Django is good enough. > You should really indulge in some form of profiling: if you haven't yet, do > install django_debug_toolbar and explore what and how many database queries > are you making for each view. > You're speaking of "high cpu use" but, unless your web application is cpu > bound -- very very strange --, most of the work is probably done at the DB > level. Can you verify that? > > What database are you using? If using Postgres, try to log long queries > (log_min_duration_statement option) and try to optimize that. > Caching, as Roberto said, is another obvious target.
I agree on several of Guido's observations: - uWSGI has _very_ little overhead. most (all?) of the CPU usage you see are coming from your app - Django is good enough for the vast majority of websites out there. as anything out there it's easily misused. - CPU-bound web apps are rare. the first bottleneck you'll usually hit is the database. django_debug_toolbar permanently enabled on development allows you to be aware of the dreaded "N+1 queries" issue. log_min_duration_statement for Postgres (and slow-log on MySQL) is great to pinpoint non-optimal queries. - after optimizing database access, a good cache strategy saves almost all remaining performance issues. but.... there's one thing i don't see addressed: - DB issues would show spikes on either HD waittimes or CPU/RAM consumption by the database process, not the uWSGI process. .... unless you're using SQLite? -- Javier _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
