Понимаю. Но не в ущерб же современному названию…
Что бы можно было пользоваться, нужна агрегированная статистика по регионам/НП,
и раскраска цветом, где сколько адресов сопоставлено.
Ну и разделение на страницы выкинуть. Найти в Мск какую-либо улицу просто невозможно.
С раскраской я подумаю, суммарная статистика в планах https://github.com/Scondo/fiosm/issues/4
Технически там все понятно, но пока обсчет такой статистики вешает рендер. Ищу пути обхода в частности https://github.com/Scondo/fiosm/issues/6
Увы, но постраничное разделения явилось вынужденной мерой - данные обрезались при рендере. Учимся половинному делению…
Так, чуваки и чувихи, какие новости на Плюке?
Нельзя ли опубликовать наконец какой процент адресов из ФИАС есть в осм, по России в целом и в разрезе по областям?
К сожалению проблемы производительности посредством таймаутов переросли в проблемы с доступом.
Причем сейчас я не могу установить причину проблем с производительностью, т.к. они не воспроизводятся на отладочной машине, где ведется разработка.
Возможно это что-то с базой, в этом я сейчас пытаюсь разобраться, но, увы, очень медленно, поскольку “горячий” сезон на работе пока не кончился.
Расчет “рекурсивной” статистики - это та же проблема производительности, только в кубе.
К ней ищется параллельное решение в виде предварительного обсчета статистики.
В худшем случае сяду в режиме рабочего дня на майские. Обещать ничего не могу, но работа идет… или по крайней мере ползет.
Как там работа над проектом? Майские уже 
Починил пару глюков, нарисовал новую мордочку с тегом meter.
Надо: заменить прогрев кеша статистики на отстройку, увеличить число потоков сервера. После этого сайт должен стать рабочим.
Рекурсивная статистика постоянно имелась ввиду в рамках прибивания багов и, вероятно, как только будет прогрев кеша нарисую рекурсивные цифры. Т.е. не сколько районов подчиненных МО найдено в МО, а сколько всего районов, улиц (и отдельно - домов) найдено в МО.
В очереди: сделать страничку по списку сопоставленных домов.
А можешь напомнить, почему ты не хочешь просто сгенерить статические html-ки? Тогда все вообще должно залетать…
Сейчас: потому что на выбранной мной архитектуре единственный понятный мне способ это сделать - это пройтись по сайту “архиватором интернета”.
А в целом потому, что я все-таки надеюсь на то, что когда-нибудь перейду на работу в дифф-режиме, когда статистика будет пересчитываться только для обновленных данных.
Scondo, а что за странная архитектура, при которой сайт ложится от трёх пользователей? Подозреваю, этого сложно достичь даже если всё хранить в текстовых файлах и при каждом запросе их парсить целиком.
Мне тоже интересно. Если готовые данные для выдачи хранятся в БД, можно выводить их вполне быстро, этим занимаются миллионы сайтов.
Возможно, при первом обращении в базе ничего ещё нет и она лихорадочно начинает заполняться…
Ничего такого в коде не вижу, но оно, возможно, хорошо спрятано.
Наверное, когда появится время, надо добавить кучу отладочного вывода в логи - тогда станет хотя бы понятно, на чем висит.
Производительность Python-приложений, на мой неопытный взгляд, вообще очень зависит от настроек сервера и наличия на нём всяких наворотов/служб/хитроумных настроек… Я ставил себе только готовый Rhodecode - при самой простой конфигурации висело от 5 пользователей в локальной сети. После плясок с бубном по инструкциям и активации наворотов (mod_wsgi и (в случае Rhodecode) серверов+настроек Сelery, RabbitMQ) всё залетало…
Хранение в БД самого факта сопоставления.
Соответственно на каждый запрос идет куча селектов по джойнам на немаленькие таблички.
Собственно эту проблему и был призван решать кеш статистики (отдельная табличка хранящая только цифры для каждого объекта), но именно с ним и лезут проблемы.
Если БД на постгре и осмелитесь подпустить к ней постороннего человека, помогу, чем смогу.
Если я правильно понял суть, то как-то совсем не хорошо. На каждый запрос пользователя должен быть один сложный селект, тогда, при должном уходе за базой, джойны и размеры таблиц будут иметь уже не столь большое значение.
А самое страшное - это если по одному селекту на каждую строчку таблицы 
Индексы-то есть? :3
Когда есть рабочий кеш - так и происходит. Проблема в том, чтобы сделать его рабочим.
Расчет же сделан в виде множества селектов в основном ради повторного использования кода.
Куда ж без них… хотя, вохможно, надо лишний раз прикинуть кого добавить/убавить.
Вот и предлагаю свою безвозмездную помощь в решении этой проблемы. Люди жаждут рабочего сервиса.
Может стоит пересмотреть позицию, и возможно решить данный вопрос вспомогательными таблицами не теряя при этом универсальности кода? Что называется, пальцем в небо, без знания иерархии структуры и конкретных примеров советы могут и ухудшить ситуацию.
В общем, мое дело предложить, ну а ваше, видимо, отказаться.
Так, ботов прогнал, статистику отстроил.
Сейчас сервер строит страницу за несколько секунд, но просьба be gentle, потому что я пока застрял с потокобезопасностью и как следствие все сидят в одном потоке.
список домиков будет со дня на день, также вопрос производительности остается открытым, я посмотрю что можно еще сделать.
Если до конца недели проблем не вылезет - попробуем рекурсивку, то чего все ждут.