- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Раз уж вы кеш пилите, то задумайтесь над таким вопросом, что будет, если у вас при пустом кеше придёт одновременно несколько запросов - каждый из них запустит процесс генерации кеша?
"cache/" . md5($url) . ".cache";
а я вот вижу тут возможно злонамеренного переполнения диска
просто перебором. и везде буде код 200 скорее всего и все уйдет на диск
Думаю, лучше с warning изначально бороться и писать код, чтобы их не возникало. Это не задача кеша.
Какая разница warning покажется один раз не из кеша или много раз впоследствии из кеша.
Ни первого ни второго быть не должно.
"cache/" . md5($url) . ".cache";
а я вот вижу тут возможно злонамеренного переполнения диска
просто перебором. и везде буде код 200 скорее всего и все уйдет на диск
Диск то не переполнится, а дескрипторы быстро закончатся. Лучше кэш пихать в память, типо мэмкеша или редиса какого нибудь. Ну на крайний случай в бд, если она не являеться узким местом.
"cache/" . md5($url) . ".cache";
а я вот вижу тут возможно злонамеренного переполнения диска
просто перебором. и везде буде код 200 скорее всего и все уйдет на диск
404 не кэшируются
---------- Добавлено 10.08.2016 в 22:40 ----------
ТС, понимаете, программирование это не там, где есть волшебство. Тут ТУПО нужно сделать, то что вы хотите. Магии нет, волшебных слов тоже.
да, но есть вещи о которых не знаешь. я не знал про error_get_last)
Раз уж вы кеш пилите, то задумайтесь над таким вопросом, что будет, если у вас при пустом кеше придёт одновременно несколько запросов - каждый из них запустит процесс генерации кеша?
спасибо. не стал усложнять, т.к там пара запросов на чтение из базы -- просто добавил блокировку при записи
file_put_contents($cacheName, $data, LOCK_EX);
Думаю, лучше с warning изначально бороться и писать код, чтобы их не возникало. Это не задача кеша.
Какая разница warning покажется один раз не из кеша или много раз впоследствии из кеша.
Ни первого ни второго быть не должно.
да, согласен, конечно. но на всякий случай
Если кеш нужно тупо выплюнуть браузеру, то можно так:
П.С.
Не хватает времени кеширования.
С функциями хеширования возможны колизии.
Посмотрите также в сторону fastcgi кеширования.
Страницу целиком можно не кешировать, а нарезать ее на маленькие блоки.
Не для бугагашечки, а серьезно. Зачем самому себе придумывать проблемы?
Что мешает изначально писать код в дебаг-режиме с максимальным уровнем нотификации об ошибках, исключая ворнинги и нотисы на этапе разработки?
Понимаю, что когда пишешь для себя, можно на многое закрыть глаза, но закрывать их на ошибки или непредсказуемое поведение своего же кода, имхо, странно.