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