Ok, so having excluded SQLite and the static served files, I'd like to test if the server matters. What would be a minimum Apache install and config to run Django locally (on Windows)?
On Nov 1, 7:30 pm, Lars Ruoff <lars.ru...@gmail.com> wrote: > Ok, thanks all, > > So following Bill's advice, i did:>python manage.py shell > >>> import game.models > >>> list(game.models.Location.objects.filter( \ > > ... x__gte=34, \ > ... x__lte=46, \ > ... y__gte=24, \ > ... y__lte=36)) > > ...and the result showed up instantly! > So it seems DB is not the issue. > Will do other testing... > > On Nov 1, 4:18 pm, Bill Freeman <ke1g...@gmail.com> wrote: > > > My experience with Django debug toolbar is that it makes things > > slow all by itself. > > > I have done a couple of apps that use the equivalent query, using > > PostgreSQL, > > without noticing a performance issue, with everything running on a Linux > > server. > > > 1. Have you tried timing the query by hand? That is, run the manage.py > > shell, > > import your model, and type a sample version of the query, wrapped in a > > list() > > operation to force the query to evaluate right away. If it's slow, > > then you problem > > is at least mostly in your DB/query choice. > > > 2. Is the machine in question tight on memory? That could make things > > slower > > that it would be on a production instance. > > > 3. You might look at the "range" field lookup instead of pairs of > > gte, lte. I doubt > > that it makes a performance difference, and I don't know if SQLite supports > > BETWEEN, but it's easy to try. > > > 4. You show x and y as integers, but if that was just by way of example, and > > they are really some complex (non-scalar) data type, the comparisons may not > > be cheap on the database. > > > Bill > > > On Mon, Nov 1, 2010 at 8:13 AM, Javier Guerra Giraldez > > > <jav...@guerrag.com> wrote: > > > On Mon, Nov 1, 2010 at 5:55 AM, Cal Leeming [Simplicity Media Ltd] > > > <cal.leem...@simplicitymedialtd.co.uk> wrote: > > >> 9 out of 10 times, the bottleneck is usually the database > > > > true, but 8.7 of those 9 are about how the database is used, and not > > > about the engine choice. simply changing SQLite won't improve > > > significantly the one-user case. > > > > the trick is: 1) get as few db queries as possible for each page. 2) > > > use appropriate indices for those queries > > > > but first of all, you have to identify if it is really the DB where > > > you're spending time. the easiest way to be sure is to install > > > django_debug_toolbar app, it's great to tell you exactly what's going > > > on with the time and the DB accesses. > > > > -- > > > Javier > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Django users" group. > > > To post to this group, send email to django-us...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > django-users+unsubscr...@googlegroups.com. > > > For more options, visit this group > > > athttp://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
