Support Forum

[vic]

Скажите пожалуйста, TS однопоточная?

У меня есть интерфейс, внутри которого есть три файла → index.ftl file1.ftl file2.ftl
Внутри file1.ftl выполняется длительная работа на BeanShell, скажем 5 секунд.
Файл file2.ftl сам по себе отдается быстро.
Так вот когда я из index.ftl при помощи ajax запрашиваю сначала file1.ftl, а затем file2.ftl → ответ на оба запроса приходит почти одновременно, после того, как file1.ftl отработает, т.е. через 5 секунд.
Такое ощущение, что TS выполняет запросы поочередно, т.е. работает в один поток.

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

PS Или же это проблема Jetty?

[admin]

Сейчас ситуация такая:
1) Самое-самое ядро системы, кеши и прочее - однопоточное.
2) Проверка прав пользователей и генерация страниц (уровень Secured... и выше) - многопоточные
3) Различные тормозные операции типа генерации отчета, переиндексации задачи после изменения, отправка оповещений по e-mail, интеграция с SCM делаются в отдельных потоках.

С многопоточностью ядра играться пробовали, ничего хорошего из этого не вышло. Главная проблема в том, что для многопоточной работы нужно выставлять блокировки различных объектов (например, если мы меняем какую-то задачу, то должны выставить write lock на задачу и read lock на вышестоящие задачи). В итоге сбор информации о том, что нужно блокировать, а так же сама блокировка/разблокировка занимают времени в разы больше, чем собственно выполнение операции. Блокировать все и один раз оказывается банально быстрее, хотя и процессоры остаются незагруженными.

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

[vic]

Спасибо за развернутый ответ.
А конкретно применительно к интерпретации BeanShell-кода, какая ситуация? Провел пару экспериментов и выяснил, что если в file2.ftl нет биншела, а только HTML или FreeMarker → он отдается быстро, не дожидаясь выполнения file1.ftl (в котором работает биншел).

[admin]

BeanShell очень медленно инициализируется, т.е. тормоза будут независимо от размера скрипта. Собственно, это было главной причиной появления компилированных скриптов в TS4.

[vic]

Ну все же в моем случае задержки несоизмеримы со временем инициализации...

[admin]

Ну все же в моем случае задержки несоизмеримы со временем инициализации...

Тогда не знаю, надо профайлером смотреть - обратите внимание на триал YourKit.

[vic]

Подниму старую тему для прояснения ситуации. Случайно, в процессе решения других задач, обнаружил.

Объект Bsh, через который происходит интерпретация кода на BeanShell:

Code: Select all

<#macro script>
<#assign nest>
<#nested>
</#assign>
${Bsh.eval(nest)}
</#macro>

у вас является объектом класса com.trackstudio.app.CalculatedValue, о чем пишется в логе « define Bsh=com.trackstudio.app.CalculatedValue@598e915a », а также легко выясняется через функцию javap на BeanShell'е.

А теперь смотрим вывод такой команды:

Code: Select all

$ grep 'define Bsh' tomcat.log | tail -10000 | uniq -c
  10000 define Bsh=com.trackstudio.app.CalculatedValue@598e915a

И видим, что для последних десяти тысяч запросов использовался для интерпретации один единственный объект Bsh. И если мы найдем в логе последнее вхождение предыдущего объекта Bsh, то сразу после него увидим перезапуск Tomcat.
Это навевает предположения, что или объект Bsh объявлен как статический, либо CalculatedValue это синглетон.
И сразу становится понятно, почему код на BeanShell'е в кастомных интерфейсах выполняется только последовательно.
И ваше предложение смотреть в сторону профайлера выглядит как незнание, как работает собственный продукт…

[admin]

Ну, в TrackStudio сейчас только наших собственных Java-классов 950 штук, не считая JSP, JavaScript-кода и прочего, так что вполне можем чего-то и не знать В любом случае, при проблемах с тормозами лучше сразу смотреть profiler, наши умозрительные догадки очень часто бывают неправильными.

По поводу bsh, там CalculatedValue - singleton

Code: Select all

    public static synchronized CalculatedValue getInstance() throws GranException {
        if (instance == null) {
            instance = new CalculatedValue();
        }
        return instance;
    }


Что не мешает создавать новую копию интерпретатора при каждом вычислении (что логично, иначе в него параметры не передашь):

Code: Select all

    public synchronized Object eval(String text) throws GranException, EvalError {
        try {
            Interpreter interpreter = createInterpreter();
            interpreter.set(LOG, log);
...


но метод объявлен synchronized, так что именно вычисление через bsh сейчас однопоточное (и как там сделать возможность многопоточного вычисления не очень понятно, ведь скрипт может вызывать практически все что угодно).

Попробуйте отказаться в этом месте от Bsh в пользу прямого Java-кода, если возможно.

[vic]

Спасибо за пояснение.

и как там сделать возможность многопоточного вычисления не очень понятно, ведь скрипт может вызывать практически все что угодно

А какие могут быть проблемы?
Исходя из ваших слов выше, secured объекты все синхронизированы, т.е. использовать их при нескольких потоках безопасно? Опасность только если что-то менять через KernelManager?

[admin]

А какие могут быть проблемы?
Исходя из ваших слов выше, secured объекты все синхронизированы, т.е. использовать их при нескольких потоках безопасно? Опасность только если что-то менять через KernelManager?

Так не только безопасно, но и бесполезно. В общем, если убрать synchronized то пользы не будет, а глюки в случае вызова через Kernel будут.