Тормозит лог в ZP

[sydoow]

Стал тормозить лог ZP (сообщения приходят с задержкой), раньше такого не замечал
Со временем задержка в логе - увеличивается

И сама начинает зенка тормозить, медленнее выполняются проекты, долго реагирует на "стоп"/"старт"/вход в ES, хотя ресурсы свободные есть
Ещё, походу по этой же проблеме, долго закрывает зенку (долго весит "сохранение состояния")

Потоков >50 (проекты в основном на запросах)
ОЗУ: 24Гб

Не могу понять в чём может быть причина
ZP и винду - перезагружал
Версия: 7.1.6.1

Мб где-то кэш почистить?

 

[sydoow]

В TG чате по ZP один человек посоветовал проверить SSD, спасибо ему за это, и перевести шабы в ОЗУ

1) Проверил SSD - оказался уже "уставшим"
2) Заменили на сервере SSD и переустановил Win 2012
3) Перевёл все шабы и файлы для них - на диск в ОЗУ (SoftPerfect)
4) Перевел папку "trash" и временные файлы Win - на диск в ОЗУ
5) Увидел что много обращений к файлам "\Logs\executionLog-ZennoPoster.txt" и "\Logs\nonCriticalErrors-base_cr.txt" - перевел их тоже в ОЗУ (через правку конфиг файлов ZP)

Стало быстрее, но всё равно не идеально (

Если нагрузить шаблоны на Вебе - то ресурсы сервера нагружаются почти полностью, но задержки в логе нету

Если нагрузить шаблоны на запросах (>70 потоков) - то ресурсы сервера нагружаются на ~50% и начинается задержка в логе, сами шабы медленнее отрабатывают и через какое то время может крашится ZP (раньше сутками работал ZP без краша)

Вообщем, как я понял, такое происходит если нагрузить потоками на запросах.

В шаблонах используются запросные методы:
ZennoPoster.HTTP.Request - для GET и POST запросов
ZennoPoster.HttpPost - для "multipart" POST запросов, потому что при использовании предыдущего метода на "multipart" POST запросах не отправлялся русский текст

Версия ZP: 7.1.6.1

При этом на сервере (на SSD, не в ОЗУ) ещё включил апарсер, который никак не повлиял особо на нагрузку и на кол-во глюков в логе ZP

Вообщем непонятное для меня что-то происходит, хочется выжимать по максимуму потоки, а не получается и ещё вылеты стали появляться..

 

[sydoow]

Я выяснил в чём было дело...

Проблема возникала когда много потоков перебирало Гугл таблицу с несколькими К строк чтобы достать нужные данные (соответственно шло много запросов).
Не знаю чья это проблема: Гугла (из-за большого кол-ва обращений) или в ЗП где то косяк (всё таки Гугл таблицы относительно недавно появились и возможно не все баги ещё выявлены, да и версия ЗП у меня годичной давности)

В моём случае было идеальным решением это переход на БД, но с БД я всё так и не научился работать, а решение нужно было максимально быстрым

Поэтому я решил проблему след образом
1) Доставал нужные столбцы из Гугл таблиц и складывал в отдельные списки
2) Полученные списки я закидывал в ЗП таблицу + добавлял отдельный столбец "Номер строки в Гугл Таблице"
3) Проводил нужные манипуляции с этой таблицей (чистка/выборка)
4) В итоге получал в ЗП таблице нужные мне данные и номера нужных строк в Гугл табл
5) Делал единичные запросы к Гугл таблице по номерам строк

Таким образом снизил кол-во запросов в Гугл таблице, проблема с тормозами тайминга исчезли и скорость вернулась

ps: если бы не эта проблема, я бы не узнал что у меня SSD диск на сервере умирает))

 

[BAZAg]

Таким образом снизил кол-во запросов в Гугл таблице, проблема с тормозами тайминга исчезли и скорость вернулась

Значит, если я правильно понял, проблемы с логом нет - есть проблема с запросами к таблице?
Просто, с проблемами с логом я также встречался - решал их отправляя сообщение в лог в виде new Task - как минимум из-за отправки сообщения в лог остальное выполнение шаблона не тормозило на этом действии.

 

[bigloafer]

Перевел папку "trash" и временные файлы Win - на диск в ОЗУ

Этого лучше не делать: Я делал так. При объемных операциях выделенная память в рам диск заканчивается и операция успехом не завершается.
К самой виндовской папке TEMP зенка не так сильно и обращается.

Увидел что много обращений к файлам "\Logs\executionLog-ZennoPoster.txt" и "\Logs\nonCriticalErrors-base_cr.txt" - перевел их тоже в ОЗУ (через правку конфиг файлов ZP)

На сколько сильный был прирост производительности после этой операции?

Не можете поделиться поэтапными действиями для перевода данных логов в рам диск?

 

[sydoow]

Значит, если я правильно понял, проблемы с логом нет - есть проблема с запросами к таблице?

Просто, с проблемами с логом я также встречался - решал их отправляя сообщение в лог в виде new Task - как минимум из-за отправки сообщения в лог остальное выполнение шаблона не тормозило на этом действии.

Сам шаблон это вроде как не тормозило (по крайней мере в начале тормозов лога) - видно было по запоздалому логу, что скорость была норм

Но в какой то момент скорость выполнения ВСЕХ шаблонов в ЗП всё таки падала (когда задержка в логе была час и более) и потом зенка могла вообще выключиться

При этом всём ресурсы сервера нагружались не полностью

Ещё момент..
Есть шабы на запросах (там без Гугл таблиц) который запускаются по расписанию каждый час и когда они запускались лог начинал тормозить сильнее, потом когда они выключались тайминг лога восстанавливался - так могло работать сутки без проблем, главное нужно было найти баланс

 

[sydoow]

На сколько сильный был прирост производительности после этой операции?

Хз, не скажу, больше делал для того, чтобы меньше обращений в диску, а на скорость не обратил внимание

Не можете поделиться поэтапными действиями для перевода данных логов в рам диск?

В файлах:
'd:\Program Files\ZennoLab\RU\ZennoPoster Pro V7\7.1.6.1\Progs\NLog.config'
'd:\Program Files\ZennoLab\RU\ZennoPoster Pro V7\7.1.6.1\Progs\ServiceProcesses\NLog.config'
!СНАЧАЛА СДЕЛАЛ РЕЗЕРВНЫЕ КОПИИ ФАЙЛОВ!

В поле 'name="nonCriticalErrors"' в путях "fileName" - прописал полный путь до файла на диске ОЗУ
Было:
fileName="${basedir}/../Logs/nonCriticalErrors-${processname}.txt
Стало:
fileName="Z:/Logs/nonCriticalErrors-${processname}.txt