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