И все же на тему производительности. на примере наших дс 6.3, 40к записей, linux, tomcat8 nio , JAVA_OPTS Xms1G -Xmx8G

# wrk -t 1 -c 20 -d 30s /основная карточка

Thread Stats Avg Stdev Max +/- Stdev
Latency 1.79s 136.69ms 2.00s 68.14%
Req/Sec 13.65 9.57 50.00 79.57%
307 requests in 30.04s, 6.89MB read
Requests/sec: 10.22
Transfer/sec: 234.83KB


#wrk -t 1 -c 20 -d 30s /contact

1 threads and 20 connections
Requests/sec: 10.22
Transfer/sec: 234.83KB Thread Stats Avg Stdev Max +/- Stdev
Latency 31.82ms 12.24ms 172.59ms 88.17%
Req/Sec 642.35 105.80 820.00 80.67%
19195 requests in 30.03s, 267.49MB read
Requests/sec: 639.29
Transfer/sec: 8.91MB

Собственно проблем то и нет особых с котом, видно что может выдавать приличный результат по нагрузке, а вот когда дело доходит до postgres, волосы дыбом становятся от количества запросов. Может есть какие-то секреты оптимизации запросов к бд? Оптимизация не самой бд, а именно дс?



Редактировано 1 раз. Последний раз 03.07.2019 08:46 пользователем recived.

У меня всё свелось к подбору макс.количества соединений в postgresql.conf в зависимости от сервиса и к локальным войнушкам с ITшниками о реальной, а не динамической памяти на виртуалках.

Именно tomcat в частности и java (к примеру dspace index-discovery -o) в целом показывает неспособность продавливать планку объёма динамической памяти вверх. Но, это скорее местные особенности/проблемы конкретных гипервизоров и конкретных инфраструктур.

В принципе, можно поставить перед tomcat какой-то кэширующий http proxy, но... статистика станет тогда совсем уж недостоверной. В принципе, счастье угрожает случиться в dspace7, когда solr будет совсем "наше всё" и дескать angular будет отдельно ходить по DSPACE API в ядро и по REST API в SOLR (ЗАЧЕМ?!), по крайней мере разработчики говорят что узкое место в виде базы пропадёт, но мне вот не понятно как данные будут летать при работе mediafilter... понятно что извлеченка будет храниться в асетсторе - ближе к ядру, но и в SOLR будет индекс... в общем, опять ёж с ужом. Ладно хоть solr будет ванильный и в плане поиска его можно будет безнаказанно настраивать под себя.

Цитата:

В принципе, можно поставить перед tomcat какой-то кэширующий http proxy, но... статистика станет тогда совсем уж недостоверной.

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

На самом деле, статистика томкэта достаточно объективна. Я в основном работаю с логами и если вычитать из этих сотен гигабайт аксес логов всё что резолвится в гугл, яндекс и пр, а так же все автономки всех поисковых систем (ага, иплист умер в 2012-м, но кто мешает делать их работу самим?), то получается очень даже ничего. Местных роботов мы тоже отлавливаем и вычитаем из статистики (или даже баним) достаточно эффективно, так что тут только одна проблема - иногда статистика падает задним числом (когда нашли робота, который не очень активно работал несколько месяцев), но это не проблема, когда можешь объяснить причину.

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

Круто ^_^. Вопросы только возникли.

Цитата:

Я в основном работаю с логами и если вычитать из этих сотен гигабайт аксес логов

Сотни гигов логов это сильно. За какой период так накопили?

Цитата:

На самом деле, статистика томкэта достаточно объективна.

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

Цитата:

А вот сводить кэширующий хттп прокси и собственно веб сервер - это уже чуть менее тривиально.

В плане? В чем недостаток?

В предыдущих постах имел ввиду реальную статистику посещений на основании которой можно делать выводы. Занимаются этим сбором хорошо известные GA, я.Метрика и прочие системы. Статистика которая идет в зачет.посещений основывается на гостах в которых принято считать посещением "Сеанс". Как ни крути дс такое не сможет сделать, максимум отфильтровать по заданным критериям логи.



Редактировано 2 раз. Последний раз 05.07.2019 16:24 пользователем recived.

1. Ведем историю с 2012-го года, хотя сервис с 2004-го. Всё, что раньше 2012-го к сожалению утрачено (логи, статистика, частично репорты). Изначально сервис был запущен на SPARC/Solaris, с которого пришлось в какой-то момент очень быстро валить. В процессе оказалось что на большой машине (880 или 890) было всего дисков шесть по 72гб, логи там просто не велись. Это что касается Уральского федерального (ранее УРГУ). Во всех остальных подшефных dsapce я стараюсь поддерживать полноту логов со старта сервиса. Пока дырка в несколько месяцев есть только в одном случае из дюжины. Там сервис на некоторое время выпал из поля зрения - ВУЗ хотел попробовать самостоятельно всё поддерживать, но потом оказалось что дружить проще. В период самостоятельности там некоторые проблемы (в т.ч. с местом на сервере) решали не ротацией логов, а их удалением.

И когда пиндосы говорят о проектах типа RAMP, то я думаю, что в общем могу не хуже, имея статистику (и логи и гугл) с дюжины одинаково настроенных источников. Только вот какую такую аналитику, какие откровения можно тут получить - хз. Всё и так достаточно прозрачно, а логи - инструмент для бана ботов.

2. Проблема ресурсов решаема. Быть может не дешево, но решаема.

3. Когда-то имел опыт сведения squid и httpd, но это было очень давно. Теперь эпизодически имею опыт сведения ezproxy и сервисов за ним - с точки зрения анализа логов это достаточно комплексная задача. Но, может это я что-то не так делаю...

Что касается статистики GA, это очень спорно! Сейчас девчата из duraspace утверждают что известный код отрабатывает даже прямые клики по ссылкам на PDF из выдачи поисковиков и урлов на других сайтах. Казалось бы, причин им не верить нет и события годовалой давности, когда в РФ стали падать dspace по причине кривых маршрутов до google вроде это подтверждают, но... я вот пробовал имитировать клики и потом их искать в GA - их нет. И заявленная связка гуг вебмастер+гугл аналитика тоже не так хороша. Имхо, посчитать скачивания ПДФ по логам можно точнее чем это сделает гугл аналитика и ГОРАЗДО точнее, чем это сделает яндекс метрика.

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

Всем умельцам привет.
Вернулся я вновь к вопросам статистики в Dspace.Так как гугл с определённого времени перестал фиксировать открытия загруженых файлов, чем я успешно пользовался много месяцев, вновь встал вопрос о загрузках для отчётов. Анализировать логи вручную не знаю как и чем.
Вопрос заключается в том, как внедрить яндекс-метрику (вроде как оттуда можно вытянуть эти циферки) в xmlui интерфейс. Не могу найти таковых. Может кто подскажет куда код-то вставлять? В jspui вроде как в header-default можно. В xml не понимаю. Направьте, кто сможет меня, пожалуйста. Ибо мне просто уже съели мозг с этими цифрами.
У нас используется:
- dspace 5.6 xmlui Mirage (1),
- Linux/Debian без GUI,
- tomcat 8
- java 8

BarsTK
5.6 + xmlui... мсье любит риск?:)

На самом деле xmlui при модификации обычно нужно пересобрать. Это раз. Далее, код отслеживания метрики (равно как и аналитики) в заголовке страницы никак не посчитает Вам клики на PDF и тем более прямые переходы на PDF из гугла.

В JSPUI реализовано всё это гораздо изящнее - [github.com]

<bean class="org.dspace.google.GoogleRecorderEventListener">
        <property name="eventService" >
            <ref bean="dspace.eventService"/>
        </property>
    </bean>

Т.е. юзеру просто не отдадут контент, пока гугл не "тикнет". Так что байки о том что прямые клики на ПДФ пролетают мимо аналитики скорее не верны, если речь идет о JSPUI. Про XMLUI не знаю.

Как такое реализовать самостоятельно для XMLUI я не знаю, но наверняка оно как-то уже реализовано.



Редактировано 2 раз. Последний раз 13.07.2019 14:57 пользователем IdeaFix.

IdeaFix, спасибо за коментарии, но

Цитата:

5.6 + xmlui... мсье любит риск?:)

В чём особый риск?

Цитата:

На самом деле xmlui при модификации обычно нужно пересобрать.

Я в курсе, с этим без проблем

Цитата:

код отслеживания метрики (равно как и аналитики) в заголовке страницы никак не посчитает Вам клики на PDF и тем более прямые переходы на PDF из гугла.

Знаю, но нужно с чего-то начинать.

Цитата:

прямые клики на ПДФ пролетают мимо аналитики скорее не верны, если речь идет о JSPUI

конечно не верны скорее всего и в отношении XMLUI, но как их отследить, я не понимаю

Цитата:

наверняка оно как-то уже реализовано

Уже запарился искать, поэтому решил спросить здесь

Неужели никто не в курсе как метрику в xmlui встроить? Какой-то тупик в замкнутом круге получается

Дайте ссылочку на Ваш репозиторий, отвечу в личку....

А насчет xmlui.... вот мне сейчас лениво в темплейт темы лезть, но Вы же проверили и там никак код не вбросить?:)

Цитата:

IdeaFix
Дайте ссылочку

http://elib.gsmu.by - это наш репозиторий

Как вбросить код, к сожалению не увидел

У вас закрыта дырка с дефолтной темой видимо по причине её (темы) отсутствия, это хорошо. Но всё равно, до 5.10 лучше обновиться, там только секьюрити и немного с postgres и solr добавлено.

Что же до кода метрики, асинхронку (если она есть) я бы добавлял в page-structure.xsl без пересборки, а синхронный код в трансформер для отображения страницы, но это не оптимальный вариант конечно. Но всё же, зачем яндекс, если гугл теортеически (на jspui практически!) может не меньше, а даже больше?

IdeaFix, спасибо за уделённое время. Несколько пояснений.

Цитата:

IdeaFix
У вас закрыта дырка с дефолтной темой видимо по причине её (темы) отсутствия

Тема есть, просто я в своё время её дорабатывал

Цитата:

IdeaFix
до 5.10 лучше обновиться

Пардон, а ссылка на таковую существует? На официальном сайте максимальная только 5.9 доступна для загрузки. При этом в доках о десятом релизе указано

Цитата:

IdeaFix
в трансформер для отображения страницы

Что именно Вы имеете в виду?

Цитата:

IdeaFix
зачем яндекс, если гугл теортеически (на jspui практически!) может не меньше, а даже больше?

Я нигде не могу найти как посчитать загрузки файлов репозитория через гугл либо нативную статистику. Посоветовали попытаться через яндекс-метрику. Собственно, только из-за этого попытался связатся с метрикой.
Правда, столкнулся с таким фактом, что все советчики используют именно jspui.

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

[wiki.duraspace.org]
[github.com]

Просто регистрируетесь в гугл аналитике, пишете в конфиг код аналитики и смотрите в консоли аналитики типы файлов. Или я не понимаю проблемы?

Ну а в личке посмотрели, как бывает... у вас до сих пор можно подставить при регистрации в имя юзера путь до скрипта, который выполнится с правами tomcat, но я не люблю демонстрировать эту уязвимость :)

[github.com] вроде как сё описано. Вроде как с разрабами можно даже на вики в полемику вступать, не говоря о списках рассылки...

[elar.rsvpu.ru]

CORE таки запустил "сервис" по подбору полных текстов по DOI. Под JSPUI всё элементарно в плане интеграции, но у меня не хватает ума для кастомизации внешки. Может кто подключится?

Цитата:

IdeaFix
пишете в конфиг код аналитики и смотрите в консоли аналитики типы файлов

Код давно внедрён, учётка в аналитике есть с того самого момента. Но я не вижу возможности анализа аналитики по типам файлов.

Цитата:

IdeaFix
вроде как сё описано.

Так по инструкциям в доках и делал и попал в тупик

[support.google.com]



Редактировано 2 раз. Последний раз 24.07.2019 23:12 пользователем IdeaFix.

[elar.rsvpu.ru]
[elar.rsvpu.ru]


Они присобачили перевод. Думаю, в течении недели-двух добавление функционала таки завершится и появится документация. Тогда же я опишу опыт интеграции в dspace/jspui.

[UPD]

[ideafix.name] - русское описание интеграции CORE Discovery в DSPACE/JSPUI

[blog.core.ac.uk] - оригинальный текст в CORE Blog



Редактировано 1 раз. Последний раз 24.07.2019 23:12 пользователем IdeaFix.

Коллеги, я чего-то туплю, или у новых мавенов изменения в типовых настройках? Не могу собрать измененные искходники. Независимо от типов запуска мавена (mvn package, compile и пр.) мавен игнорирует локальные исходники и выкачивает готовые POM'ы из репозитория. Куда нажать чтобы было как раньше?

Блин, а ведь всё просто...

<useIncrementalCompilation>false</useIncrementalCompilation>



Редактировано 1 раз. Последний раз 04.08.2019 17:48 пользователем IdeaFix.

Коллеги DSpace-воды, а никто из тех, у кого фидбек форма открыта, не ощутил значительного увеличения спам-комментариев?

Пока ни разу не сталкивались со спамом через DSpace. Спамят через форму обратной связи на сайте университета, а библиотека никому не интересна.

Везет.... у меня 20-100 штук в день :( Было (:

[ideafix.name]

Всем день добрый.

Умельцы, подскажите пожалуйста, откуда тянется внешний вид списка документов при выполнении поиска (результирующий список) в xmlui. Я уже сломал мозг и почти клаву, но не понимаю где нужно изменить код.
Цель - сменить стандартный вид списка документов в репозитории. В item-list.xsl сделал соответствующие правки, вид изменился, но только для "Недавно добавленные" и для списка документов в коллекциях. В результирующем списке поиска старый вид. Ума не приложу. Уже запарился экспериментировать. Спасибо заранее

Dspace 5.6, xmlui, Mirage



Редактировано 1 раз. Последний раз 19.09.2019 14:57 пользователем BarsTK.

Вроде как здесь по идее
\DSpaceRepo\dspace-xmlui\src\main\webapp\themes\dri2xhtml-alt\aspect\artifactbrowser\discovery.xsl
Но интерфейс не реагирует

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

woodyfon написал(а):
-------------------------------------------------------
> Если Вы редактируете исходники, необходимо потом
> пересобрать соответтвующую web-мордочку.

Я в курсе. Именно потому, что бы не пересобираться после каждого мелкого изменения, правил .xsl прямо в webapps действующего репозитория. А после того как результат достигнут, делал нормальную сборку. Кстати, с item-list делал аналогично и не встретил проблем. Видимо, в данном случае облом

Закрываю вопрос. Применяется только после пересборки. Печально.
Спасибо откликнувшимуся

Статья по поводу статистики в репозиториях (о том, что нет идеального решения):
[www.tandfonline.com]

Я подумываю о cloaking на скачивание файлов… в статье упоминается, что такое кто-то делал на DSpace. Т. е. поисковикам PDF-ка отдается напрямую, а юзеров переходящих с внешних сайтов кидаем на какую-то промежуточную страницу с JS-кодом Google Analytics.

А если почитать документацию и окажется что с гугл аналитикой это уже реализовано?:)