Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Коллеги, есть непонятная ситуация. HP-UX 11.31 Itanium Memory – 200+ G DB – 10.2.0.5 Size – 10+ Tb Все возможные патчи на БД поставлены. Нагрузка - 1000-1800 (50-100 активных сессий), плюс джобы подготавливающие отчёты, загрузки данных, то-сё… Основное приложение написано на АПЕКС 3.1.2.00.02. Раздельная инсталляция - БД на одном сервере, Апач на другом. После старта экземпляра всё работает нормально, однако через неделю-две производительность сильно снижается! Падает производительность приложений работающих с LOB, а таких у нас большинство. В частности, это проявляется в черезвычайно длительной процедуре заливки новых версий Апекс приложений. Если вначале это минуты, то по прошедствии времени, при деградации производительности с LOB, это длится часами, или вообще не заканчивается. С нашей точки зрения, это следствие всё той же деградации производительности с LOBами. Причина этого явления непонятна. Единственный способ который реально помогает - перегрузка БД. Сами понимаете, что это не метод. При этом это не латчи, и не блокировки - чистое время процессора. Смена TEMP & UNDO tablespace’ов, alter system flush - и другие приседания и камлания эффекта не дают. В инете ничего на эту тему нарыть не удалось. В основном это банальные советы, типа не делайте много мелких изменений LOB, накопите в переменной и пишите максимально большими кусками. Но это не объясняет причину снижения одних и тех же операций с LOB со временем. Конкретный тестовый пример простейший. Берём блок : set timing on; set serveroutput on DECLARE zzz CLOB; xxx CLOB := 'asdasdasdasd'; BEGIN dbms_lob.createtemporary(zzz,TRUE); FOR i IN 1..10000 Loop dbms_lob.append(zzz, xxx); END LOOP; dbms_lob.freetemporary(zzz); EXCEPTION WHEN OTHERS THEN dbms_lob.freetemporary(zzz); RAISE; END; / После старта экземпляра время его выполнения ок. 0.2 с. Темп деградации – примерно в 10 раз в неделю. Через неделю примерно 2 сек., через 2 недели – 10-20 и т.д. Естественно, ждать, пока замедлится на 3-4-5 порядков, возможности нет, приходится экземпляр перезапускать. И опять – всё возвращается к описанной картине. Никакой корреляции с платформой, версией ОС, спецификой АПЕКС, версией БД установить не удалось. Промоделировать ситуацию не удаётся, так как на тестовых серверах не удаётся организовать адекватную нагрузку. Таким образом на тестовых серверах, подобная ситуация не воспроизводится. Уточняю, что тестовая среда на Linux x86_64. Так что нельзя исключать зависимость от платформы. Есть у кого нибудь идеи из-за чего может происходить деградация работы с LOBами, и как с этим бороться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 15:01 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomПадает производительность приложений работающих с LOB, а таких у нас большинство. почему? Зачем ва LOB? VDomЕсть у кого нибудь идеи Завист от того, хотите ли вы работать. Т.е. например, воспроизвести нагрузку на тесте можно многими способами и ПО для этого. Но вы не хотите(. - прочитать ветку про "тормозит" - перейти на версию апекса выше и подтягивать архитектуру под новые версии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 15:21 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDom, Похоже больше на базу, а не на апекс, так что вам скорее в соседний раздел. Может быть сервер или диск перегружены чем-то в это время ? Если интересует сторона апекс, не уверен, что это может влиять напрямую, но рядом - сталкивался с утечкой TEMP памяти при использовании Text Field with autocomplete с опцией Lazy Loading: NO Cессии отжирали неадекватное количество TEMP памяти и отваливались потом с ошибками, отловил в итоге виновника по V$ACTIVE_SESSION_HISTORY. Можно было так же наблюдать рост счетчиков в v$temporary_lobs для APEX_PUBLIC_USER между запросами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 15:51 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDom, Я так понял у вас mod_plsql ? Если не помогают другие средства отладки , и по словарям проблему не получается отследить (с вашими объемами), немного радикальный метод, но можно кильнуть все апексные сессии, они скорее всего должны восстановиться в рамках пула сессий (не помню, как с mod_plsql), но всякая память и ресурсы связанные с ними освободятся. Тогда сможете проверить, помогло или нет и влияют ли здесь утечки. Можно какой-нибудь хитрый job написать, который бы давал сессиям таймаут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 17:04 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDom, А деградация идет только в апексовых сессиях, или в отдельных сессиях такая же картина? Если второе, то ИМХО апекс тут вообще не причем и с этим вопросом надо идти в ветку оракла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 17:27 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Migelle, Если это утечки ресурсов, например PGA или TEMP, другие сессии очень даже могут быть причем. Самым простым способом утечки можно проверить - килянием. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 17:32 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
SvDev, Ну, про ТЕМР автор сам написал, что не помогает. PGA явно проверяли на исчерпание. У нас есть несколько проектов не на апексе, и коннекций сильно поменьше, веб-приложение общается с БД обменом CLOB-ами. Работает иногда годами без перезагрузки и деградации не наступает. Но все работает на 11.2, может 10.2 имеет в себе сей глюк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2017, 21:19 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Migelle, то что ТС писал по поводу TEMP, это не совсем то. Утекшую TEMP память в пуле сессий фиг освободишь без убийства сессии, во всяком случае я не знаю как. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. Тоже самое касается CACHE_LOBS. Настройки в ords типа jdbc.MaxConnectionReuseCount не просто так делают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 10:04 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Коллеги, спасибо всем кто откликнулся. К сожалению текущую работу никто не отменял, а она немаленькая, и оперативно отвечать на предложения не получается. Поэтому отвечу всем сразу. Без LOBов нельзя - логика приложения, хранятся сканы документов. Нагрузку конечно можно попробовать воспроизвести, но для адекватных результатов надо бы и чтобы железо было одинаковое, а его нет. На счёт тестовых серверов. На самом деле тестовые сервера есть разные и на Linux Х_86_64 и на HP-UX Itanium (но железки с Itanium совсем чахлые). Ни на одном из них деградации работы с LOBами не замечено. Правда там и нагрузки нет. Есть идея запустить на самом загруженном сервере наш тест и посмотреть динамику. До сих пор мы этого не делали. Перейти на более новые версии Апекса пока не можем. 5 Апекс например стаёт только на Oracle 12, а вопрос миграции и лицензирования зависит от заказчика. Кроме того, это потребует некоторых ресурсов, человеческих и финансовых, а это опять зависит от заказчиков. Похожий вопрос задан и в общей ветке Oracle. Дисковая система не перегруженна, да и система в целом тоже. Из 48 ядер в среднем занято 40. Не думаю что виноват конкретно Апекс. Скорее всего это общая проблема LOB, а поскольку движок Апекса сам интенсивно работает с LOBами, то это сказывается и на нём. Однако нельзя исключать и того, что из-за интенсивной работы Апекса с LOBами общая нагрузка на LOBы сильно возрастает, и тогда проявляется проблема с LOBами. Да у нас mod_plsql. Регулярно перестартовываем Апачи, когда по разным причинам возростает нагрузка. Нагрузка сразу падает, но дело в том что деградация с течение времени увеличивается. В том числе и ночью когда Апекс нагрузки нет. Так что это врядли зависит от текущей нагрузки Апекса. На счёт темпов и undo. Проверяли так - создавали новое дефаултное ТП, а потом перестартовывали Апачи. Все Апексные сессии отваливались, а потом продолжались с новыми ТП. Никакого влияния на скрипт. Есть некие колебания времени работы скрипта в течении суток, но в целом идёт рост времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 13:15 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDom, Ещё раз, спасибо всем кто откликнулся. Давайте не будем рассматривать работу с таблицами с LOBами, ограничимся нашим тестовым примером. В примере есть только временный LOB. Время выполнения этого скрипта монотонно растёт… Независимо от текущей мгновенной нагрузки на сервере. Насколько я понимаю, ничего, кроме процессора, памяти, хранимых процедур и темпа в нём не используется. Даже относительно ТЕМПа есть сомнения, т.к. темпLOB кэшируем и относительно невелик… Создаётся впечатление, что какие-то структуры управления памятью, выделяемой под ТемпLOBы, не чистятся в процессе работы сервера, монотонно наращивая свой объём из-за чего теряется скорость обработки… Как с этим бороться, непонятно… ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 15:57 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
А если закрывать? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 16:10 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Так же попробуйте отказаться от Кэш, замедлит общий темп, но возможно на длительную работу не скажется. DECLARE zzz CLOB; xxx CLOB := 'asdasdasdasd'; BEGIN dbms_lob.createtemporary(zzz,FALSE); FOR i IN 1..10000 Loop dbms_lob.append(zzz, xxx); END LOOP; dbms_lob.freetemporary(zzz); EXCEPTION WHEN OTHERS THEN dbms_lob.freetemporary(zzz); RAISE; END; / ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 16:12 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 16:13 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDom, «Так же попробуйте отказаться от Кэш, замедлит общий темп, но возможно на длительную работу не скажется.» Увы, время сразу возрастает примерно в 100 раз, что неприемлемо… Кстати, время без кэша растёт примерно в той же пропорции, что и с кэшем. Только по абсолютному значению раз в сто больше… “Сравнить состояние до и после через "AWR : Compare period reports" пробовали? Посмотреть на v$sgastat - если какие-то "структуры управления памятью" растут, может их поискать?” Идея вполне здравая, если бы не… Вот время работы скрипта за сутки выросло раза в полтора… Или за неделю – в десять раз… Что с чем сравнивать? «Сейчас» с «сутки назад» или «неделю назад»? БД-то реально рабочая, за сутки меняется всё… Хотя… Если сохранять СГАСТАТ , скажем раз в 10 минут, а потом вдумчиво смотреть на колебания циферок… Например, выстроить графики по каждому параметру за месяц… Ох, не знаю, не знаю… :-/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 16:58 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomДо сих пор мы этого не делали. сделайте. Это ваша обязанность. ПО для нагрузки есть. VDomно для адекватных результатов надо бы и чтобы железо было одинаковое, а его нет. не надо. Вы и так увидите динамику по памяти и производительности. VDomПерейти на более новые версии Апекса пока не можем. 5 Апекс например можете но не хотите. Апекс 4 от тройки отличается очень сильною. А вот 5 от 4 не сильно. Т.е. вам надо перейти на 4-ку. Либо жолго парить мозги вопросами с тройкой. VDomБез LOBов нельзя - логика приложения, хранятся сканы документов. т.е. вы одной фразой отписались и хотите варианты решения вашей проблемы? КОНКРЕТНЕЕ ЗАЧЕМ ЭТОТ ТИП ПОЛЯ НУЖЕН В ХРАНИМКЕ КРОМЕ ВЫГРУЗИТЬ НА КЛИЕНТА? VDomПохожий вопрос задан и в общей ветке Oracle. ссылку пожалуйста. Может мы по второму кругу обсуждам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 21:50 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomДавайте не будем рассматривать работу с таблицами с LOBами, ограничимся нашим тестовым примером. тогда это вопрос чисто ветки оракла. Дайте ссылку на то обсуждение. Апекс ни при чём вроде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2017, 21:54 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Деградация носит кумулятивный характер, поэтому надо понять что может иметь кумулятивный характер, и может ли это быть связанно с операциями с LOB. С моей точки зрения это : 1) сегментация TEMP табличного пространства - замена табличного пространства TEMP на другое ничего не даёт поэтому этот фактор исключаем 2) рост swap памяти - проверка показала что свопа нет и он не растёт 3) переполнение каких то счётчиков, или семафоров - В HP-UX есть заклинание kcusage показывающее пороговые значения и текущие Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. Из приведённого только filecache_max наводит на размышления. Он достиг 12156600320 при пороге 12197325864. Разница 40 725 544. Вроде много, но это 0,34% !! Это настораживает. Вообщето в БД у нас 187 ТП, а у них 592 файла. И это без всяких других файлов БД (онлайн журналов и т.д.). Непонятно только как это может влиять на LOB. 4) сегментация памяти - мне кажется что это кандидат №1 Поясню почему. Есть такое понятие как управление большой памятью. Памяти у нас действительно много, и я даже не всю её использую. System Page Size: 16Kbytes Memory: 261149792K (137296352K) real, 265148832K (139316016K) virtual, 105355568K free Page# 1/893 В связи с этим вспоминаем что есть такая вещь как HugePages, которую как раз и рекомендуется использовать при большой памяти. То есть при старте память для Oracle сразу выделяется одним непрерывным куском, а внутри этого куска управление памятью выполняется максимально большими страницами. Всё это хорошо описано, и я неоднократно это настраивал но под Linux. Специалисты по HP-UX говорят что в HP-UX нет понятия HugePages и что там всё изначально делается правильно?? Но как? Толком мне никто этого так и не пояснил. В инете есть какие то упоминания о HugePages и HP-UX но ничего конкретного. Складывается впечатление, что какие то структуры управляющие за управление памятью, с течением времени заполняются, в результате чего начинаются тормоза. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 10:38 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
В общей ветке это тема "Деградация производительности при работе с LOB" http://www.sql.ru/forum/1262261/degradaciya-proizvoditelnosti-pri-rabote-s-lobami Но в ветке Апекса намного больше предложений. С переходом на новые версии Апекс не всё так просто. Есть договор, в котором указано чего и какой версии должно быть. В любом случае это решает заказчик, а его этот вопрос меньше всего волнует. Кстати мы пробовали и 4 и 5 Апекс, так что мы готовы, но. Приложение и написано для работы со сканами разных документов, в этом его смысл. На самом деле мы вынесли из БД часть сканов (большую часть) в так называемый файловый архив. Но проблема с LOB никуда не делась и не ушла. Кроме того не забываем что у Апекса вся работа с файлами - загрузка/выгрузка, и собственно залмвка приложений всё идёт через таблицу WWV_FLOW_DATA с ITEM_VALUE CLOB. Учитывая интенсивное использование приложений на апексе так или иначе возрастает работа с LOB. Возможно достигается какой то порог, после чего начинаюся проблемы с LOB. Хотя да, в этом случае это проблема БД, но не без участия Апекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 11:29 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomВсе Апексные сессии отваливались, а потом продолжались с новыми ТП. т.е. прямое влияние апекса вы исключили, и всё говорит о том, что апекс ни при делах, проблема где-то на уровне базы в целом. Свидетельств косвенного влияния вы не продемонстрировали, апекс используется как прослойка и лишь в части функционала. Я так понимаю, свидетельств, что виновата загрузка или выгрузка нет, я бы, например, подозревал манипуляции с Persistent LOBs и, в том числе, другие опции. Похоже на какой-нибудь баг. VDomДавайте не будем рассматривать работу с таблицами с LOBами, ограничимся нашим тестовым примером. Если бы все было так просто, вы бы сами проблему легко воспроизвели, но тестовый пример проблемы роста времени выполнения, я так понимаю, не воспроизводит. Это значит, что виновато что-то что рядом, а рядом много чего, в SecureFiles and Large Objects Developer's Guide много красивых слов и опций, которые могут стрелять, например, только в комбинации, при наличии соответствующих багов на уровне оракла. Соответственно, я не вижу сейчас смысла смотреть проблему в привязке к апексу, с учетом, что нет свидетельств, которые явно указывали бы на апекс, или что апекс ограничивает как-то отладку проблемы, которая проявляется на уровне базы и имеет общий характер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 12:37 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomНо в ветке Апекса намного больше предложений. но честнее было сразу сказать, что апекс ни при чём и дать ссылку). VDomПриложение и написано для работы со сканами разных документов, в этом его смысл. ну а апекс заточен на файловый архив. Есть разница? VDomКроме того не забываем что у Апекса вся работа с файлами - загрузка/выгрузка, и собственно залмвка приложений всё идёт через таблицу WWV_FLOW_DATA с ITEM_VALUE CLOB. не понял. Я сразу перебрасываю сканы в свою таблу. Никаких ваших ТАКИХ хранимок нету. Что я делаю не так? VDomУчитывая интенсивное использование приложений на апексе так или иначе возрастает работа с LOB. Мы про архитектуру вроде? Тогда огласите юз-кейс такой работы. Возможно вы апекс используете не по назначению....при баге в самой СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 13:08 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
SDev Да прямой связи с Апексом нет. Но косвенное очень даже может быть. Об этом я уже писал. То есть сам движок Апекса очень интенсивно работает с LOB. Поэтому Апекс скорее катализатор а не причина, причина гдето в БД. Мы тоже думаем что это может быть баг. Но реквесты, я создавать не могу. Да и даже если бы мог - Oracle 10 уже не поддерживается. Почему мы сосредоточились на тестовом примере. Во первых это объективный критерий по которому можно оценивать снижение производительности при работе с LOBами. По времени срабатывания скрипта можно понять что БД пора перегружать. Во вторых можно отбросить вопросы связанные с таблицами, их параметрами хранения и т.д. и т.п. И даже в этом упрощонном примере непонятны причины. У нас 10 БД поэтому SecureFiles нет. И всё таки какая то коссвенная связь между Апексом и производительностью работы с LOB есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 13:50 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomПочему мы сосредоточились на тестовом примере. прогоните тесты на новых версиях БД и апекса. Установка апекс 30 минут и установка БД 2,5 часа на ноуте. С третьей версией апекса уже никто реально не работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 13:56 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomИ всё таки какая то коссвенная связь между Апексом и производительностью работы с LOB есть. Если бы у вас были какие-нибудь объективные данные для этого утверждения, демонстрация связи запросами с проблемного сервера не было бы такой большой проблемой. Легко обвинить часть приложения, о которой не всё знаешь, но тем не менее это не конструктивный подход. Апекс действительно много работает с CLOB/BLOB и на уровне item в том числе, но и вы сами наверняка тоже с большими объемами LOB работаете. Часть с апекс отлажена большим числом людей с разными архитектурами приложений и pl/sql, часть с вашим приложением ограничена только вашей архитекторой с вашим кодом и отлажена хуже, чем apex сотрудниками oracle во всевозможных ситуациях. Тестовый пример никак не связан с апекс, поэтому, как минимум, я предлагаю вам собрать больше данных в другом разделе, чтобы появился хоть какой-то смысл смотреть конкретно что-то в привязке к апекс. Прочего рода совета намного рациональнее обсуждать в разделе oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 14:44 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
Petro123 Дело в том что на всех наших тестовых серверах, и на IA64 и на x86_64, время работы нашего тестового скрипта не растёт. Так что нет смысла пробовать на других версиях БД или Апекса. На некоторых тестовых серверах даже работы выполняются, но нагрузка не соизмеримая. Видимо дело всё таки в нагрузке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 17:44 |
|
||
|
Замедление заливки приложений APEX
|
|||
|---|---|---|---|
|
#18+
VDomДело в том что на всех наших тестовых серверах, и на IA64 и на x86_64, время работы нашего тестового скрипта не растёт. странно у вас с логикой. Это ваше: авторПромоделировать ситуацию не удаётся, так как на тестовых серверах не удаётся организовать адекватную нагрузку. говорит что тестовой площадки нормальой у вас НЕТ. Вы не умеете её готовить. А вы пишите что время скрипта не растёт. Обычна лень. Уж извините. Поэтому у вас даже у себя....без заказчика нет четвёрки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2017, 20:22 |
|
||
|
|

start [/forum/topic.php?fid=50&msg=39466949&tid=1874320]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
180ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 296ms |

| 0 / 0 |
