Не работает each

Общие вопросы по использованию второй версии фреймворка. Если не знаете как что-то сделать и это про Yii 2, вам сюда.
skynin
Сообщения: 400
Зарегистрирован: 2017.12.12, 10:09

Re: Не работает each

Сообщение skynin »

zelenin писал(а): 2018.07.27, 14:10
skynin писал(а): 2018.07.27, 14:05то есть, вы уверенно заявляете что ЛЮБОЙ сервер возращает ВСЕ байты результата в ответ на запрос, и только драйвер к серверу - отдает их порциями?
не драйвер отдает порциями, а драйвер принимает порциями.

Открывается tcp/ip соединение, сервер начинает отдавать байты, клиент их принимает.
Вы не ответили на вопрос

Конечный, итоговый результат запроса - 10 000 байт.

драйвер когда шлет запрос
может сказать
дай 1000, а остальное, если попрошу.

так вот вопрос на ваше
это уже фича драйвера либо более высокоуровневой надстройкой над драйвером

никакой сервер в БД не умеет так работать, а будет всегда слать 10 000 байт?
zelenin писал(а): 2018.07.27, 14:10 Вы когда хттп-клиентом страницу скачиваете, у вас клиент принимает данные или сервер пушит данные на клиента?
то есть сервер может пушить данные, а клиент их категорически не принимает?
или как у вас это - раздельные процессы
пуш от сервера клиенту - прием данных от сервера клиентом?
Не желайте странного, и не будет у вас головной боли чтобы достичь этого странного.
Тем более что окажется что оно вам и не нужно было, странное это.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Не работает each

Сообщение zelenin »

skynin писал(а): 2018.07.27, 14:19 то что мы обрабатываем каждую модель друг за дружкой, потому что у нас однопоточный движок php никак не устраняет того что мы обычно обрабатыватаем в итоге - ВСЕ модели.
выводя в грид, я вывожу все модели, но по одной. разница есть.
skynin писал(а): 2018.07.27, 14:19так какой смысл их запрашивать по одной, с заходом выполнения в глубины драйвера БД, а то и к самой БД, если все аж 50 штук мы получим разом одним all()?
я говорю нет смысла запрашивать все через all, а вы говорите какой смысл, если запрашиваем через all.
skynin писал(а): 2018.07.27, 14:19 огромное - это сколько?
относительно неогромного. считаем в разах.
skynin писал(а): 2018.07.27, 14:19 в каком проекте?
что дает в этом проекте - экономия этого потребления?
влезаем в лимит по памяти на сервере.
skynin писал(а): 2018.07.27, 14:19и зачем запрашивается сразу 1000? вывести всю тысячу пользователю?
обсчитать что-то
skynin писал(а): 2018.07.27, 14:19 не пробовал, а как итератор отработает классику:
ArrayHelper::index($posts, 'id')
проитерируется, превратив итератор в массив.

skynin писал(а): 2018.07.27, 14:19 и при таком сценарии у нас в памяти будут одновременно висеть все 1000 моделей.
да

skynin писал(а): 2018.07.27, 14:19 то есть создание массива из 1000 моделей с помощью итератора это не одно и тоже потребление памяти
чем запросить его с помощью all()
одно и то же. но получив итератор, мы можем с ним обойтись максимально эффективным образом для вашего юзкейса. Получив массив, мы уже ничего не сделаем.
skynin писал(а): 2018.07.27, 14:19эта догма в вашем же примере не спасает от 1000 моделей в памяти одновременно.
эта "догма" дает вам право выбора - выбрать из итератора массив либо обработать по одному. Массив же этого выбора не дает.
skynin
Сообщения: 400
Зарегистрирован: 2017.12.12, 10:09

Re: Не работает each

Сообщение skynin »

zelenin писал(а): 2018.07.27, 15:17 выводя в грид, я вывожу все модели, но по одной. разница есть.
сколько байт сэкономили ;)

и, я же сразу писал что сценарии работы с данными могут быть - разными.
zelenin писал(а): 2018.07.27, 15:17 я говорю нет смысла запрашивать все через all, а вы говорите какой смысл, если запрашиваем через all.
вы несколько раз написали "всегда".
а это признак догмы.
потому что
сценарии работы с данными - бывают разные
выбирать инструмент и подход стоит - вдумчиво, а не догматически.
zelenin писал(а): 2018.07.27, 15:17 относительно неогромного. считаем в разах.
в типичном гриде до полусотни строк.

согласен, между 1ним байтом и 1000 - разница в тысячу раз!

так сколько вы памяти экономите на выводе сущностей в грид?
zelenin писал(а): 2018.07.27, 15:17 влезаем в лимит по памяти на сервере.
и какой у вас лимит по памяти на сервере?
64 мб?
так может пора сменить хостинг, а не экономить на спичках?
zelenin писал(а): 2018.07.27, 15:17
skynin писал(а): 2018.07.27, 14:19 не пробовал, а как итератор отработает классику:
ArrayHelper::index($posts, 'id')
проитерируется, превратив итератор в массив.
то есть памяти съест столько же сколько и после all()

значит, если на хостинге "64 мб" - each() вместо all() - не поможет.
zelenin писал(а): 2018.07.27, 15:17одно и то же. но получив итератор, мы можем с ним обойтись максимально эффективным образом для вашего юзкейса.
для моего - это какого?
еще раз - если в памяти будет такого же размера массив в конце итерации - то какая разница как мы его получили?
zelenin писал(а): 2018.07.27, 15:17 Получив массив, мы уже ничего не сделаем.
обычно ограничивать количество обрабатываем данных нужно на стороне сервера - условием запроса.

но - сценарии работы с данными - бывают разные
если надо для десятков тысяч позиций товара изменить цену, то да, тянуть их все в память нет смысла.
и рисково.
и лучше фиксировать не одной жирной транзакцией.
и т.д.
zelenin писал(а): 2018.07.27, 15:17эта "догма" дает вам право выбора - выбрать из итератора массив либо обработать по одному. Массив же этого выбора не дает.
я выбираю подход - когда пишу код.
а писать всегда each - это догма.
которая частенько никакой выгоды не дает.
а еще надо бы замерить тормоза по оверхеду.

если два инструмента, подхода дают одинаковый результат - то выбирать нужно тот что более простой.
у меня вот такое прагматичное правило.
а выбирать что-то потому что хочется сэкономить на спичках, или потому что будет какой-то выбор потом (то есть выбирать преждевременную оптимизацию) - это догма
Не желайте странного, и не будет у вас головной боли чтобы достичь этого странного.
Тем более что окажется что оно вам и не нужно было, странное это.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Не работает each

Сообщение zelenin »

skynin писал(а): 2018.07.27, 14:24никакой сервер в БД не умеет так работать, а будет всегда слать 10 000 байт?
драйвер откроет соединение, отошлет в него запрос, дальше в рамках этого соединения сервер будет писать байты, пока открыто соединение.

Итоговое кол-во байтов (10000) известно заранее, только если серверу выгодно сразу прочитать весь ответ в буфер, из которого их будет отдавать клиенту.
skynin писал(а): 2018.07.27, 14:24то есть сервер может пушить данные, а клиент их категорически не принимает?
есть сервер который пишет данные, есть клиент который их вычитывает. Очевидно, что в клиента нельзя данные запихнуть если он прекратит по какой-то своей логике вычитывать данные из потока. Сервер продолжит писать данные в канал, пока они буферизуются на хосте, ожидая вычитки клиентом.
skynin
Сообщения: 400
Зарегистрирован: 2017.12.12, 10:09

Re: Не работает each

Сообщение skynin »

zelenin писал(а): 2018.07.27, 16:25
skynin писал(а): 2018.07.27, 14:24никакой сервер в БД не умеет так работать, а будет всегда слать 10 000 байт?
драйвер откроет соединение, отошлет в него запрос, дальше в рамках этого соединения сервер будет писать байты, пока открыто соединение.
я не зря дважды спросил - вы про любой драйвер и любую БД?
читаем например:
Fetch Buffer Size - The amount of memory used to determine how many rows of data the ODBC Driver prefetches at a time from an Oracle database regardless of the number of rows the application program requests in a single query. However, the number of prefetched rows depends on the width and number of columns specified in a single query. Applications that typically fetch fewer than 20 rows of data at a time improve their response time, particularly over slow network connections or to heavily loaded servers. Setting Fetch Buffer Size too high can make response time worse or consume large amounts of memory.
из "Using the Oracle ODBC Driver"
гугл транслейт переведет нормально.

про PDO тоже есть. но не так четко. плюс есть разные версии для Оракла. и есть которые эмулируют, а не честно запрашивают порционно.

так что вы малость преувеличили свои знания :)

обычное дело, только с Мускулом имели дело, вот и не в курсе про "любую базу данных".

а могли бы сами погуглить, раз я так настойчиво спрашивал ;)
zelenin писал(а): 2018.07.27, 16:25 Итоговое кол-во байтов (10000) известно заранее, только если серверу выгодно сразу прочитать весь ответ в буфер, из которого их будет отдавать клиенту.
не обязательно. зависит от реализации - сервера БД, драйвера БД и кучи неизвестных в общем случае факторов тонкостей их алгоритмов.

но думаю что разговор об открытых курсорах в рамках открытого соединения в серьезных БД точно будет моим монологом.
zelenin писал(а): 2018.07.27, 16:25Сервер продолжит писать данные в канал, пока они буферизуются на хосте, ожидая вычитки клиентом.
я рассказал в этой теме о том, чего возражающие мне не поняли, но решили поучить или уличить в незнании :)

цитировать себя не вижу смысла.

просто понимаете, я пришел в веб разработку из мира Джавы.
где то что я рассказал требуют на собеседовании уже на мидла, в рамках - а теперь поговорим о JDBC

то что php программисты с этим не сталкиваются, потому что - модель вычислений "рождаться чтобы умирать" и потому что нечасты задачи обрабатывать на клиенте массивы данных точно превышающих ОЗУ, и потому что для большинства синоним - сервер БД это конечно MySQL - не удивительно.

поэтому и неудивительно что в программерской тусовке более невежественными в программировании считают только 1Сников.
а потом конечно - "пыхеров"

на одном из докладов ко мне в кулуарах даже подошел парень как-то, с удивлением, - я вообще-то джавист, пришел просто послушать, но вы такое рассказывали... вы ж на php пишите? а почему тогда пыхеров считают недопрограммерами?

вот в эту тему и послал бы :)
Не желайте странного, и не будет у вас головной боли чтобы достичь этого странного.
Тем более что окажется что оно вам и не нужно было, странное это.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Не работает each

Сообщение zelenin »

skynin писал(а): 2018.07.27, 15:39еще раз - если в памяти будет такого же размера массив в конце итерации - то какая разница как мы его получили?
еще раз. метод у вас может быть один, а юзкейсов десятки. плодить разные методы потому что здесь мне нужны 10 объектов, а здесь проитерироваться по сотне тысяч можно, но я предпочту несложную унификацию, благо из итератора я всегда могу получить массив одной функцией, а не из массива ресурс нет.

Получить массив действительно проще. Точнее понять что такое массив. Это понятно всем пхпшникам, большинству которых слово итератор не знакомо. В других же высокоуровневых и не очень языках итераторы по всюду, и порой вариантов выбрать из базы массив даже нет. Настройка заведомо на эффективность, быстродействие и качество.
skynin
Сообщения: 400
Зарегистрирован: 2017.12.12, 10:09

Re: Не работает each

Сообщение skynin »

zelenin писал(а): 2018.07.27, 16:44
skynin писал(а): 2018.07.27, 15:39еще раз - если в памяти будет такого же размера массив в конце итерации - то какая разница как мы его получили?
еще раз.
еще раз - вы уверенно показали что даже не поняли о чем речь.
zelenin писал(а): 2018.07.27, 16:44 В других же высокоуровневых и не очень языках итераторы по всюду
на каких языках профессионально писали?
хотите обсудить стримы в той же Джаве?
особенно про оверхед многопоточных итераторов.
уверены?
zelenin писал(а): 2018.07.27, 16:44 Настройка заведомо на эффективность, быстродействие и качество.
Настройка заведомо на эффективность, быстродействие - это у новичков болезнь просто.
Хотя на практике важней ясный код, наличие тестов и т.д.
а эффективность и быстродействие в большинстве случаев решаются либо вертикальным или горизональным масштабированием, либо изменением 5%-10% кода
и догма - пиши всегда each() - не поможет, когда такой случай настанет. просядет обычно в другом месте.

и уж точно это не тот код что выводит что-то там в гриды будет проблемой :D
Не желайте странного, и не будет у вас головной боли чтобы достичь этого странного.
Тем более что окажется что оно вам и не нужно было, странное это.
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Не работает each

Сообщение zelenin »

skynin писал(а): 2018.07.27, 16:42Fetch Buffer Size - The amount of memory used to determine how many rows of data the ODBC Driver prefetches at a time from an Oracle database regardless of the number of rows the application program requests in a single query. However, the number of prefetched rows depends on the width and number of columns specified in a single query. Applications that typically fetch fewer than 20 rows of data at a time improve their response time, particularly over slow network connections or to heavily loaded servers. Setting Fetch Buffer Size too high can make response time worse or consume large amounts of memory.
из "Using the Oracle ODBC Driver"
и? базы данных вольны делать любые оптимизации, что не отменяет того, что они все делают поверх стрима tcp/ip. Хочешь по одной строке обрабатывай и передавай дальше, хочешь предвыбери (prefetch) строк в буфер, ограниченный Fetch Buffer Size, и отдавай дальше.
PDO вообще-то тоже буферизует пул строк, если передать FETCH_ALL.
skynin писал(а): 2018.07.27, 16:42обычное дело, только с Мускулом имели дело, вот и не в курсе про "любую базу данных".
а могли бы сами погуглить, раз я так настойчиво спрашивал ;)
ой, ну не начинайте вот этого, не дите ведь.
skynin писал(а): 2018.07.27, 16:42 не обязательно. зависит от реализации - сервера БД, драйвера БД и кучи неизвестных в общем случае факторов тонкостей их алгоритмов.
"серверу выгодно" = "зависит от реализации".
skynin писал(а): 2018.07.27, 16:42 просто понимаете, я пришел в веб разработку из мира Джавы.
где то что я рассказал требуют на собеседовании уже на мидла, в рамках - а теперь поговорим о JDBC

то что php программисты с этим не сталкиваются, потому что - модель вычислений "рождаться чтобы умирать" и потому что нечасты задачи обрабатывать на клиенте массивы данных точно превышающих ОЗУ, и потому что для большинства синоним - сервер БД это конечно MySQL - не удивительно.
это же ровно о том, о чем я написал в предыдущем своем сообщении?)
skynin писал(а): 2018.07.27, 16:42 поэтому и неудивительно что в программерской тусовке более невежественными в программировании считают только 1Сников.
а потом конечно - "пыхеров"

на одном из докладов ко мне в кулуарах даже подошел парень как-то, с удивлением, - я вообще-то джавист, пришел просто послушать, но вы такое рассказывали... вы ж на php пишите? а почему тогда пыхеров считают недопрограммерами?

вот в эту тему и послал бы :)
ой, господи. Я-то думал вы пыхер, а вы, боже, джавист.
И вот с такой позиции полубога вам кажется, что кого бы вы не встретили вам дано право поучать.
Но на секундочку у меня в коммерческом продакшне сервисы на 5 языках, из которых php не основной почти 5 лет.
skynin
Сообщения: 400
Зарегистрирован: 2017.12.12, 10:09

Re: Не работает each

Сообщение skynin »

zelenin писал(а): 2018.07.27, 17:13 и? базы данных вольны делать любые оптимизации
ну так перечитайте тему где мне стали рассказывать, в частности ВЫ - что не бывает таких оптимизаций.

про догму которая не спасает хоть поняли. и то круто :)
zelenin писал(а): 2018.07.27, 17:13 ой, господи. Я-то думал вы пыхер, а вы, боже, джавист.
пыхер это вы.
а я просто программист который последние годы пишет на php и на js.
до этого на Джаве, 1С, BP, С, assembler'e. профессионально в смысле, когда деньги платят.
zelenin писал(а): 2018.07.27, 17:13 И вот с такой позиции полубога вам кажется, что кого бы вы не встретили вам дано право поучать.
да что вы - наоборот, это меня поучать норовят :D

а я просто коплю вопросы для предстоящих собеседований.
а то возьмешь - а чел весь в догмах, и при этом не понимает разницу между уровнями протоколов
и все "блещет" знаниями "что они все делают поверх стрима tcp/ip"
ты ему про прикладной уровень - а он тебе про транспортный :D
zelenin писал(а): 2018.07.27, 17:13 Но на секундочку у меня в коммерческом продакшне сервисы на 5 языках, из которых php не основной почти 5 лет.
а о чем речь так и не поняли :D
Не желайте странного, и не будет у вас головной боли чтобы достичь этого странного.
Тем более что окажется что оно вам и не нужно было, странное это.
Ответить