Русский язык для XenForo 2, быть костылям или нет?

[romeyk]

По ошибке с белым экраном после якобы установки. Проблема в том, что установка языка идет через ajax запрос. А ограничение по времени для ajax-запроса установлена в 30000 мс, т.е. 30 секунд (файл core.js)
У меня всё на докер-контейнерах на локале работает, это немного медленнее, чем обычный LAMP или что там и за 30 секунд не успевают отработать все запросы к БД, которые, к слову, завернуты в транзакцию. Сам язык создается, а фразы в базу не пишутся. На хостинге со слабыми ресурсами такая же песня. Я не заморачиваясь на время установки сделал так - в файле js/core-compile.js находим поиском timeout:3E4 и меняем 3E4 на 9E4 (90000 ms - это 90 секунд).

 

[Smalesh]

Очень некорректное сравнение.

Вполне корректное, так как при беге возле машины из Москвы в Волгоград пассажир успевает немного издохнуть - возникает тот самый таймаут.

У меня тупо не успевает обработаться сам xml

Это вопрос к работе и производительности mysql, той самой машине из примера выше. Как бы. поэтому на нормальных площадках все нормально отрабатывает. И к слову, чтобы i7 реализовал себя, а не был занят все время дисковыми операциями, ставят где-то 32гига оперативы и желательно ssd. Но это уже жуткий оффтоп.

 

[romeyk]

тогда вопросов больше нет

А у меня к вам их и не было. Если кто-то найдет решение вопроса другим методом, буду благодарен.

 

[West14]

romeyk, у Вас довольно странный случай. Т.к. в большинстве таких ситуаций помогает просто продолжение перестроения на главной в админке.
Суть всей этой дискуссии в том, что тот способ, который Вы предложили не является правильным потому, что:

редактировать файлы движка - моветон.

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

 

[romeyk]

Это вопрос к работе и производительности mysql, той самой машине из примера выше. Как бы. поэтому на нормальных площадках все нормально отрабатывает. И к слову, чтобы i7 реализовал себя, а не был занят все время дисковыми операциями, ставят где-то 32гига оперативы и желательно ssd. Но это уже жуткий оффтоп.

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

 

[ssmol]

Если кто-то найдет решение вопроса другим методом

настроить нормально сервер. год назад у меня спокойно двойка ставилась на raspbian pi2

 

[ssmol]

У меня в контейнерах крутятся достаточно большие проекты

ага тоесть из имеющихся 8 гигов контейнеру с ксеней может быть вообще достается 256

 

[romeyk]

romeyk, у Вас довольно странный случай. Т.к. в большинстве таких ситуаций помогает просто продолжение перестроения на главной в админке.
Суть всей этой дискуссии в том, что тот способ, который Вы предложили не является правильным потому, что:

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

Каким образом увеличение таймаута может сломать форум? Если бы это был не аякс-запрос и возникла такая проблема, до достаточно было бы в настройках php увеличить max_execution_time.

ага тоесть из имеющихся 8 гигов контейнеру с ксеней может быть вообще достается 256

Нет, ограничений на использование памяти нет.

 

[Smalesh]

Тяжело доходит. Есть проблема с работой mysql. Эта проблема косвенно вылазит при импорте языка, по принципу "там где тонко - там и рвется". Эта проблема действительно может сломать форум. Но вместо нее предлагается позиция "страус и песок", еще и с правкой файла. Так понятней?

 

[romeyk]

Тяжело доходит. Есть проблема с работой mysql. Эта проблема косвенно вылазит при импорте языка, по принципу "там где тонко - там и рвется". Эта проблема действительно может сломать форум. Но вместо нее предлагается позиция "страус и песок", еще и с правкой файла. Так понятней?

Явно не мне. Постараюсь объяснить более подробно.
Для начала рассмотрим вариант - БД и файлы хранятся в одном месте - всё быстро работает и все рады. Есть другой вариант - БД находится на другом сервере и время ответа будет выше. Для работы форума в целом это никакой проблемы не создает, разве что страницы на доли секунды будут открываться медленнее. Но конкретно в этой ситуации (вполне может быть, что таких ситуаций единицы или она вообще единственная), ситуация выглядит иначе.
Как происходит обычная генерация страницы - идет запрос на сервер, сервер обрабатывает запрос, при этом выполняя, в том числе, запросы к БД. Если тонкое место у меня общение с БД и по разным причинам я не могу это изменить, то я просто чуть увеличу максимальное время обработки скрипта в php.ini, не трогая форум. Но в случае добавления языка выполняется огромная куча запросов, что согласитесь, нетипично для стандартной работы форума. Если бы это был обычный POST запрос или не было бы ограничения в js, то я бы увеличил молча у себя максимальное время выполнения скрипта и не было бы этого холивара. Но запрос тут - ajax, при этом с искусственно ограниченным временем выполнения. Самый главный вопрос - зачем ограничивать время выполнения ajax-запроса, если сервер и так отменит выполнение через те же 30 секунд (дефолтная настройка max_execution_time), но при этом каждый может самостоятельно изменить настройки сервера.
Для обычной нормальной работы форума - 30 секунд хватает с головой и говорить о проблемах стоит тогда, когда для обычной работы сервера не хватает 30 секунд для обработки запроса. Но когда высоконагруженный скрипт еле-еле проползает в 30 секунд, которые ты не можешь изменить никак иначе, чем правкой файлов форума - это ненормально. Да, можно написать дополнение, которое переопределит стандартный метод ajax, но это те же яйца... И мне вот просто интересно - может кто-то посмотреть за сколько секунд выполнится запрос добавления языка на среднестатистической машине без контейниризации? Это можно сделать посмотрев в инструментах разработчиках на вкладке network, отфильтровав XHR запросы и включив preserve log, т.к. после окончания обработки идет перезагрузка страницы.

 

[CrazyHackGUT]

может кто-то посмотреть за сколько секунд выполнится запрос добавления языка на среднестатистической машине без контейниризации

i3-2130 (HT включен), 12ГБ DDR3 1333МГц, HDD Western Digital 1Tb Blue. Запрос на импорт языка (именно первоначальный):

 

[Smalesh]

Если тонкое место у меня общение с БД

То в таком случае меняют шаг итерации, в конце концов, но не задирают таймауты. Но сначала включи log_slow_queries на малое время и посмотри, как у тебя работает сам mysql. Будешь удивлен.



У меня есть проекты, где db вынесена на кластер c ttl, просто как раз в этот момент на нем работаю

root@backend:/# ping 10.0.14.2
PING 10.0.14.2 (10.0.14.2) 56(84) bytes of data.
64 bytes from 10.0.14.2: icmp_req=1 ttl=64 time=0.059 ms
64 bytes from 10.0.14.2: icmp_req=2 ttl=64 time=0.039 ms
64 bytes from 10.0.14.2: icmp_req=3 ttl=64 time=0.052 ms
^C
--- 10.0.14.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.039/0.050/0.059/0.008 ms
root@backend:/#

и нет проблем при импортах.