«phpClub» — архив тем ("тредов"), посвящённых изучению PHP и веб-технологий.
Аноним 2018/07/01 13:42:22  №1220825 1
>>1199390 (OP)
Оп, мне сейчас понадобится кеш для рескейленых картинок (именно рескейл, для иконок там отдельная решенная тема).
Проблема в том что готового подходящего решения я не нашел...
Есть пара нюансов: мне нужно ограничивать жизнь файлов именно максимальным размером кеша а не временем; нужно чтобы новые файлы перезаписывали старые; файлы только пишутся но не читаются; хранить нужно строго именно файлы на диске; нужно минимальное дисковое i/o на измерение размера кеша и поиск старых файлов. Кажется сделать легко. Что я думаю собрать: с fs взаимодействие только через запись и удаление файлов (и touch при обновлении), сама инфа о том какие файлы сейчас находятся в кеше и какое у них время держать в memcached (кеш в кеше лол). На случай утраты инфы из ram при старте один раз траверсить директорию на наличие файлов и их таймстемпы.
Что думаешь?
Ответы: >>1232699
Аноним 2018/07/22 04:27:50  №1232699 2
>>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 3
>>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 4
>>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 5
>>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 6
>>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
Правильно.