Re: 2D map application: performance and design question

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-users@googlegroups.com.
> > > To unsubscribe from this group, send email to django-users+unsubscribe@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-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.