Текущее время: Пт, июл 18 2025, 15:47

Часовой пояс: UTC + 3 часа


Правила форума


ВНИМАНИЕ!

Вопросы по SAP Query и Quick View - сюда



Начать новую тему Ответить на тему  [ Сообщений: 20 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Оптимизация кода!
СообщениеДобавлено: Чт, июл 17 2014, 13:59 
Начинающий
Начинающий

Зарегистрирован:
Ср, фев 12 2014, 20:42
Сообщения: 8
Добрый день форумчане! Возник такой вопрос по оптимизации Z-программы, прогу кто то писал давно до меня меня попросили разобраться. Хочу услышать какие будут у вас мнения по оптимизации?
Сильно не ругайте я только учусь!
Вот исходный код запроса как было изначально:
Code:
  SELECT  SUM( d~wogbtr ) AS wogbtr  a~aufnr  a~auart b~ingpr c1~anlnr c1~anlun e1~budat d~beknz c1~bukrs

         FROM ( ( ( ( cobk AS e1
         INNER JOIN coep AS d  ON d~kokrs  = e1~kokrs
                               AND d~belnr  = e1~belnr )

         INNER JOIN aufk AS a  ON  a~objnr  = d~objnr )

         INNER JOIN afih AS b  ON  a~aufnr  = b~aufnr )

         INNER JOIN iloa AS c1 ON  c1~iloan  = b~iloan )

  INTO CORRESPONDING FIELDS OF TABLE itab_a

         WHERE  a~auart  IN s_auart  AND
                a~autyp  = '30'      AND
                a~bukrs  = pa_bukrs  AND
                b~ingpr IN  s_ingrp AND
                d~gjahr EQ  pa_gjahr AND
                d~perio  IN  s_perio AND
                d~wrttp  = '04' AND
                d~beknz = 'A'

  GROUP BY a~aufnr  a~auart b~ingpr c1~anlnr c1~anlun e1~budat d~beknz c1~bukrs .

SORT itab_a BY aufnr budat.


  SELECT  SUM( d~wogbtr ) AS wogbtr  a~aufnr  a~auart b~ingpr c1~anlnr c1~anlun e1~budat d~beknz c1~bukrs

         FROM ( ( ( ( cobk AS e1
         INNER JOIN coep AS d  ON d~kokrs  = e1~kokrs
                               AND d~belnr  = e1~belnr )

         INNER JOIN aufk AS a  ON  a~objnr  = d~objnr )

         INNER JOIN afih AS b  ON  a~aufnr  = b~aufnr )

         INNER JOIN iloa AS c1 ON  c1~iloan  = b~iloan )

  INTO CORRESPONDING FIELDS OF TABLE itab_s

         WHERE  a~auart  IN s_auart  AND
                a~autyp  = '30'      AND
                a~bukrs  = pa_bukrs  AND
                b~ingpr IN  s_ingrp AND
                d~gjahr EQ  pa_gjahr AND
                d~perio  IN  s_perio AND
                d~wrttp  = '04' AND
               ( d~beknz = 'S' or d~beknz = 'H' )

  GROUP BY a~aufnr  a~auart b~ingpr c1~anlnr c1~anlun e1~budat d~beknz c1~bukrs .
  SORT itab_s BY aufnr budat.

Изображение

Вот как я переделал:
Code:
  SELECT aufk~aufnr aufk~auart afih~ingpr iloa~anlnr iloa~anlun iloa~bukrs SUM( coep~wogbtr ) coep~beknz cobk~budat
    FROM cobk
      INNER JOIN coep
        ON coep~kokrs  = cobk~kokrs
        AND coep~belnr = cobk~belnr
      INNER JOIN aufk
        ON  aufk~objnr = coep~objnr
      INNER JOIN afih
        ON  aufk~aufnr = afih~aufnr
      INNER JOIN iloa
        ON  iloa~iloan = afih~iloan
    INTO TABLE itab_as
    WHERE aufk~auart IN s_auart
      AND aufk~autyp = '30'
      AND aufk~bukrs = pa_bukrs
      AND afih~ingpr IN  s_ingrp
      AND coep~gjahr EQ  pa_gjahr
      AND coep~perio IN  s_perio
      AND coep~wrttp = '04'
      AND ( coep~beknz = 'A' or coep~beknz = 'S' or coep~beknz = 'H')
    GROUP BY aufk~aufnr  aufk~auart afih~ingpr iloa~anlnr iloa~anlun cobk~budat coep~beknz iloa~bukrs .
  SORT itab_as  BY aufnr budat.
IF sy-subrc = 0.
  LOOP AT itab_as.
    IF itab_as-beknz = 'S' or itab_a-beknz = 'H'.
      APPEND itab_as to itab_s2.
      SORT itab_s2  BY aufnr budat.
    ENDIF.
    IF itab_as-beknz = 'A'.
      APPEND itab_as to itab_a.
      SORT itab_a  BY aufnr budat.
    ENDIF.
  ENDLOOP.
ENDIF.

Изображение
Что оптимизировал:
а) Сделал один запрос вместо двух, которые отличались только последней строкой условия,
б) Убрал INTO CORRESPONDING FIELDS OF

Вот еще один мой вариант оптимизации:
Code:
*Разработка по оптимизации запросов!
*Выборка для AUFK
SELECT aufk~aufnr aufk~auart aufk~objnr afih~ingpr iloa~anlnr iloa~anlun iloa~bukrs
   FROM iloa
   INNER JOIN afih
     ON iloa~iloan = afih~iloan
   INNER JOIN aufk
     ON aufk~aufnr = afih~aufnr
   INTO TABLE it_EXZAMPL
   WHERE aufk~auart  IN s_auart
      AND aufk~autyp  = '30'
      AND aufk~bukrs  = pa_bukrs
      AND afih~ingpr IN  s_ingrp
   GROUP BY aufk~aufnr aufk~auart aufk~objnr afih~ingpr iloa~anlnr iloa~anlun iloa~bukrs.
  SORT it_EXZAMPL BY objnr.

*Выборка для COEP
  SELECT  SUM( coep~wogbtr ) coep~beknz coep~gjahr coep~objnr cobk~budat
    FROM cobk
    INNER JOIN coep
      ON cobk~kokrs  = coep~kokrs
      AND cobk~belnr = coep~belnr
    INTO TABLE it_coep_cobk
    WHERE coep~gjahr = pa_gjahr
      AND coep~perio IN s_perio
      AND coep~wrttp = '04'
      AND coep~beknz IN ('A','S','H')
     GROUP BY coep~beknz coep~gjahr coep~objnr cobk~budat.
  SORT it_coep_cobk BY objnr.
 
*Объединение 2-х запросов в одну таблицу! Не доработано так как не вижу толку от такой оптимизации!
LOOP AT it_coep_cobk.
*  CHECK it_EXZAMPL is NOT INITIAL.
  READ TABLE it_EXZAMPL  INDEX 1.
  IF sy-subrc <> 0.
    IF it_EXZAMPL-objnr = it_coep_cobk-objnr.
      CLEAR wtab3.
      MOVE-CORRESPONDING it_coep_cobk to wtab3.
      APPEND wtab3 TO itab_as.
      DELETE it_EXZAMPL  INDEX 1.
    ELSEIF it_EXZAMPL-objnr <> it_coep_cobk-objnr.
      CONTINUE.
    ELSE.
      EXIT.
    ENDIF.
  ENDIF.
ENDLOOP.

Изображение

Вот как то так! Жду ваших предложений?

Еще добавлю что таблица COEP содержит 6 388 271 записей она содержит 3 индека! Исходный код программы работает около 10 минут а то и вообще может зависать! Пробовал тестит SE30 выдает ошибку привышения размера памяти! в ST12 получил такие результаты:
Моя версия
Изображение
Рабочая версия кода!
Изображение
Кстати результаты всегда разные!


Последний раз редактировалось Bondarenko Aleksey Пт, июл 18 2014, 15:35, всего редактировалось 2 раз(а).

Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Оптимизация кода!
СообщениеДобавлено: Чт, июл 17 2014, 14:04 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
Создайте Range типа coep~beknz (data: r_beknz type range of coep-beknz.), заполняйте его и в Where coep~beknz in r_beknz[].

А вообще для оптимизации запроса смотрите статистику его выполнения (тр. st05), анализируйте использование индексов.

Разбивать JOIN-ы на несколько запросов имеет смысл только для отладки и анализа. Для оптимизации это тупиковый путь, пригодный только в крайних случаях (кластерные таблицы, составные ключи и т.д.). Придерживайтесь принципа: если МОЖНО сделать JOIN, значит НУЖНО его сделать. Меня этот принцип никогда не подводил! Оптимизировать нужно сами условия (where) и индексы.

_________________
"For all entries" не в SAP-ах, "for all entries" в головах! :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация кода!
СообщениеДобавлено: Чт, июл 17 2014, 15:50 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, сен 09 2004, 07:32
Сообщения: 777
Откуда: Москва
Пол: Мужской
Я бы сначала выбрал заказы (например, ракурс БД VIAFKOS), а потом сделал выборку из COEP по индексу с OBJNR ... :roll:

по поводу принципа:
Цитата:
Придерживайтесь принципа: если МОЖНО сделать JOIN, значит НУЖНО его сделать. Меня этот принцип никогда не подводил!

напомню, что SELECT с JOIN'ом заведомо идет мимо буфера DBMS... Так что, для полностью буферизованных таблиц, очевидно, не самое хорошее решение.

_________________
"Прежде чем сделать что-то, подумай, к чему это может привести..."


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Оптимизация кода!
СообщениеДобавлено: Чт, июл 17 2014, 16:51 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
nicky555 написал:
....
напомню, что SELECT с JOIN'ом заведомо идет мимо буфера DBMS... Так что, для полностью буферизованных таблиц, очевидно, не самое хорошее решение.

И "слава богу", что мимо! Для буферизованных таблиц преимущество будет очевидным, только если все таблицы из JOIN буферизованы. В остальных случаях это весьма НЕ очевидно.
Сам факт необходимости буферизации - уже повод задуматься правильно ли структурирован алгоритм. На моей практике приходилось оптимизировать методом буферизации только в случаях г@%нокода, когда чужой Z размазан по системе так, что концов не найдешь.

p.s.
Кстати большое заблуждение называть оптимизацией только улучшение производительности. Для меня оптимизация кода состоит минимум из 3-х частей: скорость, память, читабельность. Они, как "лебедь, рак и щука", невозможно улучшить одно не ухудшив другое. Поэтому оптимизация - баланс, зависящий от конкретной задачи.
Например, у меня были разработки, когда я полностью забивал на оптимизацию скорости и памяти (если вместо 2 мсек, работает 2 сек - несущественно, чаю глотнуть не успеешь :) ) ради максимальной читабельности (ибо постановка мутная, возможны переделки, возможно не мне).

_________________
"For all entries" не в SAP-ах, "for all entries" в головах! :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация кода!
СообщениеДобавлено: Чт, июл 17 2014, 16:55 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пт, сен 23 2005, 11:11
Сообщения: 963
для oracle лучше избегать join на больших таблицах (десятки млн зап.), даже если по индексам,
обычный nested loop в таких случаях не выгоден, быстрее работает две последов. выборки:
- select .. into keys
- select .. for all entries in keys (преобраз.: select .. in (1,2,..,5) union select .. in (6,7..10) union ..)

imho лучше избегать более 2 таблиц в join


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Оптимизация кода!
СообщениеДобавлено: Чт, июл 17 2014, 18:51 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
trop написал(а):
для oracle лучше избегать join на больших таблицах (десятки млн зап.), даже если по индексам,
обычный nested loop в таких случаях не выгоден, быстрее работает две последов. выборки:
- select .. into keys
- select .. for all entries in keys (преобраз.: select .. in (1,2,..,5) union select .. in (6,7..10) union ..)

imho лучше избегать более 2 таблиц в join

Как раз в таких случаях JOIN то, что "доктор прописал". В подобной ситуации у нас всё замечательно решилось индексом, причем даже не новым, а корректировкой убогого Z-индекса.
При этом надо не забывать, что новые индексы могут не сразу "включиться", особенно для больших и часто используемых таблиц - сброс статистики сразу помогает.

Не надо забывать, что INNER JOIN является условием выборки. Т.е. результатом будет пересечение множеств, что сокращает объём передаваемых данных и объём памяти.
select .. into keys - повышает шансы получить дамп из-за нехватки оперативной памяти. Это тоже случай из моей практики. :)

For all entries - настолько частный случай, что просто невозможен в серьезных разработках.
Опять же, в нашем случае, было несколько JOIN-таблиц, в каждой из которых по несколько полей участвовали в условиях выборки in <Select-options>. Оптимизация индексов по результатам тестирования - самый гибкий и эффективный способ, учитывающий реальную потребность пользователей, не требующий модификации кода.
Да и вообще, при грамотном подходе, сам по себе For all entries нифига не быстрее. :)

p.s.
Повторюсь, я за взвешенный подход - баланс между скоростью, памятью и читабельностью (в т.ч. гибкостью к усложнению условий запроса). Всегда можно написать код, который превосходит средневзвешенный по какому-то одному параметру, и в ущерб другим. А посему утверждаю, что JOIN надо рассматривать как правило, которого как минимум нужно придерживаться новичку.
А прочие ухищрения как исключения.

p.p.s.
И не надо обижать Oracle. Он и 10 лет назад триллионами записей ворочал. Хотите насмешить Oracle - расскажите им про внутренние таблицы! :)

_________________
"For all entries" не в SAP-ах, "for all entries" в головах! :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация кода!
СообщениеДобавлено: Чт, июл 17 2014, 19:12 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3080
Откуда: Москва
Parazit написал:
Как раз в таких случаях JOIN то, что "доктор прописал". В подобной ситуации у нас всё замечательно решилось индексом, причем даже не новым, а корректировкой убогого Z-индекса.

Посмотри ноты SAP по поводу MKPF, MSEG и performance ;)
В ERP специально некоторые поля из MKPF в MSEG включили, чтобы избегать JOIN.
Parazit написал:
При этом надо не забывать, что новые индексы могут не сразу "включиться", особенно для больших и часто используемых таблиц - сброс статистики сразу помогает.

Может не сброс, а сбор? :wink:
Каждая новая версия Oracle считает себя все умнее и умнее, чем программист. В результате простые и предсказуемые выборки становятся все более медленными.
И оптимизация может достигаться только с помощью прямых указаний - хинтов :roll:
Parazit написал:
select .. into keys - повышает шансы получить дамп из-за нехватки оперативной памяти. Это тоже случай из моей практики. :)

По практике намного больший эффект на пожирание памяти оказывает копирование внутренних таблиц с последующим DELETE для получения уникальных ключей
Parazit написал:
For all entries - настолько частный случай, что просто невозможен в серьезных разработках....
Да и вообще, при грамотном подходе, сам по себе For all entries нифига не быстрее. :)

FOR ALL ENTRIES по первичному ключу рулит! Если кроме него не накладывается никаких условий :lol:
Parazit написал:
p.s.
Повторюсь, я за взвешенный подход - баланс между скоростью, памятью и читабельностью (в т.ч. гибкостью к усложнению условий запроса). Всегда можно написать код, который превосходит средневзвешенный по какому-то одному параметру, и в ущерб другим.

Согласен. В каждом конкретном случае решение может отличаться.

_________________
С уважением,
Удав.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация кода!
СообщениеДобавлено: Чт, июл 17 2014, 19:49 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
Удав написал(а):
Посмотри ноты SAP по поводу MKPF, MSEG и performance ;)
В ERP специально некоторые поля из MKPF в MSEG включили, чтобы избегать JOIN.

Дык, никто не утверждает, что JOIN ничего не стОит системе. Впрочем сама SAP не образец для подражания. За BSEG убил бы! :)
Удав написал(а):
Может не сброс, а сбор? :wink:

Сброс-Reset-Перезагрузка... :)
Удав написал(а):
Каждая новая версия Oracle считает себя все умнее и умнее, чем программист. В результате простые и предсказуемые выборки становятся все более медленными.
И оптимизация может достигаться только с помощью прямых указаний - хинтов :roll:

До сих пор обходился без хинтов, и всё получалось. Последний раз желание хинта было с версией R/3 4.0, с тех пор пропало. :)
Удав написал(а):
Parazit написал:
select .. into keys - повышает шансы получить дамп из-за нехватки оперативной памяти. Это тоже случай из моей практики. :)

По практике намного больший эффект на пожирание памяти оказывает копирование внутренних таблиц с последующим DELETE для получения уникальных ключей :wink:

Хрен редьки не слаще! И то и другое из порочной практики использования внутренних таблиц где не попадя. :)
Удав написал(а):
FOR ALL ENTRIES по первичному ключу рулит!

Ключи сначала надо выбрать! :)
У меня точно есть ситуация, когда этот приём ухудшает общее время выборки чуть не вдвое. Сначала читаю из BSIS-BSAS ключи по условию, потом дочитываю нужные поля из BSEG. При небольшом количестве выбранных записей - заметный выигрыш. При большом количестве выборки тупой перебор BSEG намного быстрее такой оптимизации. И главное, не знаю как от этого избавиться. Получается, надо прогнозировать объем выборки, хоть свою статистику строй! :)

_________________
"For all entries" не в SAP-ах, "for all entries" в головах! :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация кода!
СообщениеДобавлено: Чт, июл 17 2014, 21:20 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3080
Откуда: Москва
Parazit написал:
Сначала читаю из BSIS-BSAS ключи по условию, потом дочитываю нужные поля из BSEG. При небольшом количестве выбранных записей - заметный выигрыш. При большом количестве выборки тупой перебор BSEG намного быстрее такой оптимизации. И главное, не знаю как от этого избавиться. Получается, надо прогнозировать объем выборки, хоть свою статистику строй! :)

Мы добавляем свои поля в BSIS/BSAS. Твои ФМ по поиску платежей, выравненных со счетами-фактурами и наоборот, стали работать в несколько раз быстрее ;)

_________________
С уважением,
Удав.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация кода!
СообщениеДобавлено: Пт, июл 18 2014, 00:59 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, авг 19 2004, 17:37
Сообщения: 1962
Откуда: Москва
Пол: Мужской
Удав написал(а):
Parazit написал:
Сначала читаю из BSIS-BSAS ключи по условию, потом дочитываю нужные поля из BSEG. При небольшом количестве выбранных записей - заметный выигрыш. При большом количестве выборки тупой перебор BSEG намного быстрее такой оптимизации. И главное, не знаю как от этого избавиться. Получается, надо прогнозировать объем выборки, хоть свою статистику строй! :)

Мы добавляем свои поля в BSIS/BSAS. Твои ФМ по поиску платежей, выравненных со счетами-фактурами и наоборот, стали работать в несколько раз быстрее ;)

Я тоже так делаю для проги анализа выравниваний.
Проблема, которую я описал, проявляется в Оборотке. В ней любые поля BSEG могут быть использованы динамически. Весь BSEG же не потащишь в BSIS-BSAS. :)

_________________
"For all entries" не в SAP-ах, "for all entries" в головах! :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация кода!
СообщениеДобавлено: Ср, июл 30 2014, 08:37 
Начинающий
Начинающий

Зарегистрирован:
Ср, фев 12 2014, 20:42
Сообщения: 8
Спасибо всем за ответы! У меня еще есть вопрос по этому запросу!
Почему при первой прогонки программы она долго работает, а то может и вовсе зависнуть, а при следующих запусках выполняется быстро???


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Оптимизация кода!
СообщениеДобавлено: Ср, июл 30 2014, 09:23 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 15:38
Сообщения: 1257
Цитата:
Почему при первой прогонки программы она долго работает, а то может и вовсе зависнуть, а при следующих запусках выполняется быстро???


Данные выборок кэшируются на разных уровнях. Есть кэш субд. Есть кэш оси. А есть буферизация отдельных таблиц в самом SAP. Хотите получить адекватные замеры производительности - забивайте левыми данными кэш, чтобы все было "как впервый раз". Забить кэш можно через выполнение запроса возвращающего большой объем данных по табле не используемой в тестируемом отчете.

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация кода!
СообщениеДобавлено: Ср, июл 30 2014, 09:40 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пт, сен 23 2005, 11:11
Сообщения: 963
как вариант - добавить в запрос bypassing buffer, или сбросить табл буфер командой /$tab, или писать на native sql


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения: Re: Оптимизация кода!
СообщениеДобавлено: Ср, июл 30 2014, 10:41 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Пн, мар 28 2005, 15:38
Сообщения: 1257
Цитата:
как вариант - добавить в запрос bypassing buffer, или сбросить табл буфер командой /$tab, или писать на native sql


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

_________________
Там, где я рос, единственным развлечением было запоминать число «π».(С) Н. Стивенсон


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оптимизация кода!
СообщениеДобавлено: Ср, июл 30 2014, 11:12 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Чт, окт 06 2005, 16:44
Сообщения: 3080
Откуда: Москва
Кодер написал(а):
Хотите получить адекватные замеры производительности - забивайте левыми данными кэш, чтобы все было "как впервый раз".

Замеры производительности обычно производятся в тестовых системах, в которых при первом запуске с вероятностью ~90% данные не кэшированы, за исключением справочных таблиц.
Поэтому для оптимизации как раз необходимо, чтобы кэш БД был заполнен нужными данными для того, чтобы не искажалась процентные соотношения (например, когда одна таблица находится в кэше, а другая - нет) при измерении.
В продуктивной системе, в которой работают много пользователей, заполнение кэша БД непредсказуемо и повлиять на это мы никак не сможем. Я уже не говорю о том, что продуктивный сервер обычно намного мощнее, чем сервера для тестовых систем.
По этой причине учитывать в измерениях время заполнения кэша БД не имеет практического смысла.

_________________
С уважением,
Удав.


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 20 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB