Мастер-Тур(15):Методика формирования программ туров

Версия статьи от 22-01-2024.

Введение

Документ предназначен для сотрудников ТО, использующих ПК Мастер-Тур 15, в обязанности которых входит формирование продукта. Цель документа – помочь избежать типичных ошибок и поделиться успешными практиками.
Сокращения:
ПТ – программа тура
ЦБ ~ ценовой блок

Основные параметры ПТ, влияющие на производительность

Основной критерий, с помощью которого можно понять оптимально вы работаете с ПТ или нет, это скорость выставления продукта (или изменений в продукте) в онлайн. Если новая ПТ выходит в онлайн менее чем за 2-5 мин – значит все правильно. Если больше – это повод задуматься. Похоже, что что-то пошло не так.

Также следует отслеживать время, за которое перезапускается служба поиска и расчетов. Если полное время перезапуска превышает 1 час – значит надо что-то менять в ПТ или в железе.

Мы выделили несколько параметров, которые влияют на скорость, с которой изменения, произведённые менеджерами в турпродукте (изменения в ЦБ, ценах, ПТ, отелях и т.п.) отображаются на сайте.

Число схем и маршрутов

Один из основных параметров, влияющих на скорость выставления тура в онлайн является число схем и маршрутов по туру. Чем их больше, тем дольше тур или изменения по нему будет выходить на сайт.

Схема – это комбинация отель+продолжительность, на которую возможен тур. Таким образом число схем в ПТ будет равно количеству отелей в программе тура, умноженное на количество продолжительностей в данной программе тура. Обратите внимание, что в многоотельных турах число схем считается как произведение числа схем для каждой услуги проживания.
Например: в ПТ две услуги проживания, в первой два отеля и две продолжительности. Во второй три отеля и четыре продолжительности. Общее число схем будет: (2 отеля*2 продолжительности)*(3 отеля*4 продолжительности) = 48.
Поэтому в многотельных турах мы рекомендуем пользоваться настройкой ограничения комбинаций отелей по категориям или (если это невозможно) разбивать тур на несколько ПТ.

Маршрут – это комбинация, точки отправления с точкой прибытия. Кроме этого для услуги перелет к ним добавляется рейс с временем вылета. Последний фактор очень важен, если у одного рейса несколько времен вылета (= строчек в расписании перелета), то считаться будет не один рейс, а столько, сколько строчек в расписании. Маршруты считаются только для маршрутных услуг.
Например: есть тур в Турцию с перелетом туда-обратно (два рейса), с двумя вариантами трансфера туда (аэропорт-Белек, аэропорт-Анталия) и два варианта трансфера обратно (Белек –Аэропорт и Анталия-аэропорт). По каждой маршрутной услуге считаем число маршрутов:

• Перелет туда – 2 маршрута (потому что два рейса)
• Перелет обратно – 2 маршрута
• Трансфер туда – 2 маршрута
• Трансфер обратно – 2 маршрута

Количество маршрутов будет равно 2*2*2*2=16.

Чем больше схем и/или маршрутов у вас в одной ПТ, тем дольше тур или изменения по нему будут выходить в онлайн. К сожалению, невозможно указать точную максимальную цифру числа схем и маршрутов. Она привязана к характеристикам вашего железа. Наша статистика показывает, что ПТ в ~300 схем и ~300 маршрутов не вызывает каких-то проблем с производительностью. Мы не рекомендуем в одной ПТ иметь более 500 схем и 2000 маршрутов, время загрузки туров не более двух минут. Если в одном туре имеется два из трёх ограничений, тур считается "тяжёлым"

Оптимальные программы туров

• На скорость выставления ПТ в онлайн прежде всего влияет совокупность количества схем отелей и количества маршрутов. Причем число маршрутов сильнее влияет на производительность. Мы не рекомендуем в одной ПТ иметь более 6000 схем и 200 маршрутов (или 500 схем и 2000 маршрутов).
• Обращайте внимание на количество расписаний для авиаперелетов. Этот параметр существенно влияет на число маршрутов. Даже если у вас один ежедневный рейс, но с разным временем вылета, вы получите 7 маршрутов.

Обращайте внимание на число городов вылета-прилета. Каждый город это новый маршрут.

• Приводимые ограничения не являются абсолютными. У вас может быть быстрая ПТ с 10000 маршрутами, но всего с несколькими схемами отелей и наоборот.

Неоптимальные программы туров

В этом разделе мы приводим варианты неоптимальных ПТ, которые приводили к проблемам в работе службы поиска и расчетов.

• В одной ПТ сделано более 30-ти вариантов трансферов
• В одной ПТ внесено более 15 отелей с 30 вариантами продолжительности.
• Заезды по ПТ каждый день, и тур рассчитанный на продолжительность от 1-го до 29 дней (и более)
• Пример типичной ПТ, «выше» которой, скорее всего начнутся проблемы с производительностью: 1 город вылета, 5 городов (курортов), 10 вариантов трансферов, 50 отелей в каждом городе и связка трансферов осуществляется через маршрутные точки: город отеля -> отель (к примеру для каждого трансфера выбрано 4 отеля). Число маршрутов для данной ПТ – 1*5*10*50*4=10000.
  
• Одна ПТ, в которой более 10 продолжительностей и более 10 городов является неоптимальной для расчета актуальных фильтров

Обратите внимание, что приведенные примеры не являются абсолютными. Т.е. вполне возможно, что вы сделаете ПТ с 50-тью вариантами трансферов, и этот тур будет выходить в онлайн за 30 сек. Важно понимать, что в конечном счете на производительность системы влияет общее число комбинаций, которое получится в итоге в рамках одной ПТ. Кроме этого многое зависит от мощности сервера, на котором располагается служба поиска и расчетов (минимальные требования здесь).

Начиная с релиза 15.8 для дополнительного поиска неоптимальных программ туров появилась запись статистики по наиболее "тяжелым" турам в лог TourSearchCache.txt.

Типичные ошибки

Здесь приведены типичные ошибки, которые допускают менеджеры при формировании ПТ.

Ошибка	Последствия
Не привязаны трансферы к геоточкам.	Система считает, что такой трансфер доступен для всех отелей. Это приводит к увеличению числа маршрутных комбинаций, иногда очень значительному.
В ПТ есть услуги, привязанные к разным геоточкам. Услуги между собой никак не связаны. Например, нет трансферов между этими двумя геоточками.	Система не может выстроить маршрут, так как не находит услуг, связывающих две геоточки. Тур не выходит в онлайн.

Выводы

Все приведенные советы и примеры являются ориентирами, которые следует проверять на практике. У нас есть примеры ТО, у которых при общем большом числе схем по всем ПТ (0,5 млн), служба поиска и расчетов перезапускается за 8 мин, в то время как у другого ТО, со 100 тыс. схем, перезапуск службы занимает 20 мин, при том что сервер у второго ТО мощнее.
Поэтому общий совет – начинайте с простых ПТ. И постепенно увеличивайте число комбинаций, добавляя туда новые варианты услуг. Так вы точно будет понимать, где находится предел вашей системы.

Если что-то пошло не так

Вы выставляете новую ПТ, но она не выставляется, и вы не понимаете, что происходит. В такой ситуации советуем посмотреть логи, которая ведет служба поиска и расчетов.
В файлах-логах можно найти определенную информацию по каждому этапу работы системы.

Существующие логи

Логи ПК Мастер-Тур:

• DictionaryCacheLog.txt – первоначальная загрузка в кеш всех справочников;
• TourSearch.txt – первоначальный расчет и перерасчет актуальных фильтров, информация о поисковых запросах;
• TourSearchApi.txt – информация о поисковых запросах к API поисковыми системами;
• TourSearchApiShort.txt – краткая информация о поисковых запросах к API поисковыми системами (записывается только запуск и завершение запроса). Используется вместо лога TourSearchApi, если у клиента наблюдается слишком большая нагрузка при записи лога TourSearchApi;
• TourSearchCache.txt – детализированная информация при первоначальной загрузке в кеш и об изменениях всех данных в системе.
• ExeptionLogger.txt – в этот файл записываются все исключения, произошедшие во время работы в службы поиска, по ошибкам в этом логе можно быстро найти проблему, если она возникла;
• Calculate.txt – записываются результаты расчетов по перелетам, отелям, доплатам к авиаперелетам;
• Specials.txt – лог для акций, записи попадают в момент применения акции к ценам, так же в этот лог пишется информация об изменениях в цене, когда мы запрашиваем список разниц цен;
• Account.txt – лог, в который пишется информация об успешной или не успешной попытки войти в систему.

Логгеры функционала авиаперелетов из внешних систем:

• GetFlightsRequestResponseLogger – включает получение информации об авиаперелетах при переходе в корзину (поиск);
• ActualizeFlightsRequestResponseLogger – включает получение информации о выбранном авиаперелете (актуализация);
• CreateFlightsReservationRequestResponseLogger – включает получение информации о бронировании;
• GetFlightsDetailsLogger – включает получение информации об ошибках, возникающих при работе с внешним поставщиком;
• GetFareFamiliesFlightsRequestResponseLogger – включает получение информации о тарифах (при нажатии кнопки Сменить тариф);
• GlobalInformationFlightLogger – включает запись краткой статистики по каждому запросу к внешнему поставщику;
• GetFlightsRequestResponseNotValidLogger – включает сохранение запросов и ответов с ошибками или пустыми результатами поиска.

Логгеры функционала отелей из внешних систем:

• HotelFromRemoteProviderMappingsLogger - включает получение информации о результатах и ошибках синхронизации справочников;
• HotelFromRemoteProviderMappingsAddLogger – включает получение информации о создании справочных данных и их синхронизации при бронировании;
• HotelFromRemoteProviderErrorLogger - включает получение информации об ошибках, возникающих при работе с внешним поставщиком;
• HotelsRemoteProviderRequestResponseLogger - включает получение информации об актуализации данных и бронировании туров;
• SearchHotelsRemoteProviderRequestResponseLogger - включает получение информации о поисковых запросах туров;
• TravelBoxRequestResponseLogger - включает получение информации о штрафах (только для TravelBox).

TourSearchCache.txt – информация при первоначальной загрузке данных в кеши и всех изменениях в системе

Если служба поиска и расчетов загружается дольше обычного или не загружается совсем, то в файле TourSearchCache.txt необходимо найти туры, в которых время загрузки более 5 минут.

Что искать:
Tour key: 100003426. Scheme count: 2156. Routes count: 12350. Time: 00:08:36.0000000

Как расшифровать:
Программа тура с ключом 100003426 имеет 2156 схем и 12350 маршрутов, рассчитывалась 8 мин 36 сек.

Решение:
В данной ПТ явно превышено число маршрутов. Ваша система не справляется с таким большим числом комбинаций. Необходимо либо уменьшить число маршрутов в ПТ, либо разбить данную турпрограмму на несколько, для уменьшения количества маршрутов.

Начиная с релиза 15.8 появилась запись статистики по наиболее тяжелым турам в лог TourSearchCache.txt

Что искать:
statistic: tp - 100011123 count - 51 time - 0:01:59.9327177
statistic: tp - 100003424 count - 200 time - 0:00:23.53224
statistic: tp - 100011248 count - 6109 time - 0:00:20.2080214
Как расшифровать:
tp - идентификатор турпрограммы.
count - относительное количество расчетов данной турпрограммы в актуальных фильтрах. Это относительный параметр, который показывает вес турпрограммы. Чем больше это число, тем больше раз эта турпрограмма участвовала в расчетах.
time - время расчета.

Статистика пишется в случае, если в службе включены актуальные фильтры.
Если у текущего экземпляра службы есть отдельная служба актуальных фильтров, то статистика писаться будет только в службе фильтров.
Чем больше параметр count, тем данная турпрограмма покрывает большое количество фильтров, то есть она будет пересчитываться по многим направлениям/датам/продолжительностям и т.д.
Для оптимизации турпрограмм нужно проанализировать турпрограммы по перелетам, трансферам, отелям, городам. Попробовать уменьшить/разбить перелеты и трансферы.
Проанализировать количество выбранных отелей. Например: если имеется более 200 отелей, необходимо разбить их по 50 отелей.
Более подробно с оптимизацией по производительности системы можно ознакомиться в статье рекомендациии по оптимизации производительности системы.

TourSearchApiShort.txt – краткая информация о поисковых запросах к API поисковыми системами

TourSearchApiShort.txt – краткая информация о поисковых запросах к API поисковыми системами.
Используется вместо лога TourSearchApi, если у клиента наблюдается слишком большая нагрузка при записи в лог TourSearchApi.
В данный лог записываются только информация о старте запроса и о выполнении запроса.
На примере запроса GetTours:

• GetTours started – запуск запроса GetTours;
• GetTours completed – запрос GetTours выполнен;
• Time: 825 – время обработки запроса GetTours в мс;
• Guid – идентификатор запроса
• Host – IP-адрес хоста

Пример

2023-01-31 09:56:56,740 [13] INFO [(null)] - Guid: b4253481-6ebb-4ff1-bf0d-0328bc806e46. Host: 10.10.60.51. GetTours started. http://supp-08.megatec.ru:9000/TourSearchOwin/searchApi?action=GetTours&count=20&countryId=90&departCityId=1&dateFrom=10.10.2018&dateTo=10.10.2018&ticketsIncluded=0&adults=2&kids=0&nightsMin=7&nightsMax=7&currencyId=1 2023-01-31 09:56:57,564 [13] INFO [(null)] - Guid: b4253481-6ebb-4ff1-bf0d-0328bc806e46. Host: 10.10.60.51. GetTours completed. Time: 825. http://supp-08.megatec.ru:9000/TourSearchOwin/searchApi?action=GetTours&count=20&countryId=90&departCityId=1&dateFrom=10.10.2018&dateTo=10.10.2018&ticketsIncluded=0&adults=2&kids=0&nightsMin=7&nightsMax=7&currencyId=1

TourSearch.txt – лог расчета актуальных фильтров

Актуальные фильтры – это список значений, которые появляются в выпадающих списках основных фильтров в форме поиска туров. Например, когда вы нажимаете фильтр «Куда», система показывает варианты стран, для которых есть цена. Когда вы добавляете новую ПТ с новой страной, она должна попасть в список стран, по которой есть туры. Эта процедура и называется расчетом актуальных фильтров. При создании неоптимального тура она может занимать продолжительное время.
Поэтому мы рекомендуем, при непонятных ситуациях проанализировать данные из файла TourSearch.txt, а именно сравнить количество актуальных фильтров и время расчета актуальных фильтров последнего запуска с аналогичными данными из предыдущих расчетов.

Начиная с релиза 15.7 эти данные пишутся в лог TourSearchCache.txt

Что искать:
processed: 2499009 / 2507042 by tour programs: 100008192
processed: 2502007 / 2507042 by tour programs: 100008192
processed: 2505000 / 2507042 by tour programs: 100008192
ActualFilters: processing complete. Time: 00:09:16.7486096

Как расшифровать:
Общее количество актуальных фильтров – 2507042. Данные фильтры рассчитывались ~ 9 мин

Решение:
Если в разы увеличилось время расчета актуальных фильтров, то необходимо проанализировать добавленные за это время программы туров.

В разы увеличилось время расчета актуальных фильтров

Если в разы увеличилось время расчета актуальных фильтров, то нужно проанализировать, какие турпрограммы могли стать причиной этого.
Для этого нужно обратить внимание, на каком туре актуальные фильтры начинают рассчитываться медленно.

Что искать:
processed: 2499009 / 2507042 by tour programs: 100008192
processed: 2502007 / 2507042 by tour programs: 100008192
processed: 2505000 / 2507042 by tour programs: 100008192
ActualFilters: processing complete. Time: 00:09:16.7486096

где 100008192 – ключ турпрограммы, по которой происходит расчет актуальных фильтров. Если расчет актуальных фильтров по одной турпрограмме происходит более нескольких минут, нужно проанализировать эту турпрограмму. Неоптимальной турпрограммой для расчета актуальных фильтров является программа,в которой более 10 продолжительностей и более 10 городов.

Существующие ограничения системы

Отображения не минимальной цены для конкретного отеля

Примерно в 1% результатов поиска может возникать ситуация, когда для конкретного отеля подбирается не самая минимальная цена.

При инициализации службы поиска происходит взвешивание цены на отель. В случаях, когда суточные цены на разные размещения или типы питания внесены разным количеством периодов, средний вес более дешевого номера может быть больше, чем у более дорогого. Например, цена на питание завтрак внесены 4-мя строчками, а цена на питание полупансион – 6-ю. При измерении общего среднего веса цены получится, что цена на питание полупансион весит меньше.
Для избежания подобных ситуаций рекомендуем вносить цены на разные размещения и типы питания одинаковым количеством периодов.

Взвешивание цены на услугу, при разных типах цен

В случае, есть на услугу заведены цены и за период и за день с большим периодом действия, будет действовать разный алгоритм взвешивания цены, что может привести к тому, что меньший вес будет иметь цена за период, даже, если по факту она выше, чем цена за день. Для такого большого периода действия цены должен быть одинаковый тип цены, чтобы взвешивание отработало корректно, либо период действия цены за период должен быть в разы меньше.