«phpClub» — архив тем ("тредов"), посвящённых изучению PHP и веб-технологий.
Аноним 2018/06/29 08:16:46  №1219400 1
Посоны, ткните носом, что почитать для решения следующей задачи: я из своего кода шлю серверу запрос, получаю ответ, что все ок, дальше я жду от него запроса ко мне, в котором он и передаст нужные мне данные. Мне нужно понять как это вообще реализуется.
Ответы: >>1219834 >>1219981
Аноним 2018/06/29 17:31:16  №1219785 2
Поцоны, как же я охуел, когда узнал, что не могу просто себе копировать в новую переменную уже готовый обьект, который потом уходит в другую функцию. Пиздец я ебался три часа. Пока до меня не дошло, что нужно заново вызвать фукцию, чтобы появился обьект, а тот "старый" обьект - он уже тютю.


Пиздец я тупой. symphony framewrk
Ответы: >>1219981
Аноним 2018/06/29 17:55:26  №1219805 3
Вообще у кого-то есть опыт отладки приложения на symphony? Эта еба даже в вебсервер-лог ошибки не всегда пишет. Остается только догадываться, что там: переменая, массив или обьект. Жизнь боль.

Накатив phpstorm и xdebug, я смогу отлавливать все это добро?

Я делал маленький хук, а ебался два дня.
Ответы: >>1219810 >>1219981
Аноним 2018/06/29 18:13:07  №1219810 4
>>1219805
> Я делал маленький хук, а ебался два дня.
В цитатник) Пеши есчо.
Ответы: >>1219981
Аноним 2018/06/29 18:44:24  №1219834 5
>>1219400
Мне, похоже, надо смотреть в сторону очередей и воркеров. Можно ли это сделать с помощью php-fpm?(ngnix, если это играет роль)
Ответы: >>1219981
Аноним 2018/06/30 04:19:21  №1219981 6
>>1219785

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

>>1219805\t

Вообще, в Симфони как раз есть логгирование, просто надо уметь настраивать его в конфиге. Ты можешь логгировать все в обычный файл, например, также в dev окружении внизу страницы есть такая модная панель (web toolbar), которая показывает лог, выполненные запросы, и многое другое: https://symfony.com/blog/new-in-symfony-3-1-web-debug-toolbar-and-profiler-enhancements

Также, в Симфони есть вспомогательные команды для отладки: https://symfony.com/doc/3.4/debug/debugging.html

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

Если тебе интересно все, что происходит во время обработки запроса, какие функции вызываются, то самую подробную информацию дает trace в xdebug - туда пишется каждый вызов каждой функции. Логи трейса огромные, и нужно приложение для их просмотра, вроде в phpstorm такой функционал есть.

>>1219810

Зачем это писать? Тебе скучно? Иди скучай в другой тред.

>>1219400

Это OAuth? Такое делается с помощью сохранения куда-то состояния. То есть в начале скрипт отправляет данные на сервер, и сохраняет куда-то свое состояние. Потом, когда от сервера приходит запрос, он достает это состояние и обрабатывает данные. То есть взаимодействие разбивается на 2 отдельных процесса. Нет команды вроде "ждать прихода запроса от сервера".

Также, если у тебя OAuth, для него есть готовые библиотеки.

>>1219834

Если речь об OAuth, то это не требуется.

Аноним 2018/06/30 08:04:23  №1220010 7
Помогите нубу: установил php, установил mysql, теперь, как я понял, где-то нужно ввести --with-mysqli, чтобы все заработало, а вот где?
Ответы: >>1232699
Аноним 2018/06/30 08:06:10  №1220011 8
>>1219981
>Это OAuth?
я на 95% уверен, что это про очереди и воркеры и на 40% уверен, что это как-то связано с связано с php-fpm
Ответы: >>1232699
Аноним 2018/07/01 10:30:18  №1220689 9
задачка про калькулятор https://ideone.com/Z6NzBK
подскажите, пожалуйста, стоило ли так делать
Ответы: >>1220725 >>1232699
Аноним 2018/07/01 13:42:22  №1220825 10
>>1199390 (OP)
Оп, мне сейчас понадобится кеш для рескейленых картинок (именно рескейл, для иконок там отдельная решенная тема).
Проблема в том что готового подходящего решения я не нашел...
Есть пара нюансов: мне нужно ограничивать жизнь файлов именно максимальным размером кеша а не временем; нужно чтобы новые файлы перезаписывали старые; файлы только пишутся но не читаются; хранить нужно строго именно файлы на диске; нужно минимальное дисковое i/o на измерение размера кеша и поиск старых файлов. Кажется сделать легко. Что я думаю собрать: с fs взаимодействие только через запись и удаление файлов (и touch при обновлении), сама инфа о том какие файлы сейчас находятся в кеше и какое у них время держать в memcached (кеш в кеше лол). На случай утраты инфы из ram при старте один раз траверсить директорию на наличие файлов и их таймстемпы.
Что думаешь?
Ответы: >>1232699
Аноним 2018/07/22 04:27:50  №1232699 11
>>1220010

Вводить --with-mysqli надо, если ты самостоятельно собираешь интерпретатор php из исходников.

Как ставить расширение, зависит от твоей ОС. Под виндой - многие расширения идут в комплекте и их надо просто включить в конфиге, а остальные скачиваешь и кладешь в папку расширений. Под линуксом обычно ставится через менеджер пакетов вроде apt-get.

>>1220011

php-fpm скорее всего тут не при чем. Это лишь менеджер процессов для поддержки FastCGI.

>>1220689

Вместо [+]|[-]|[]|[/] лучше писать [+\-/]

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

Лучше было бы разбить строку на один список элементов. Например, через preg_match('~[0-9]+|[+\-*/]|.~u'). Последняя точка ловит любой символ и позволяет обнаруживать ошибочные символы. И далее уже обходить полученный массив элементов.

> if (preg_match("/[.]/", $value)
Тут хватило бы mb_strpos.

Так, вроде работает верно, но я не могу понять, всегда ли она будет так работать. Что, если у нас будет выражение "8 8 8 8 + "?

>>1220825

> файлы только пишутся но не читаются;
В чем смысл такого кеша? Я не понимаю из описания, что кешируется и куда.

> На случай утраты инфы из ram при старте один раз траверсить директорию на наличие файлов и их таймстемпы.
Это непрактично. Попробуй поработать с кешем на миллион файлов с большим количеством папок, и у тебя "траверсенье" может занять полчаса.

Практичнее сделать неумирающее приложение и держать список файлов в памяти. Если надо, дампить его на диск и при запуске читать дамп. Также, это лучше писать не на PHP, а на Го, так как тут критична производительность.

То, что у тебя, скорее всего будет работать плохо.

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

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

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

Также, у меня ощущение, что я слышал про что-то такое для нгинкса.
Ответы: >>1233122
Аноним 2018/07/22 16:49:37  №1233122 12
>>1232699
Спасибо за ответ ОП. Очень прошу тебя прочетсь пост целиком:

> В чем смысл такого кеша? Я не понимаю из описания, что кешируется и куда.
Имеется ввиду, пишутся на диск из php но читаются только файловым сервером.

> Это непрактично. Попробуй поработать с кешем на миллион файлов с большим количеством папок, и у тебя "траверсенье" может занять полчаса.
В планах была только одна папка с парой тысяч файлов примерно.

> Практичнее сделать неумирающее приложение и держать список файлов в памяти. Если надо, дампить его на диск и при запуске читать дамп. Также, это лучше писать не на PHP, а на Го, так как тут критична производительность.
Я никак не могу пихать его в рам потому что её мало. Файлы могут весить по 1-2 мегабайта, а память там общая на несколько сайтов. Сейчас в среднем свободно меньше гига и даже тот в "эвейлебл" а не фри. Плюс иногда память сильно нужна на всякие процессинги. Получается, под это дело нужно выделять пару гигов хотябы и всё-равно часть системы отвечающая за частоту запросов оставить, чтобы в памяти лежали самые популярные файлы.

> То, что у тебя, скорее всего будет работать плохо.
Вполне возможно.

> Альтернативный простой вариант - просто складывать файлы на диск и раз в сутки запускать штуку, которая обходит файлы, считает их объем и удаляет лишнее. Старайся использовать минимум подпапок, так как их обход при большом количестве будет знатно тормозить.
Это если сделать прямо так может быстро убить диск, чуть позже в посте объясню детали.

> Надо помнить, что дисковый трафик не бесконечный. Возможно, что хранить файлы в памяти выгоднее. Мне кажется, для нгикса что-то такое было.
Как выше объяснил рам не годится (хотя я не спец, может быть можно там всё как то ужимать но есть ли смысл). ИОПСы конечно не резиновые, но в том и фишка, ниже чуть чуть еще объясню свою позицию.

> В общем, у меня есть ощущение, что ты можешь написать что-то бесполезное. То есть в твоем воображении это крутой кеш, а на деле с ним может все будет работать медленее, чем без кеша. Чтобы этого не произошло, надо обязательно провести тесты, которые подтвердят, что с кешем все работает быстрее.
Нет, я не думаю что придумал какой то крутой кеш иначе бы сразу побежал его делать а не думал сперва. Пожалуйста прочти дальше.

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

Теперь попробую дополнить факторами по которым я решил что так будет лучше и для чего вообще кеш нужен:
1. Кеш для картинок, не помню указывал ли это раньше. Грубо говоря, есть оригинал в 5к, кеш - для его версий в 4к, 2к, телефонном и так далее. Хочу отдельно отметить что это не относится к тамбнейлам, для них отдельная системка и весят они ничтожно мало и проблем нет.
2. Картинок очень много и потенциально есть вероятность запроса их в любом порядке и любом разрешении.
3. Мало рам, диск ограничен.
4. Почему вообще кажется что нужен кеш: ресайз картинок, особенно крупных - занятие небыстрое. Я почему-то думаю, что одно чтение файла с диска быстрее чем чтение более крупного файла с диска, его декодировка, ресайз, кодировка и отдача.
5. "аналитически" (аналитика не моя) считается что в основном будет спрос только на ряд файлов в определнных разрешениях. Что это значит: допустим, какое то изображение в определеном разрешении запросили один раз в месяц - нет смысла даже думать о его кешированнии. Но на главной (лендинг типа) странице есть как минимум несколько изображений которые показываются всем посетителям - очевидно что их есть смысл закешировать в размере в котором они для лендинга юзаются. Так-же есть такие разделы где часто показываются одни и те-же картинки, и ориентировочно большинство пользователей имеют fhd мониторы - следовательно, вероятность что они будут эти именно эти картинки просить в именно таком разрешении выше.
6. Таким образом это не традиционный кеш, а кеш по частоте обращений, т.е. кешировать в принципе нужно только то что чаще всего запрашивают пользователи.
7. Использование отдельного "реестра" для частоты обращений (внутри мемкешд например) как раз позволяет минимизировать бесполезные иопсы и писать только то что реально нужно.
8. Нужна возможность именно вручную контролировать кап на дисковое пространство кеша, чтобы случайно не забить диск и прочие радости.

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

Но и в то же время не хочется чтобы парочка любопытных листальщиков галерей завалила сайт по рам или диску.
Ответы: >>1241066
1-35 Аноним 2018/08/04 23:52:57  №1241066 13
>>1232886

Я могу предложить урок, где есть пример MVC-кода: https://github.com/codedokode/pasta/blob/master/arch/mvc.md

> Где по логике MVC должны хранится скрипты?
Ты имеешь в виду, файлы с кодом? Не понимаю вопрос. Что значит "где"? В какой папке?

> Если писать их прямо во вьюшке меня будут бить?
Вью предназначено только для вывода информации, данные для вывода оно получает от контроллера.

> Обязательно ли передавать во вьюшку модель формы?
Если ты хочешь вывести эту форму, то наверно. А как ты иначе ее выведешь и заполнишь значениями?

> Как ко мне будут относится, если я передам модель объекта из БД?
Не знаю, что ты понимаешь под "моделью". Если это объект, который хранит информацию об одной сущности в БД, то логично его передать. Если это объект, который умеет искать и изменять информацию в БД, то наверно передавать его во вью не стоит.

>>1232967

По моему, человек хочет разобраться в MVC. Это тред как раз для таких для вопросов. Что тут непонятного?

>>1233122

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

Тогда проще всего сгенерировать уменьшенные версии картинок один раз и навсегда. Если их 2000 и уменьшенные версии весят допустим по 2 Мб на картинку (хотя JPEG можно сжать гораздо сильнее), это всего 4 Гб диска. Если заказчик хочет высококачественные изображения, то 4Гб - небольшая плата за них.

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

> Получается, под это дело нужно выделять пару гигов хотябы и всё-равно часть системы отвечающая за частоту запросов оставить, чтобы в памяти лежали самые популярные файлы.
Да, но если тебя интересует максимально возможная производительность, то конечно, картинки надо отдавать из памяти, а не с диска. Так как доступ к данным на диске, особенно под нагрузкой, медленнее. Хотя, если сайт малопосещаем, то разницы особой нет.

> 4. Почему вообще кажется что нужен кеш: ресайз картинок, особенно крупных - занятие небыстрое.
Да, для 5к картинок декодинг, ресайз и сжатие навскидку потребует несколько секунд.

> Это если сделать прямо так может быстро убить диск, чуть позже в посте объясню детали.
Тогда кеш нормально вряд ли получится сделать.

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

> 2. Картинок очень много и потенциально есть вероятность запроса их в любом порядке и любом разрешении.
> 3. Мало рам, диск ограничен.

Тогда кеш с большой вероятностью не будет работать. Так как он быстро заполнится, дальше будут запрашивать картинки, которых в нем нет - значит придется удалять существующие, ни разу их не отдав. Как я писал выше, ты можешь протестировать это, даже не делая реальный кеш, а просто смоделировав его работу в программе и посчитав hit/miss rate (отношение числа попаданий и промахов кеша).

> 4. Почему вообще кажется что нужен кеш: ресайз картинок, особенно крупных - занятие небыстрое. Я почему-то думаю, что одно чтение файла с диска быстрее чем чтение более крупного файла с диска, его декодировка, ресайз, кодировка и отдача.
Да, но для кеша нужна либо память, либо место на диске. Которого у тебя нет.

> Но на главной (лендинг типа) странице есть как минимум несколько изображений которые показываются всем посетителям
Вообще, для лендинга экономически неэффективно заморачиваться с кешами, у лендингов обычно маленький бюджет. Проще просто для этих изображений через imagemagik сгенерировать версии в нужном размере. Но если тебе так хочется попробовать, то конечно, пробуй. Только сделай сначала тесты или измерения.

> 7. Использование отдельного "реестра" для частоты обращений (внутри мемкешд например) как раз позволяет минимизировать бесполезные иопсы и писать только то что реально нужно.
А как ты собрался считать эту частоту? Запускать php-скрипт на каждый запрос картинки? Это сразу понизит эффективность, так как нгинкс гораздо эффективнее раздает статические файлы, поддерживает conditional requests и тд, да и запуск скрипта на ограниченном железе требует время. Можно конечно попробовать (с модулем XSendfile), но у меня ощущение, что найти 4 Гб места проще и быстрее, чем писать и отлаживать такой кеш.

В общем, проще всего - просто сгенерировать уменьшенные версии заранее. Также, можно попробовать твой вариант с подсчетом числа запросов и XSendFile. Тут удобнее использовать не мемкеш, а редис, в котором как раз есть удобные структуры вроде хеш-таблиц. Логика может быть вроде:

- если в кеше есть место, то сохраняем туда превьюшку (или: если картинка входит в список востребованных)
- если нет, то не сохраняем
- раз в N часов анализируем статистику запросов и удаляем редко востребованные картинки

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

Правда, это получается сложная штука, требующая много времени на реализацию и отладку.
Ответы: >>1241102
Аноним 2018/08/05 05:41:00  №1241102 14
>>1241066
Щас юзается для отдачи превьюшек X-Accel-Redirect (пишут что это нгинксовский аналог xsendfile)

Я по твоему посту так понял - ты не заметил что у меня есть отдельно превью (с ними проблем нет) и отдельно ресайзы. Вот ресайзы это кароче версии какой-то картинки 10кХ10к в разрешениях 5к, 4к, 2к, FHD, HD, vertical FHD, дохуя их.

Изображений пара десятков тысяч, и список возможных разрешений около 40 и меняется вручную по желанию. Сохранять все - нереально. Я в любом случае запросы к файлам пускаю через пхп сейчас, там идет вайтлистинг, генерятся превьюхи если еще нету и сохраняются. Но то превьюхи, а рескейл может быть слишком крупным. Плюс у превьюх там размеры в основном по aspect ratio регулируются - а их меньше чем фактических разрешений в вайтлисте. Плюс превьюхи можно в говно ужать и будет нормально.

Еще там не совсем тривиальная схема маппинга юри на файлы - всё проклятые "ЧПУ", в ссылках на файлы-то. Я хотел убрать пхп прослойку, но не осилил пока переписать логику преобразования юри в путь на регулярках в реврайтах нгинкса. Типа, сделать чтобы пхп запускался только если первьюхи не хватает.

Хотя я мерил - эта прослойка в целом по времени почти не ест если файлы уже готовы (~5мс), ест только при генерации.

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

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

Еще ты пишешь вполне разумную вещь, типо накидать систему и смоделировать нагрузку - но проблема что эта модель будет не реалистичная в любом случае. Может быть тотальная ассиметрия в запросах (одно оснвное разрешение, какие-то выстрелившие ключи), а моделируется такое барахло обычно с медианными (типо классическое распределение). Хотя может я накручиваю зря.

Вообще конечно т.к. в сайт я "не верю" можно не торопиться с всякими изобретениями; даже на уника в минуту можно сгенерировать на ходу картинку. Но это не профессионально как то ощущается, а я ведь хочу стать погромистом...
Ответы: >>1243953
Аноним 2018/08/10 03:57:09  №1243953 15
>>1241497

Процент это 1/1000 числа. Увеличить на 10% - значит поделить число на 100 частей, взять 10 и прибавить к этому же числу. Ну или умножить число на 1,1.

>>1241102

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

> Еще там не совсем тривиальная схема маппинга юри на файлы - всё проклятые "ЧПУ", в ссылках на файлы-то.

Ты делаешь URL = путь к картинке на диске (/images/download/2000x3000/sunshine-123.jpg) и добавляешь в нгинксе правило, что если в папке /images/download/ нет файла, то вызывается PHP вместо отдачи 404.

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

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

>>1240997

> w5.1 https://ideone.com/yvZESL
> $creditBalance != 0;
Лучше писать условие $x > 0, чтобы при уходе в минус программа не зациклилась.

Верно, хотя вместо if можно было использовать min/max.

> w5.2 https://ideone.com/k3dgmE
> for ($pct = 10, $sumOfDream = 1000000, $dep = 10000, $clientAge = 16; ; $dep += ($dep / 100) * 10, $clientAge++)
Не надо писать такую длинную шапку цикла, ее трудно читать. Стоит оставить вверху только 1 переменную.

Так, верно.

> w5.3 https://ideone.com/4GtuH3
Верно.

> w5.4 https://ideone.com/X1glvK
Правильно.