Я уже разобрался.

какой фантазёр :)

Как это “не требуется интерпретация”, а что по твоем PHP делает?

Я имею ввиду, что заинклюдив массив, тебе не нужно его десериализовать, к примеру.

Опять же, что, по твоему, делает PHP интерпретатор?

Он десериализует файл в синтаксическое дерево, а потом во оп коды

Блин

если я храню данные в sql в частности если храню там массив PHP то я его вначале сериализую - это время

С какой базой производились сравнения? Производились ли сравнения с array vs json?

затем когда я считываю из базы сериализованный массив - я его десеарилизую

С какой базой производились сравнения? Производились ли сравнения с array vs json?

mysql

еще раз, любая конвертация текста в структуру есть десериализация, пусть то json или .php

записать массив в файл и считать его - быстрее чем записать массив данных и считать его через mysql

mysql

ахаха, не осилил документацию по json xDDD

Были ли сравнения с nosql базами

Дмитрий, я поделился "горьким опытом" в отношении фии include() Ты всё упираешь на архитектуру. Я в любой архитектуре могу найти недостатки, и, думаю, ты тоже. Но от этого, утекать памяти через include() меньше не станет.

Дмитрий, я поделился "горьким опытом" в отношении фии include() Ты всё упираешь на архитектуру. Я в любой архитектуре могу найти недостатки, и, думаю, ты тоже. Но от этого, утекать памяти через include() меньше не станет.

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

Столкнулся с проблемой такой, использую Laravel & jwt-auth и теперь понимаю что использовать jwt не получится в web, Но мне нужно как то сделать middleware для роутов /admin, и получается нужна сессия что бы не пускать ненужных пользователей туда, сама админка тоже устроена как SPA и юзает jwt что бы общаться с сервером, и вот теперь делема как решить вопрос, Видал решения хранить в куках jwt_token но уж что то мне кажется это огромным костылем.

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

я скрипт в 5 строк выше скинул. запусти и убедись)

я скрипт в 5 строк выше скинул. запусти и убедись)

я тебе свой ник подарю, нельзя быть настолько ......

Архитектура всега во главе. Если ты выбираешь архитектуру с использованием механизмов явно не предназначенных для того, что ты делаешь, а include не предназначен для подгрузки данных, он предназначен для загрузки кода, то ты должен это очень весомо обосновать. Ты выбрал решение, которые выглядит неверным с первого взгляда, ты не провел полный ресерч, что бы обосновать ошибочность первого взгляда, закономерно наступил на какие-то грабли и рассказываешь нам про них. На что тебе закономерно говорят, что ты выбрал неверный путь.

Архитектура всега во главе. Если ты выбираешь архитектуру с использованием механизмов явно не предназначенных для того, что ты делаешь, а include не предназначен для подгрузки данных, он предназначен для загрузки кода, то ты должен это очень весомо обосновать. Ты выбрал решение, которые выглядит неверным с первого взгляда, ты не провел полный ресерч, что бы обосновать ошибочность первого взгляда, закономерно наступил на какие-то грабли и рассказываешь нам про них. На что тебе закономерно говорят, что ты выбрал неверный путь.

Дмитрий, это ты рассуждаешь об архитектуре. Я говорю о функции include, о том, что она может завалить скрипт в случае включения большого количества файлов, тестик не поленился сбросил, повторяю:

for($i = 0; $i < 100000; $i++){ $df = fopen($i.".txt", "w"); fclose($df); include($i.".txt"); unlink($i.".txt"); } // fr

Я не пытался доказать, что моя архитектура лучше, чем какая-то другая - боЗе упаси, как написал выше в любой архитектуре есть недостатки. И разговор, повторюсь, не об архитектурах)

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

Такое вот обучение

Если оно тебе не нужно - игнорируй. Если ты, как будучи опытный программист видишь решение, или изъян - так поделись. Ну это как по мне. У тебя, видимо, архитектура психологии другая.

Всем привет. Возможно, вы слышали про October CMS – самую популярную CMS, построенную на базе Laravel Framework. Сегодня стартовала кампания по выводу October CMS в GitHub Trends. Вы можете помочь в этом просто поставив звезду репозиторию проекта https://github.com/octobercms/october. Репозиторию необходимо набрать не менее 100 звёзд за сутки, чтобы добиться этой цели. ? Заранее благодарю за помощь неравнодушных. ?

for($i = 0; $i < 100000; $i++){ $df = fopen($i.".txt", "w"); fclose($df); include($i.".txt"); unlink($i.".txt"); } // fr

ты понимаешь не удивляешься что код $s = 1; занимает больше 1 байта памяти в php, а работа include сразу УТЕЧКА ПАМЯТИ!!! есть накладные расходы по cpu, ram, io при использовании php, в том числе и для функций.

Всем привет. Возможно, вы слышали про October CMS – самую популярную CMS, построенную на базе Laravel Framework. Сегодня стартовала кампания по выводу October CMS в GitHub Trends. Вы можете помочь в этом просто поставив звезду репозиторию проекта https://github.com/octobercms/october. Репозиторию необходимо набрать не менее 100 звёзд за сутки, чтобы добиться этой цели. ? Заранее благодарю за помощь неравнодушных. ?

никода не слышал о такой - значит сверх популярная :)))

Всем привет. Возможно, вы слышали про October CMS – самую популярную CMS, построенную на базе Laravel Framework. Сегодня стартовала кампания по выводу October CMS в GitHub Trends. Вы можете помочь в этом просто поставив звезду репозиторию проекта https://github.com/octobercms/october. Репозиторию необходимо набрать не менее 100 звёзд за сутки, чтобы добиться этой цели. ? Заранее благодарю за помощь неравнодушных. ?

в папке контроллеров лежат html'ки? серьезно? ;) https://github.com/octobercms/october/blob/master/modules/system/controllers/requestlogs/index.htm =)

ты понимаешь не удивляешься что код $s = 1; занимает больше 1 байта памяти в php, а работа include сразу УТЕЧКА ПАМЯТИ!!! есть накладные расходы по cpu, ram, io при использовании php, в том числе и для функций.

Успокойся.

Успокойся.

я 2 дня в чате читаю бред про тупость с include, стоит и меня послушать :)

никода не слышал о такой - значит сверх популярная :)))

7350 звёзд без накрутки на гитхабе это мало? Наибольшая экосистема плагина среди всех ларавеловских cms. ?

никода не слышал о такой - значит сверх популярная :)))

Но вот потому и хотим вывести в тренды проект ?

7350 звёзд без накрутки на гитхабе это мало? Наибольшая экосистема плагина среди всех ларавеловских cms. ?

вот нарутка идет, прямо сейчас!

вот нарутка идет, прямо сейчас!

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

в папке контроллеров лежат html'ки? серьезно? ;) https://github.com/octobercms/october/blob/master/modules/system/controllers/requestlogs/index.htm =)

здесь контроллерами назввается не то, что в ларавеле. контроллеры в OctoberCMS - это классы для работы страниц админки и рядом с ними лужат конфиги и верстка админки а в ларавеле это обработчики урлов

Если оно тебе не нужно - игнорируй. Если ты, как будучи опытный программист видишь решение, или изъян - так поделись. Ну это как по мне. У тебя, видимо, архитектура психологии другая.

решение - не использовать файлы, использовать базу если большой поток мелких запросов по ключу - использовать nosql базу или mysql handlersocket

В качестве решения проблемы оверпамяти этого скрипта: for($i = 0; $i < 100000; $i++){ $df = fopen($i.".txt", "w"); fclose($df); include($i.".txt"); unlink($i.".txt"); } // fr ты предлагаешь "не использовать файлы, использовать базу если большой поток мелких запросов по ключу - использовать nosql базу или mysql handlersocket" Хорошо, я понял тебя. Правда, боюсь, что вариант твоего решения в данном случае не подходит. Но спасибо.

В качестве решения проблемы оверпамяти этого скрипта: for($i = 0; $i < 100000; $i++){ $df = fopen($i.".txt", "w"); fclose($df); include($i.".txt"); unlink($i.".txt"); } // fr ты предлагаешь "не использовать файлы, использовать базу если большой поток мелких запросов по ключу - использовать nosql базу или mysql handlersocket" Хорошо, я понял тебя. Правда, боюсь, что вариант твоего решения в данном случае не подходит. Но спасибо.

А ты пробовал все эти файлы сконкатенировать и заинклюдить один? Сдается мне что все равно упадет

А ты пробовал все эти файлы сконкатенировать и заинклюдить один? Сдается мне что все равно упадет

только не говори ему, что еще есть opcache ;)

А ты пробовал все эти файлы сконкатенировать и заинклюдить один? Сдается мне что все равно упадет

В этом случае будет оверпамять по другой причине. Повторюсь, в качестве решения неприятный костыль с eval. Хотя он, как показали тесты, побыстрее include. Думал мало ли, местные знатоки знают где отключается запись включаемых файлов )

Я могу еще добавить парочку решения его проблемы, но это будет похоже на паралимипиаду и не буду делать ибо не для неокрпших умов

В качестве решения проблемы оверпамяти этого скрипта: for($i = 0; $i < 100000; $i++){ $df = fopen($i.".txt", "w"); fclose($df); include($i.".txt"); unlink($i.".txt"); } // fr ты предлагаешь "не использовать файлы, использовать базу если большой поток мелких запросов по ключу - использовать nosql базу или mysql handlersocket" Хорошо, я понял тебя. Правда, боюсь, что вариант твоего решения в данном случае не подходит. Но спасибо.

Почему не подходит, обоснуй

В этом случае будет оверпамять по другой причине. Повторюсь, в качестве решения неприятный костыль с eval. Хотя он, как показали тесты, побыстрее include. Думал мало ли, местные знатоки знают где отключается запись включаемых файлов )

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

записать массив в файл и считать его - быстрее чем записать массив данных и считать его через mysql

Думаю что не быстрее, а если вместо mysql подставить redis то точно будет медленнее.

Почему не подходит, обоснуй

Долго объяснять, что делается в этом скрипте for($i = 0; $i < 100000; $i++){ $df = fopen($i.".txt", "w"); fclose($df); include($i.".txt"); unlink($i.".txt"); } // fr Но если кратко, то в нём не ведётся работа с данными )))

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

Я вообще ничего не спрашивал )

Долго объяснять, что делается в этом скрипте for($i = 0; $i < 100000; $i++){ $df = fopen($i.".txt", "w"); fclose($df); include($i.".txt"); unlink($i.".txt"); } // fr Но если кратко, то в нём не ведётся работа с данными )))

Конкретно в этом скрипте делается бред, достойный топовых мест в сборнике индусского кода. Так что не будем о нем.

Думаю что не быстрее, а если вместо mysql подставить redis то точно будет медленнее.

Потому что чтение с диска этих файлов дико медленно, а как там они в кеши драйвера файловой системы попадут - неизвестно. А в redis все хранится в оперативке и считай всегда закешировано.

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

Потому что чтение с диска этих файлов дико медленно, а как там они в кеши драйвера файловой системы попадут - неизвестно. А в redis все хранится в оперативке и считай всегда закешировано.

Это немного другие вопросы и там, поверь, не всё так очевидно. Я мог бы порассуждать, но, чувствую местных разорвёт в конец))

Тут порассуждать не поможет, надо бенчмарки с графиками

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

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

Тут порассуждать не поможет, надо бенчмарки с графиками

Делалось. Но вопрос архитектуры я не поднимал.

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

Нет, видимо не допонял или я криво выразился. Инклюдятся обычные массивы. В том числе и по этому, это быстрее чем работа с SQL, ведь там: нам нужно послать запрос, получить ответ, развернуть ответ и, если есть сериализованные данные - десериализировать их.

Вопрос архитектуры не нужно паднимать, он поднимается сам у любого человека, которому важен не факт абстрактной проблемы, а ее влияние и применимость.

Дмитрий, я понял тебя, спасибо за ответы.

Я вообще ничего не спрашивал )

>Думал мало ли, местные знатоки знают где отключается запись включаемых файлов ) А чьи это слова?

>Думал мало ли, местные знатоки знают где отключается запись включаемых файлов ) А чьи это слова?

А это контекст, а не прямой вопрос. Я крайне редко спрашиваю. Только, если уж не найти ответов в интернетах (зарубежных), если сам пару суток не помыкался. Но обычно этого всего хватает.

Делалось. Но вопрос архитектуры я не поднимал.

Так выложи бенчмарки на гитхаб. Я первые шаги в пшп начал делать в 2005, но ни разу в жизни не помню чтобы include был проблемой, ни обсуждений на форумах нигде. А во времена 5.0 он оперативки жрал раза в 2-3 больше.

А серверы были в 10 раз меньше.

Хм, дежавю. Месяц назад этот человек уже побивал семерых MySQL одним массивом и вот опять...

ERROR: S client not available

Юрий, еще вопрос - какая у вас нагрузка, что вам требуется такая оптимизация?

Так выложи бенчмарки на гитхаб. Я первые шаги в пшп начал делать в 2005, но ни разу в жизни не помню чтобы include был проблемой, ни обсуждений на форумах нигде. А во времена 5.0 он оперативки жрал раза в 2-3 больше.

ты имеешь ввиду тесты, показывающие, к примеру, быстродействие работы при хранении данных в SQL VS хранении их же в массивах - я это сделаю в ближайшее время. но сразу оговорюсь, недостатки есть и у подхода связанного с хранением в массивах. я не пытаюсь противопоставлять. но это, Павел, уже другая история, не имеющая отношения к include() ))

ты имеешь ввиду тесты, показывающие, к примеру, быстродействие работы при хранении данных в SQL VS хранении их же в массивах - я это сделаю в ближайшее время. но сразу оговорюсь, недостатки есть и у подхода связанного с хранением в массивах. я не пытаюсь противопоставлять. но это, Павел, уже другая история, не имеющая отношения к include() ))

Главное чтобы было видно что это работает значительно быстрее

Хм, дежавю. Месяц назад этот человек уже побивал семерых MySQL одним массивом и вот опять...

Перед include() я рассказал о том что такое скрытых запросах браузерах к серверам.

Главное чтобы было видно что это работает значительно быстрее

2-3 раза

Ну да, неплохо.

Да понятно, что прямое обращение к файлу будет быстрее, чем запрос в мускуль. Это уже обсуждали как раз с этой персоной.

Хотел спросить - а что бы статейку на хабре не запилить? Тут кто попало да и всего 816 человек. На хабре вы сможете открыть глаза всему русскоязычному сообществу сразу, кто не прочитает, тем друзья расскажут. С удовольствием почитаю, может что интересное в комментариях дополнят.

но если нормлаьная база, заточенное под подобное, то я бы поспорил

но если нормлаьная база, заточенное под подобное, то я бы поспорил

+

Скажем так - работать без опкод кеша сейчас нельзя, и это факт. Любые микрооптимизации будут бесполезны если сравнивать микрооптимизия без опкод кеша и неоптимизированный код с опкод кешем

но главная проблема инклуда, что он будет в опкод кеше и память быстрее закончится из-за него чем из-за списка файлов

просто хранить *данные* в *опкод* кеше - это полный мрак

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

без этого "бага" много кода в пхп работало бы значительно медленнее

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

Индексы.

Так выложи бенчмарки на гитхаб. Я первые шаги в пшп начал делать в 2005, но ни разу в жизни не помню чтобы include был проблемой, ни обсуждений на форумах нигде. А во времена 5.0 он оперативки жрал раза в 2-3 больше.

в первом зенде была оптимизация собрать все файлы в 1 файл - думаю ты застал

Индексы.

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

и еще раз скажу насчет опкод кеша. Его можно залимитировать, но тогда возникает проблема записи, обновления и инвалидации кеша и это *значительно* более ресурсоемкая операция

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

одним словом решение в изначальной редакции (архитектура + решение) гавно по определению.

Если изначально было кем-то придумано и надо было фиксить без импортов экспортов данных, то тут бы не было вопросов. Понятно что хак. И конечно можно делать костылем, но только инклуд обязательно надо менять на что-то еще, например на обычное чтение файла и разбор данных (вариантов уйма)

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

В первом приближении хешмапы (ну или индексы на основе массивов), гораздо эффективнее, нежели чем индексы mysql Но во втором приближении, когда речь идёт об изменении данных и соот-но изменении индексов - индексы MySQL становятся предпочтительнее, поскольку MySQL, будучи независимым ПО, может позволить себе хранить индексы в оперативке. Но есть и третье приближение, суть которого - хранить не все данные а диапазоны. Но вот этот момент ещё не протестирован, и прогнозировать пока не берусь.

открою секрет - в мускуле хеш индексы тоже есть

я в кугсе

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

)))

Я не говорю о том что в базах есть оптимлаьное хранение данных + компрессия в результате чего бывает значительно эффективнее хранить в них, чтение с диска и из памяти даже быстрее чем без компрессии. Но все зависит от данных

Да, написать свою субд со своими индексами всегда эффективнее, чем использовать готовую. Особенно когда у людей 1кк+ rpm

И когда людей в штате 1кк+