> I think this is because of wl_map_info needs long time to process the map.
I agree, this is probably the problem. It takes so long because it needs to load all of Widelands graphics assets into memory and on a cold cache this takes probably too long. Not much we can do about this except of changing the tool into a python library that is always loaded in the website and stays in memory.
> Pickling: The pickled object is already stored in the database. The model for this is 'NoticeQueueBatch'
This I find interesting. I would expect that the objects in the database to be always stored using djangos ORM, i.e. in proper tables. Instead here they are pickled and saved as a string. I wonder what informed this design - it seems more brittle to me. But it is probably without consequence for us either way.
> Are you fine with running emit_notices hourly?
Yes, sure. There is also /etc/cron.20minutesly/ to run it 3 times per hour. I would trigger the script there.
> I think this is because of wl_map_info needs long time to process the map.
I agree, this is probably the problem. It takes so long because it needs to load all of Widelands graphics assets into memory and on a cold cache this takes probably too long. Not much we can do about this except of changing the tool into a python library that is always loaded in the website and stays in memory.
> Pickling: The pickled object is already stored in the database. The model for this is 'NoticeQueueBatch'
This I find interesting. I would expect that the objects in the database to be always stored using djangos ORM, i.e. in proper tables. Instead here they are pickled and saved as a string. I wonder what informed this design - it seems more brittle to me. But it is probably without consequence for us either way.
> Are you fine with running emit_notices hourly?
Yes, sure. There is also /etc/cron. 20minutesly/ to run it 3 times per hour. I would trigger the script there.