Анонс новостей (обновлений, исправлений) Easyhotspot

[Dmitry]

подогнали мне тут для экспериментов дамп «реальной живой» базы Easyhotspot-а, в которой примерно 105 тысяч ваучеров (а заодно и несколько сотен тысяч записей о сеансах в таблице radacct). И появился серьезный повод для «суровых» экспериментов по радикальному сокращению длительности выполнения SQL-запросов в базу (а то, некоторые страницы «черной админки» открываются по нескольку минут!)...

[Dmitry]

Итак, оптимизация «черной админки» состоялась!

Как было сказано ранее, один из клиентов пожаловался на скорость показа страниц биллинга, которая была по его словам ужасающей (как он сказал, «список ваучеров открывался минут пять...»). И что очень важно, клиент согласился скинуть мне дамп своей базы, чтобы я смог экспериментировать с этими данными на своем домашнем сервере, за что ему отдельное спасибо!

Как я и предполагал, «тормоза» интерфейса были вызваны большим объемом данных, хранившихся в базе. На одном из рисунков ниже показана «круговая диаграмма Статистики 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 с лишним тысяч). Под «комфортностью» в данном случае подразумевается тот факт, что время, затрачиваемое программой на формирование страниц, СНИЗИЛОСЬ ЕЩЕ В НЕСКОЛЬКО РАЗ по сравнению с цифрами, показанными на рисунках выше!..

[Dmitry]

Обновлен платежный модуль для п/с «ЕДИНАЯ КАССА». Что изменилось:

• Модуль «на лету» форматирует номер телефона, вводимый клиентом, приводя его к виду типа +38 (066) 583-6592;
• Администратор может принудительно указать код страны для телефона клиента, что снижает число совершаемых клиентами ошибок;
• Добавлен файл текстовых сообщений на украинском языке (модуль теперь поддерживает три языка интерфейса - английский, украинский и русский);
• Сообщения об ошибках выводятся popup-окнами, а не функцией alert языка javascript (симпатичней выглядит, и «единообразно» в разных браузерах);
• Немного откорректирован CSS страницы модуля;
• Полностью зашифрован обмен данными в http-запросах между модулем и биллингом Easyhotspot;
• Переписан скрипт-инсталятор модуля, благодаря чему избавился от возможных ошибок, в случае запуска установки из папки с пробелами в имени;
• Обновлена инструкция к модулю «ЕДИНАЯ КАССА»;

[Dmitry]

Обновлена инструкция «Программа управления Wi-Fi хотспотом - Easyhotspot, Руководство по эксплуатации»:

• В инструкцию добавлен раздел, посвященный настройкам «Функции отправки служебных СМС», а именно — «Подробнее о параметрах, используемых разными агрегаторами», описывающий какие данные и куда нужно вписывать для работы с различными агрегаторами;
• В свете того, что была изменена процедура инкассации выручки от продажи ваучеров, переписаны и соответствующие разделы Руководства;
• Перепроверены (и в случае необходимости исправлены) ссылки как внутренние, так и внешние.

Обновленная инструкция доступна по ссылке:
«Программа управления Wi-Fi хотспотом - Easyhotspot, Руководство по эксплуатации»

Обновлена инструкция «Индивидуализация вашего хотспота»:

• Добавлена информация о том, как выбрать формат печати ваучеров — «большой» PDF (стандартный) / «маленький» PDF / чек для «термопринтера» / XML-файл;
• Добавлена информация о настройке параметра, меняющего местами закладки «Пароль» и «Бесплатно» (что удобно при использовании СМС-авторизации);

Обновленная инструкция доступна по ссылке:
«Индивидуализация вашего хотспота»

[Dmitry]

Исправлен экспорт в XML - убраны имена тегов, содержавшие кириллицу и пробелы.

[Dmitry]

Сегодня была впервые протестирована возможность установки биллинга Easyhotspot на дистрибутив Ubuntu 20.04 LTS (Focal Fossa). Правда, использовалась еще тестовая версия дистрибутива (т.н. Daily Build), т.к. официальный релиз состоится аж 24 апреля 2020 года.

Не без чудес, конечно, и не с первого раза, но тем не менее - в конечном итоге установка завершилась успешно:

[Dmitry]

Обновление — в процедуру отправки биллингом СМС добавлен «счетчик» неудачных попыток. Отныне, если одно и то же СМС не получается отправить более 10 раз, биллинг прекращает попытки сделать это. Основная цель «нововведения» — блокировка перманентной отправки ошибочных СМС (например, если клиент указал не правильный номер телефона).

[Dmitry]

Исправлены мелкие ошибки в паре функций javascript страницы авторизации:

• откорректирована реакция на нажатие кнопки Enter в форме для ввода телефона для СМС-авторизации;
• устранено появление текста «undefined» в некоторых popup-сообщениях об ошибках;

[Dmitry]

В продолжение «оптимизации» работы с «толстой» базой — изменены функции поиска по таблице radacct и экспорта результатов поиска из таблицы radacct. При очень больших объемах базы сам поиск хоть и медленно, но все-таки выполнялся. А вот экспорт результатов при сильно большом числе записей, увы, «падал» (речь о десятках тысяч строк и более — при тестах на моем домашнем тестовом сервере, и даже в случаях менее 10 тыс. строк — во время проверок на одном из тестовых VPS). Поэтому процедура экспорта была изменена — в зависимости от числа строк, которое должно попасть в отчет, программа теперь МЕНЯЕТ ФОРМАТ вывода данных! При малом числе попадающих в отчет записей («водораздел» установлен равным 5 тысячам строк) программа, как и раньше, выводит отчет в формате XLS. Если же отчет будет включать больше строк, то, во первых, формат вывода «автоматом» переключится на CSV, а во вторых, «наполнение» файла отчета будет выполняться «пакетно» — частями по эти самые 5 тыс. строк. И лишь после того, как отчет будет сформирован полностью (в него будут вписаны все попавшие в отчет строки, сколько бы их там ни было), программа выдаст его Администратору...

[Dmitry]

Аналогичный описанному в предыдущем сообщении подход был задействован и для функции экспорта списка ваучеров из программы — при повышенном их числе вывод осуществляется в формате CSV (вместо XLS), который гораздо менее «прожорлив» в отношении ресурсов сервера.