Старый друг - лучше новых двух (тут трется воскресший freenx-server)

Модераторы: dimbor, Модераторы разделов

Djelf
Сообщения: 516
ОС: Гигтег+Цшт32

Re: Старый друг - лучше новых двух

Сообщение Djelf »

На примере запроса переменных

Код: Выделить всё

SELECT 
   count(key), /* если ключа нет будет 0 */
    key,
    coalesce(us.value,rs.value) as value /* если у юзверя установлен параметр то он не NULL */
FROM settings as rs
LEFT JOIN settings as us on us.key=rs.key AND us.user=@user
WHERE rs.user='root'
GROUP BY rs.key /* обязательно, если запрос не по одному ключу в WHERE, а если по одному то и не важно */
GROUP BY, это конечно, дополнительные расходы, но небольшие.

И вообще это все проще и быстрее переписать на Golang ;)
Спасибо сказали:

dimbor
Ведущий рубрики
Сообщения: 1393
Статус: Подвинутый участник

Re: Старый друг - лучше новых двух

Сообщение dimbor »

Благодарю! До счетчика мог бы и сам догадаться, но видать уже втупил вкрай с этой 1ч, не к ночи.
Djelf писал:
13.01.2020 13:36
И вообще это все проще и быстрее переписать на Golang ;)
Да хоть матом на заборе. Тоже проще в итоге. Это все переписывание преследует в первую очередь цель разобраться, как оно функционирует в целом. И всплывают нюансики, знаешь ли.
Спасибо сказали:

dimbor
Ведущий рубрики
Сообщения: 1393
Статус: Подвинутый участник

Re: Старый друг - лучше новых двух

Сообщение dimbor »

В качестве промежуточного отчета имею сообщить: Все (буквально все) ранее писанное мной на баше написано криво, и надо переписывать. Пичаль.

Нагребая nxsettings, прокачал скилл работы со строками. Перебираючи конфиги, оно тормозило нещадно. А как выкинул к хреням все эти grep, cut, tr, sed, awk, скорость увеличилась в разы. Где-то в четыре раза, если верить time. Баш все это сам умеет, только приноровиться надо было.

Посему из nxsetup получается знатная вундервафля, проверяющая все что душе угодно.

Также даже многострочники из сопроцесса читать научился - надо всего лишь знать, сколько строк будет в ответе - животворящий count() помогает. Иногда только запросов получается два вместо одного. При постоянно открытой базе и хилых объемах данных, скорость особо не просаживается.

В связи с открывшимся разнообразием возможностей возникает такой вопрос. Если каждый рабочий nx-инстанс все равно с двумя БД работает, может вешать сопроцесс на все время существования и вторую БД туда просто приатачивать?
Спасибо сказали:

Djelf
Сообщения: 516
ОС: Гигтег+Цшт32

Re: Старый друг - лучше новых двух

Сообщение Djelf »

dimbor писал:
16.01.2020 19:33
В связи с открывшимся разнообразием возможностей возникает такой вопрос. Если каждый рабочий nx-инстанс все равно с двумя БД работает, может вешать сопроцесс на все время существования и вторую БД туда просто приатачивать?
Точно так: https://www.sqlite.org/lang_attach.html Два сопроцесса не требуются.
Спасибо сказали:

Djelf
Сообщения: 516
ОС: Гигтег+Цшт32

Re: Старый друг - лучше новых двух

Сообщение Djelf »

Ну я тут слегка подумал ;)
Если ты решил загнать настройки в sqlite, то скорость обработки всяких ini`шек не имеет никакого значения, +1с это проблема?
Поиск и чтение, какой то настройке в ini, это критично, а при выполнении условия = они все уже в базе sqlite вот на это можно закрыть глаза.
Спасибо сказали:

dimbor
Ведущий рубрики
Сообщения: 1393
Статус: Подвинутый участник

Re: Старый друг - лучше новых двух

Сообщение dimbor »

Все ж неспроста мутится. Вылижу по скорости набор конфигов - появятся готовые решения для nxnode и nxserver. Да уже часть есть. Они позволят оптимизировать по скорости сам протокол установки сеанса, не отвлекаясь на фигню всякую. Да и схемы систематизирутся, алгоритмы оформляются - вот это вот все. В идеале вместо source nxloadconfig везде должен быть source nxfunctions, условно говоря.

Если б не увидел конский рост производительности, не парился сейчас бы. Дико интересно, насколько можно разогнать старичка-инвалида. Ну да уже буквально несколько суток осталось, в зависимости от загрузки на основной работе. Потом представлю конкретику.
Спасибо сказали:

Djelf
Сообщения: 516
ОС: Гигтег+Цшт32

Re: Старый друг - лучше новых двух

Сообщение Djelf »

Насколько разогнать можно?
Предполагаю, что примерно до <1с, от момента запуска, до получения данных и их отображения от NX-сервера.
Реализация на Golang, на текущем сервере, проходит процедуру коннекта за 2-3с, на NXClient 5с, OpenNX вообще уныл в этом плане (зато у него прогресс-бар логина есть).
Но OpenNX можно бустануть. В AsyncProcess отключить таймаут ожидания нахрен ;)
Смысл то в чем, при TCP_NODELAY пакет от NXServer всегда будет меньше размера TCP пакета (а даже если выключен, то все равно одним пакетом, но возможно список запущенных сессий может не влезть, если их 100500), следовательно одним пакетом и проскочит, т.е. в wxInputStream весь ответ будет доступен сразу же, поэтому задержка (уверен на 99%) вообще не требуется.
Спасибо сказали:

dimbor
Ведущий рубрики
Сообщения: 1393
Статус: Подвинутый участник

Re: Старый друг - лучше новых двух

Сообщение dimbor »

Djelf писал:
19.01.2020 10:44
Насколько разогнать можно?
Поживем - увидим. Пока старые source *.conf явно быстрее летают, чем манипуляции с БД. Одна надежда предвычислить и прочекать заранее все, до чего дотянусь. Предупреждаю, может получиться: "Думала - счастье!... А нет, опять опыт."

Кстати, спрошу еще две вещи. Сейчас не сильно парит, но потом может выползти.

1) Заполняю _пустую_ БД, куча инсертов - ~1.5 с., но после этого первая операция чтения проходит через ~5 с. В непустой с update все отлично. Я так пол, скулайт файл целиком с нуля 5 секунд записывает. Что так долго? Там 20К всего.

2) Движок мне, блин, ключи при чтении по алфавиту сортирует по умолчанию. А мне их надо в порядке записи в базу. Они друг от друга иногда зависят. В ORDER BY ничего похожего на "ордер не бай" не нашел. Однако просмотрщик от mc их показывает в нужном порядке. Как так?
Спасибо сказали:

Djelf
Сообщения: 516
ОС: Гигтег+Цшт32

Re: Старый друг - лучше новых двух

Сообщение Djelf »

По (1) я писал выше: включи режим "PRAGMA journal_mode = WAL". Можно еще поиграться с прагмами типа ""PRAGMA synchronous = OFF", "PRAGMA cache_size = 100000", "PRAGMA temp_store = MEMORY", а можно поставлять базу как ее дамп и не читать настройки, а поднимать из дампа.
В принципе можно поставлять базу и как базу, но если она создана на версии 3.6.17, то 3.6.16 ее не прочтет.
Есть еще вот это https://www.sqlite.org/mmap.html я не использую, потому что у меня базы в несколько гигов, а на конфиг в 20кб - самое то!!!

По (2) прочитай вот это https://www.sqlite.org/autoinc.html Есть ORDER BY rowid, но при создании таблицы, rowid нужно указывать явно с autoincrement, иначе при vacuum будет пересчет поля rowid и не факт что нумерация не собьется.
mc видимо показывает dump из базы, а он упорядочен по rowid или не упорядочен... я код dump`а не смотрел.
Спасибо сказали: