Комментарии 36
80k обращений в сутки и это highload?
80к в сутки распределены неравномерно, пик нагрузки приходится на отдельные часы. На тот момент это было для нас достаточно высоконагруженной системой, генерирующей в пик несколько сотен обращений в секунду, в будущем нагрузка будет только возрастать. Кроме того, на графике зафиксированы не сами запросы или загрузки страницы, а количество сформированных платежных документов.
Даже если 80к в час — это чуть больше 20 запросов в секунду, это совсем мало.Запросов было гораздо больше в секунду. Стоит учитывать неравномерное распределение по времени, к тому же здесь речь идет про сформированные платежные документы. Физически запросов было на порядок больше — кроме формирования платежного документа пользователь выполнял много других запросов: просмотр размера оплаты по услугам, внесение показаний прибора учета и так далее…
Делать партиционирование на десятках миллионов — уже возникают вопросы.
Вопросы партиционирования в первую очередь были связаны с возможностью независимо обновлять данные районов и во вторую очередь с тем, что время выполнения запроса к БД PostgreSQL (актуальной на тот момент версии) существенно выше при десятке миллионов записей в таблице по сравнению с сотней тысяч записей в таблице.
Как я понял это для формирования платежных документов. Тоже вопрос — зачем формировать платежные документы при заходе на сайт? Можно же их заранее нагенерить. Закончился отчетный период — запустили джобу и все.
Да, этот вариант был бы хорошим решением, кроме потребности в дисковой памяти, нужно учитывать, что запрос на формирование платежного документа может быть осуществлен за любой месяц в пределах 3-х лет.
Ну и если геренируется много запросов, смотрели ли в сторону денормализации данных, в отдельных случаях это может ускорить систему не в разы, а в сотни и тысячи раз.Данные денормализованные, в максимально простом виде, для того чтобы в одном запросе участвовала только 1 таблица.
количество документов, на тот момент да около того. Если брать на текущий момент (>1 000 000 в месяц), то около 7 Тб получится, что достаточно весомо для нас. Я согласен с вами, при отсутствии ограничений по железу, этот вариант очень хорош.
*мрачно* Никаких.
СБ не знает что такое облака, ставок «админстратор облачных данных» в тарифной сетке нет, денег на облака — тоже.
Становиться облачным провайдером для госструктур с перспективой оплаты за год во второй половине декабря тоже стремятся не только лишь все.
Да и к тому же, есть полугосударственный ростелеком, не?
СБ не знает что такое облака, ставок «админстратор облачных данных» в тарифной сетке нет, денег на облака — тоже.
Становиться облачным провайдером для госструктур с перспективой оплаты за год во второй половине декабря тоже стремятся не только лишь все.
Да и к тому же, есть полугосударственный ростелеком, не?
В государственном облаке. Претензий к качеству ЦОДа работы нет, но это конечно не SSD и изменение конфигурации тот еще процесс :)
Если речь идет о том поделии, которое внедрял в региональных фондах капремонта, то подтверждаю, проблемы со структурой БД там — колоссальные. Приходилось писать запросы на три экрана с несколькими десятками таблиц. Но это ещё мелочи. Главная проблема софта — несогласованность данных в разных таблицах.
Самый простой вариант борьбы, после разделения базы на актуальную и архив — раскатить БД на кластер и расширять кластер при необходимости — не пробовали?
Согласен, это простой вариант и первый приходит на ум. Частично мы так и сделали:
«Ключевые решения, предпринятые на этом этапе:
— Отделение части информации оперативной базы данных»
К сожалению, на полноценный кластер не было возможности перейти по техническим причинам (ресурсы серверов ограничены), кроме того в этом случае усложнялась процедура обновления данных. В качестве альтернативы рассматриваем выделение «горячих» данных в NoSQL базу данных в памяти, этого должно хватить при росте нагрузки в 3-5 раз от текущего.
Плюс, главным потребителем времени является не столько обращение к БД, сколько формирование файла платежного документа.
«Ключевые решения, предпринятые на этом этапе:
— Отделение части информации оперативной базы данных»
К сожалению, на полноценный кластер не было возможности перейти по техническим причинам (ресурсы серверов ограничены), кроме того в этом случае усложнялась процедура обновления данных. В качестве альтернативы рассматриваем выделение «горячих» данных в NoSQL базу данных в памяти, этого должно хватить при росте нагрузки в 3-5 раз от текущего.
Плюс, главным потребителем времени является не столько обращение к БД, сколько формирование файла платежного документа.
а что именно затрагивало время при генерации файла?
если данные для платежки уже предрассчитаны и лежат в таблице, значит основное время это запросить данные по платежному документу и сформировать PDF.
вы смотрели способы оптимизировать формирование PDF? есть 2 альтернативы:
1. использовать высокоскоростную библиотеку формирования ПДФ, учитывая что формат открытый и генерацию PDF можно на коленке набросать практически с plain-text
2. переложить формирование ПДФа на клиента, используя javascript — parall.ax/products/jspdf например
если же вы не предрассчитываете платежные данные по клиенту (примерно как это делается при закрытии месяца в 1С), то это очень большой минус. Перерассчитывать все начисления, перевытаскивать все платежи, пересчитывать остатки на каждый запрос пользователя — неудивительно что будут ужасные тормоза. Даже удивительно как ваша система справлялась с нагрузкой
если данные для платежки уже предрассчитаны и лежат в таблице, значит основное время это запросить данные по платежному документу и сформировать PDF.
вы смотрели способы оптимизировать формирование PDF? есть 2 альтернативы:
1. использовать высокоскоростную библиотеку формирования ПДФ, учитывая что формат открытый и генерацию PDF можно на коленке набросать практически с plain-text
2. переложить формирование ПДФа на клиента, используя javascript — parall.ax/products/jspdf например
если же вы не предрассчитываете платежные данные по клиенту (примерно как это делается при закрытии месяца в 1С), то это очень большой минус. Перерассчитывать все начисления, перевытаскивать все платежи, пересчитывать остатки на каждый запрос пользователя — неудивительно что будут ужасные тормоза. Даже удивительно как ваша система справлялась с нагрузкой
1. использовать высокоскоростную библиотеку формирования ПДФ, учитывая что формат открытый и генерацию PDF можно на коленке набросать практически с plain-textвариант хорош, но труднее поддерживать, формы часто меняются, пока используем FastReport.
переложить формирование ПДФа на клиента, используя javascript — parall.ax/products/jspdf напримера вот это не вариант, клиенты даже не знают, что формируется PDF пока они заняты другими разделами сайта, нагружать слабые мобильные приложения (такие тоже имеют доступ к порталу) не есть хорошо
если же вы не предрассчитываете платежные данные по клиенту
нет, мы давно отделили оперативные данные, тут проблемы нет, да и в основной системе принцип другой не как в 1С
ФастРепорт это что-то такое больно старое знакомое из Дельфи… возможно это и есть №1 причина в тормозах. Особенно если ваш репорт напичкан картинками-логотипами и выбраны не самые оптимальные настройки экспорта в ПДФ- то будет отжирать много CPU на генерацию
Да, давно развивается, выбран как универсальное решение для формирования печатных шаблонов еще на заре проекта, картинок нет, только QR код и линейный штрих-код, да отнимает достаточно ресурсов техники, но экономит ресурсы разработки, готовых дизайнеров отчетов местной прописки не так уж и много.
а профайлером не смотрели, что именно в фаст репорте тормозит? Может как-то неправильно используете библиотеку, что она отнимает много времени и ресурсов
Смотрели, но я бы не сказал, что тормозит, определенные издержки есть, но гораздо большие выгоды может принести изменение сценарий формирования, а не само формирование, потому что в первом случае мы оптимизируем формирование, а во втором вовсе можем от него отказаться в момент обращения
Там несколько тяжелых запросов на пару экранов. Причем, они могут вызываться в цикле.
По крайней мере, так было пару лет назад, когдя занимался этим.
По крайней мере, так было пару лет назад, когдя занимался этим.
Вот давно сижу и думаю у меня хайлоад или не хайлоад. А тут вот прямо челюсть отпала.
У меня в среднем 500 запросов в секунду к серверу приложений, это примерно х10 к серверу БД. Рост базы пара терабайт в год. Ну приложение и приложение пашет и пашет. Архитектура «срали мазали». А это оказывается раз в 100 хайлоадней чем хайлоад :)
Вообще классное решение 5 лет кормить две команды вместо разовой покупки FullSSD полки за 5 мультов. Главное убедительно втирать руководству про «хайлоад» и про героическое решение проблем по модным методикам. Ыххх.
ЗЫ: А если даунгрейднуться на БУшные целероны с двумя винтами в зеркале — команду можно удвоить и еще 10 лет героически бороться. Зато если такое решение продать любому адекватному заказчику — у него все будет летать!
ЗЗЫ: У меня МФЦ, если что.
У меня в среднем 500 запросов в секунду к серверу приложений, это примерно х10 к серверу БД. Рост базы пара терабайт в год. Ну приложение и приложение пашет и пашет. Архитектура «срали мазали». А это оказывается раз в 100 хайлоадней чем хайлоад :)
Вообще классное решение 5 лет кормить две команды вместо разовой покупки FullSSD полки за 5 мультов. Главное убедительно втирать руководству про «хайлоад» и про героическое решение проблем по модным методикам. Ыххх.
ЗЫ: А если даунгрейднуться на БУшные целероны с двумя винтами в зеркале — команду можно удвоить и еще 10 лет героически бороться. Зато если такое решение продать любому адекватному заказчику — у него все будет летать!
ЗЗЫ: У меня МФЦ, если что.
Все относительно, две команды не кормили фул тайм, каждый этап занимал в среднем от 40 до 80 часов разработки.
По поводу хайлоад или нет можно долго спорить, для себя критерий вывел, когда число пользователей превышает 100 000, но это только мое мнение.
По поводу покупки SSD, довольно не бюджетно, кроме того гос ЦОД ( к примеру в одном из государственных ЦОД мы ждали замены обычного жесткого диска в течении 5 месяцев) не сильно заинтересован в покупке дорогих дисков и, что самое главное, резервирования таких дисков, на случай выхода из строя.
По поводу хайлоад или нет можно долго спорить, для себя критерий вывел, когда число пользователей превышает 100 000, но это только мое мнение.
По поводу покупки SSD, довольно не бюджетно, кроме того гос ЦОД ( к примеру в одном из государственных ЦОД мы ждали замены обычного жесткого диска в течении 5 месяцев) не сильно заинтересован в покупке дорогих дисков и, что самое главное, резервирования таких дисков, на случай выхода из строя.
Замечательно, в нашем случае ситуация была такая: диски старой модели, запасов не осталось, бюджет ЦОД на год утвержден и потрачен, планово диски купят в следующем году (на всякий случай, не в этом проекте), по замерам IOPS в момент проблем был в районе 180, СУБД при это хорошо упиралась в диск.
Хороший сторадж всегда был дорогим. И это одно из самых ответственных мест любого ЦОДа. Проект изначально не прощитан.
Генерировать документы, каждый раз это действительно больно. Мы пришли к тому что генерирует документы в конце отчётного периода и храним за последние 3 месяца т. к. по статистике более старые документы у нас практически не востребованы, но если они все же требуются, генерация начинается только по нажатию кнопки пользователем.
Логично, хорошая стратегия, единственный нюанс, если одновременно нажмут кнопку 1000 пользователей, то возникнет очередь формирования и пользователь может получить чуть позже чем привык
Вероятность того что большому количеству пользователей одновременно понадобится информация из старых периодов очень мала. У нас стоит по серверу отчётности на макрорегион, это более 1кк пользователей. Стало интересно, и глянул мониторинг в МРЦ (самый крупный регион) пик очереди 96 докуметов, скорость выдачи документа пользователю к сожалению немониторим, но жалоб не разу не получали.
п. с. фикса одного из операторов большой тройки
Согласен. Более того сценарий, когда все зарегистрированные пользователи хотели бы видеть платежный документ перед оплатой, сомнителен. Например, за сотовый телефон я счет детальный не смотрю, плачу по выставляемой сумме. Так что, по идее, следует изменить сам процесс, исключить формирование платежного документа в принципе, оставив только по запросу. Но, чтобы принять такое решение, нужна статистика и согласие заказчика.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эволюция HighLoad приложения на примере регионального портала госуслуг