нет не php или нет не из-за кэшей? а почему не какой-нибудь модный ангулар.жс, и всякую подписку на теги разбирать на клиентской строне, а на стороне сервера только потихоньку генерить пачки json'ов с нужными данными?
мдэ, в случае неограниченности хостинга можно выбрать любую хипстерскую технологию, добавить ынжынкс, варниш и мемкэшед и не вспоминать о похапе, долларах и спагетти коде.
А ты прикинь сколько стоит (по усилиям, но и по деньгам соответственно) переписать проект такого уровня на другую технологию, а потом перетянуть всю базу, и чтобы по SEO не просело. Проекты такого уровня становятся заложниками изначально выбранных технологий.
Бэк рефачится за пол года, фронт - два месца. Главное наличие систематизированных требований. Сейчас любуюсь проектом менявшим стек технологий 4 раза за 3 года. Одних бд - четыре штуки было.
Я всё-таки лезу не в своё дело, но джой тоже вполне себе пусть не гигантский, но крупный проект, который пишут один-два человека в свободное от работы время.
А вот вконтач и фейсбуч решили запилить свой php с блекджеком и шлюхами, лишь бы не переписывать всё не на php.
В общем, я хотел немного порассуждать на тему целесообразности, какую выгоду (в деньгах, в деньгах) принесёт джою переписывание, какие причины были у твоего проекта менять стек технологий, и что это ему дало. Но Спольски тоже неплохо сказал.
В проекте в котором сейчас участвую все положено в угоду бизнесу, нужно максимально быстро впиливать фичи в имеющуюся систему. При этом в полседнее время появилась потребность в безумном горизонтальном масштабировании (уже набирать программистов дешевле, чем наращивать мощности серверов). и php был, и mysql, и сервер на C переписывали и на с++. После того как еще на молодой ноде запилили за неделю рабочий и более стабильный прототип, чем был на предыдущих технологиях. JS'еры дешевле =) Ну и скорость впиливания фич стала примерно равна двухнедельной итерации. С php переписывать не имеет смысла, если у тебя овер 1М строк кода. И да, hhvm и kPHP имеют ограниченную поддержку php, вк и фб запилили только тот функционал, что им нужен.
1) вотермарк ставится on-demand. При первом обращении к вотермарку он генерится. Для гифок ставится асинхронно.
2) в хранилище картинки хранятся по md5-сумме, чтобы дубликаты не занимали место. Поэтому надо посмотреть ещё в БД, какую картинку по данному урлу надо выдать.
Да, всё это можно было бы обойти и запрашивать напрямую из nginx. Но слишком сложно или надо переделывать много.
вообще вот что-нибудь типа такого. Хотя если ты просто при аплоаде генеришь такую же картиинку с ватермарком , а не делаешь на лету -- смысла в общем-то нет. Что-то я зря запаниковал.
if(!$hotlink)
тогда как надо было использовать условие
if($hotlink == 'no')
Надеюсь это тебе сильно помогло и успокоило =)
http://habrahabr.ru/post/219651/
В общем, я хотел немного порассуждать на тему целесообразности, какую выгоду (в деньгах, в деньгах) принесёт джою переписывание, какие причины были у твоего проекта менять стек технологий, и что это ему дало. Но Спольски тоже неплохо сказал.
смысла никакого кроме самодисциплины, но мне вот помогает :).
Ты же это условие не пхп писал, а в nginx rule, ведь правда? Ты же не отдаёшь картинки через пхп?!
1) Ты хранишь как оригинал картинки, так и картинку с ватермарком. То есть ты не генеришь картинку с ватермарком на лету.
2) Ты определяешь какую картинку надо показывать через php и , значит ,на каждый запрос на хранилище ты дергаешь пхп, правильно?
Если всё так, то проверку на то какую картинку отдавать надо делать в nignx. А ещё лучше в varnish.
В них обоих можно залезть в куки и посмотреть, а в нгинксе еще можно забраться в мемкеш или редис.
Если ты определяешь хотлинк ли это через сессии, то можно закостылить что-нибудь типа такого:
1) вытащить из куки в нгинксе id сессии
2) вытащит ьи мемкеша/редиса хотлинк ли это
3) показать нужную картинку
Ну я не скажу что порядок именно такой, но nginx будет вечно держать коннекшен на редис/мемкеш и работать будет быстро и надёжно.
Костыли лютые, канеш, но ты сэкономишь несколько процессора и времени на реквест если не будешь пускать пхп.
2) в хранилище картинки хранятся по md5-сумме, чтобы дубликаты не занимали место. Поэтому надо посмотреть ещё в БД, какую картинку по данному урлу надо выдать.
Да, всё это можно было бы обойти и запрашивать напрямую из nginx. Но слишком сложно или надо переделывать много.
если не найдено в redis, то запустить пхп который поищет в базе и воткнет в редис для следущего раза.
ну и ключи с ttl в недельку чтобы не хранить в там ничего старого и ненужного.
Переписать немного. Но имеет смысл только если на машинах запаса нет по мощности, конечно.
Хотя учитывая что 99% нагрузки это отдача статики -- я бы переживал что приходитьс яна каждую картинку дергать пхп.
Ведь по одному и тому же урлу может открываться любая в зависимости от того открыта ли она с саета или так.
Ну и хер с ним. Ты умный и сам всё знаешь :)
я настолько овер параноик что я даже забыл о существовании этого хедера лол.
Посмеялся. Спасибо :).
вообще вот что-нибудь типа такого. Хотя если ты просто при аплоаде генеришь такую же картиинку с ватермарком , а не делаешь на лету -- смысла в общем-то нет. Что-то я зря запаниковал.