«phpClub» — архив тем ("тредов"), посвящённых изучению PHP и веб-технологий.
Аноним 2018/07/22 12:31:26  №1232886 1
Где по логике MVC должны хранится скрипты? Если писать их прямо во вьюшке меня будут бить? Обязательно ли передавать во вьюшку модель формы? Как ко мне будут относится, если я передам модель объекта из БД?
Ответы: >>1232944 >>1232967 >>1241066
Аноним 2018/07/22 13:36:25  №1232967 2
>>1232886
зачем тебе это? Какая цель?
Ответы: >>1241066
1-35 Аноним 2018/08/04 23:52:57  №1241066 3
>>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 4
>>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 5
>>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
Правильно.