Итак,
оптимизация «черной админки» состоялась!
Как было сказано ранее, один из клиентов пожаловался на скорость показа страниц биллинга, которая была по его словам ужасающей (как он сказал, «список ваучеров открывался минут пять...»). И что очень важно, клиент согласился скинуть мне дамп своей базы, чтобы я смог экспериментировать с этими данными на своем домашнем сервере, за что ему отдельное спасибо!
Как я и предполагал, «тормоза» интерфейса были вызваны большим объемом данных, хранившихся в базе. На одном из рисунков ниже показана «круговая диаграмма Статистики Easyhotspot-а», в описании (сбоку) к которой прекрасно видно, о чем идет речь — СТО ПЯТЬ ТЫСЯЧ ваучеров в базе!!! И в дополнение к ним — БОЛЕЕ ТРЕХСОТ ТЫСЯЧ записей о сеансах в таблице radius-a!!!
С другой стороны, в коде Easthotspot-а для работы с ваучерами в базе данных использован т.н. «view», который, образно говоря, является виртуальной таблицей, создаваемой сервером «на лету» при выполнении некоего «специального» SQL-запроса. То есть, по факту в базе этой таблицы НЕТ, и когда программа запрашивает из нее данные, MySQL сначала выполняет «специальный» запрос, формирует эту таблицу, и уже потом запрашивает информацию из нее. Должен сказать, что view этот в свете написания различных процедур в биллинге был «ну просто идеален!» (для программиста) — он выдавал о ваучерах практически «всё, что надо, и еще чуть-чуть»! Что и не удивительно, так как он собирал «в единую кучу» всю информацию из целого ряда таблиц — ваучеров, тарифов, сеансов, при этом проводя еще и различные промежуточные вычисления, относящиеся уже скорей к статистике! Единственный у него, как оказалось, был недостаток — СКОРОСТЬ! И если на небольших объемах данных это было не заметно, то дамп, который мне прислал вышеуказанный клиент, показал это во всей красе! Конечно, «пять минут на открытие списка ваучеров» я на своем сервере так и не увидел, но от 2-х до 3-х в разных местах наблюдалось. В принципе, характеристики моего тестового сервера «звёзд с неба не срывают»:
ОС: Ubuntu 18.04.3 LTS / x86_64
CPU: Intel(R) Celeron(R) CPU N2815 @ 1.86GHz
RAM: Total: 3.7 Гб / Free: 1.4 Гб
HDD: msata SSD какого-то неизвестного китайского происхождения
И вот первая картинка — результат ПОИСКА ваучера:
Должен сразу сделать пару примечаний:
- Во первых, чтобы видеть помогают ли вносимые мной изменения ускорить работу программы или нет, в «черную админку» было добавлено своеобразное Easter Egg (т.н. «пасхальное яйцо») — при наведении на строку «EasyHotspot — Hotspot Management System», расположенную в «футере» страницы, теперь выпрыгивает popup-подсказочка с текстом типа «Page generated for 0.2625 sec.» (то есть, сведения о том, сколько времени в секундах сервер потратил на генерацию страницы) в основном — на выполнение SQL-запроса и обработку его результатов). И при создании скриншотов я специально наводил мышь, чтобы отображалось это сообщение, и вам было видно указанное время.
- В вторых, все скриншоты для этого поста создавались на УЖЕ ОПТИМИЗИРОВАННОЙ ВЕРСИИ «черной админки», и поэтому на картинках наблюдается уже «сравнительно небольшое время» (никаких «пяти минут» (т.е. 300.0 и более секунд) там нет и в помине!). И лишь один запрос на сегодняшний день в Easyhotspot-е оставлен с использованием того самого «старого медленного» view-а - это именно показанный выше поиск ваучера! Вот в нем я так и не смог отказаться от view-а, который «знает про ваучеры абсолютно все» (и как следствие, ищет по всем данным, каким угодно). И поэтому, в нынешней версии биллинга этот запрос ОСТАЛСЯ ТАКИМ ЖЕ «ТОРМОЗНУТЫМ», каким он и был до оптимизации! Приведенная выше картинка четко показывает — ответа от биллинга пришлось дожидаться 71 секунду. Данная цифра может служить своеобразным ориентиром «того, как оно было до оптимизации» — так же медленно открывались все те страницы «черной админки», у которых для получения данных из базы использовался указанный view. Справедливости ради, считаю нужным еще раз подчеркнуть: поиск на странице ваучеров — это ЕДИНСТВЕННОЕ на сегодняшний день место в (обновленном оптимизированном) биллинге, где оставлено использование данного «тормознутого» кода!..
А теперь перейдем к остальным скриншотам. Та самая диаграмма статистики, на которой видно, сколько ваучеров есть в базе (на генерацию ответа ушло 18 с лишним секунд против прошлых «скольких-то там минут»):
Список ваучеров после оптимизации стал открываться МЕНЕЕ ЧЕМ ЗА ОДНУ СЕКУНДУ:
Правда, из таблицы со списком ваучеров пришлось убрать возможность сортировки данных по целому ряду колонок (без «волшебного» view-а эти данные попросту отсутствуют, а т.к. они вычисляемые», то и сортировка по ним стала невозможна)! Поначалу даже думал, что уйдут и кнопки, переключавшие режим показа — «активированные»/«неактивированные»/«все». Но потом решение нашлось, и в итоге процедура наложения этих фильтров на SQL-запрос не сильно замедлила процедуру генерации отчета:
Следующая процедура, которая ранее использовала указанный «тормознутый» view — это печать ваучеров. Ведь так удобно было сразу всё получить одним запросом! И, как оказалось, не только прожорливость плагина формирования PDF была причиной невозможности сгенерировать за раз большое число ваучеров. Теперь процедура изменена так, чтобы не использовать этот «супер-пупер» view. В результате - с одной стороны, генерация PDF-файла с ваучерами стала происходить быстрее, а с другой стороны — выросло максимальное число ваучеров, которое может быть успешно распечатано. Есть и еще один «бонус», обусловленный тем, что функция генерации PDF-файла с ваучерами является одной из составляющих процедуры их генерации (создания новых ваучеров). То есть, проще говоря, теперь при создании новых ваучеров можно не опасаясь указывать большее их количество за один раз (у меня получалось успешно сгенерировать и распечатать где-то 200...250 ваучеров).
Также, был изменен ещё целый ряд процедур, использовавших этот громоздкий view. В их числе: кабинет пользователя, скрипт регулярных заданий (который запускается по cron-у каждую минуту), экспорт списка ваучеров в xls-файл, рутина, отвечающая за «автологин» (автоматическую авторизацию клиентов по mac-у при втором и последующих подключениях), и прочие другие. Все это заметно повысило отзывчивость программы, база которой была переполнена до такой степени...
Но главный вопрос человек, приславший мне дамп своей базы, задал в самом начале — «
Так что, мне теперь лучше базу ставить с нуля, пустую, или может быть можно как-то вычистить все эти старые ваучеры?» И это заставило пересмотреть (уже имевшуюся в программе) процедуру инкассации и последующего удаления израсходованных ваучеров. Потому как со старой процедурой он бы эти свои десятки тысяч (фактически уже бесполезных) старых ваучеров чистил бы «до второго пришествия»...
И процедуры были переписаны. Теперь они в Easyhotspot-е, скажем так, «пакетные». Сначала Администратор должен выполнить инкассацию. Для этого он выбирает сотрудника (кассира или другого админа), и указывает даты начала и окончания периода, за который хочет провести инкассацию. Биллинг отбирает из базы все ваучеры, отвечающие указанным критериям: их выписал указанный сотрудник, ваучеры были активированы клиентами в указанный промежуток времени. В результате получает вот такой отчет:
Как видно на картинке, на формирование отчета программе все-таки требуется некоторое время. Но, показанные на рисунке 20 с небольшим секунд — это сущие пустяки по сравнению с тем, что было раньше, когда отбор ваучеров для инкассации осуществлялся тем самым «многострадальным» view-ом! Его результатов при таком суммарном количестве ваучеров, которое показано на рисунке выше, можно было просто не дождаться вообще! Сервер мог «тупо упасть»...
Получив результат (а если бы в присланом дампе базы цены для тарифов были установлены какими-то отличными от нуля, то и итоговую сумму денег, подлежащую инкассации, страница тоже показала бы), Администратор должен нажать кнопочку «Инкассация» (внизу слева), после чего программа отметит все ваучеры, попавшие в данный отчет, как инкассированные. Кстати, происходит это весьма быстро:
Финальный этап избавления от старых ваучеров — их «Безопасное удаление». Открывая это меню, вам тоже придется немного подождать (в случае ТАКИХ объемов баз данных, если кто-то уже успел позабыть от этом!). В этот раз программа отберет все ваучеры, которые уже прошли инкассацию, и у которых истек срок годности. Результаты поиска также будут представлены в виде таблицы, в которой будут перечислены тарифы и число ваучеров, которые подлежат удалению:
И вот теперь администратору осталось лишь нажать кнопку «Удалить все». Должен сказать, что при ТАКИХ количествах процедура удаления занимает ОЧЕНЬ много времени! Лично у меня и именно с этими цифрами, которые показаны на рисунке выше, удаление выполнялось примерно 12 минут! А у клиента, приславшего мне дамп для экспериментов, удаление длилось где-то с пол-часа. Правда, он на радостях «наинкассировал» сразу более 40 тысяч ваучеров, благодаря чему и был вынужден так долго ждать окончания процедуры удаления...
В КОНЕЧНОМ ИТОГЕ — ускорение выполнения ряда процедур в паре с чисткой базы от старых и ставших уже ненужными ваучеров позволили заказчику весьма комфортно работать с биллингом, не взирая на оставшееся в базе их количество (тоже не малое — 39 с лишним тысяч). Под «комфортностью» в данном случае подразумевается тот факт, что время, затрачиваемое программой на формирование страниц, СНИЗИЛОСЬ ЕЩЕ В НЕСКОЛЬКО РАЗ по сравнению с цифрами, показанными на рисунках выше!..