Еще раз доказывает, что AWS — это дорого. И что есть «скрытые» платежи, в этом случае это была оплата трафика, которым обычно пренебрегают. Вначале проекта может действительно был 1Гб и оплата казалась минимальной.
Не написали, во сколько вышло это решение? Действительно ли S3 дороже, чем «простое решение»? Либо было использованы существующие мощности, и таким образом «сэкономили» 2000 USD?
Bitrix хорош тем, что он дает работу множеству специалистов. Громкие лозунги: «работает из коробки», «интеграция с 1С в 2 клика» делают свое дело — и вот уже новая вакансия размещена. Редкая установка живет без поддержки специалиста. Bitrix — это действительно хороший продукт, но не с точки зрения технологий, а как ощутимый вклад в экономику: он вовлекает новых специалистов, железо, тендеры, внедрения.
Почувствовал в себе силы — и вот уже «перестал работать на дядю», пара дней и у тебя уже магазин и выгрузка в маркет и синхронизация с 1С. А это уже 1-4 рабочих места минимум.
Можно сказать, что 1С-Bitrix — это модное слово «экосистема» для ИП с его неумолимым желанием иметь свой интернет-магазин, для школ, для УК и еще для сотни желающих быстро и из коробки.
Автор рассказал о ситуации, которую все знают (все заинтересованные). Ничего нового не сказал, кроме пиарной ссылки на свой продукт и невнятных диаграмм. Рекламируемый продукт обречен на провал. Ситуация на глобальном рынке такова, что идет стагнация, поэтому и появляются такие продукты «премия „Стартап года 2013“» и «участник Инновационного центра «Сколково».».
Только в страшном сне может присниться, отдать основу бизнеса на откуп третьим лицам.
С такими ценами на продукт не ясна аудитория, крупняк при желании реализует подобное своими силами, а мелкий игрок просто не потянет. Простой менеджер за эти деньги будет руками генерить XLS целый год. А там может и бизнес прогорит или второго наймут или небо упадет на земную твердь.
Даже если будет желание у кого-то интегрировать выше упомянутую систему, то в первую очередь нужно выгрузить из своих баз те самые данные, а это и есть основная проблема.
Я как раз занимаюсь парсингом упомянутых XLS, XML, CSV и прочих редких API (кто предоставляет). Проблема как раз, что поставщик не может сгенерировать актуальную информацию (то цены не совпадают, то формат меняют, то вообще ресурс упал). Как только поставщик осилит этот шаг, то и не будут нужны подобные продукты. Подключить новый файл или API — максимум день работы прогера.
То есть проблема не в том, что не используются подобные системы, или что не хватает ресурсов или каких-то форматов и стандратов, а в том, что поставщик просто не хочет (не видит необходимости) реализовать это. Точнее уже многие реализовали, и через пару лет повысят качество этих сервисов.
я бы на вашем месте отказался от bitrix, так как если вы на этапе проектирования «я не умею понимать», то в дальнейшем будут сложности с быстродействием, которые средствами API не решить.
Видимо вы не видели код API, чтобы говорить «грязном хаке кода».
да что там понимать, при нажатии в битриксе «очистить» — создавайте файл в корне (наприер cache.lock).
Сделайте баш скрипт, который будет смотреть наличие этого файла, и при его наличие удалять папку /tmp/cache… (какая указанна в конфиге для домена в _cache_path) и удалять этот файл.
Одна строка на php
И 3 строки на bash
В крайнем случае можно эту проверку засунуть в php. А можно вместо создания файла сразу удалять папку с кэшем из php.
Вопрос может быть только в прав на файлы и папки кэша.
Если у вас приложение, то кэш в том виде который предложен — не имеет смысла, он будет только мешать.
Если обращения редкие (и база небольшая) — то нужно повысить скорость выполнения самого скрипта, а не кэшировать на 30 минут.
А если приложение супер популярно, то нужно кэш перенести из файлов в memcache (поддерживается nginx), и генерить и обновлять кэш своим скриптом в зависимости от изменения контента, а не по времени.
использование $request_uri ведет к тому, что запросы вида /product/art12/ и /product/art12/?utm_source=market&… будут закешированы дважды. Это не проблема, если вы никак не отслеживаете utm метки, иначе смысл в кэшировании немного теряется, так как, если с маркета на один товар ходят не часто, то все они будут работать БЕЗ кэширования.
Более того, не все роботы шлют $http_if_modified_since $http_if_none_match, поэтому очень часто запрос будет без кэша.
Ну и для полноты хочется узнать, что еще посещалось с этого айпи, или вообще с ямайки. Какие посты, под какими пользователями и может он еще и каменты писал? Пока конечно видится «удачно удалили хаб».
Можно конечно сделать наброс: проблемы такого рода интересны пока ты сам в них копошишься, а как только перешел на другой уровень бабла, то даже обсуждение подобных случаев начинает мешать твоему светлому будущему. Хабр давно и прочно привлек внимание большой аудитории, теперь можно «навести порядок», никто никуда уже не соскочит с этого ресурча, а то уже пачка с письмами «убрать порочащую нас информацию» в окна офиса видна.
Почувствовал в себе силы — и вот уже «перестал работать на дядю», пара дней и у тебя уже магазин и выгрузка в маркет и синхронизация с 1С. А это уже 1-4 рабочих места минимум.
Можно сказать, что 1С-Bitrix — это модное слово «экосистема» для ИП с его неумолимым желанием иметь свой интернет-магазин, для школ, для УК и еще для сотни желающих быстро и из коробки.
Только в страшном сне может присниться, отдать основу бизнеса на откуп третьим лицам.
С такими ценами на продукт не ясна аудитория, крупняк при желании реализует подобное своими силами, а мелкий игрок просто не потянет. Простой менеджер за эти деньги будет руками генерить XLS целый год. А там может и бизнес прогорит или второго наймут или небо упадет на земную твердь.
Даже если будет желание у кого-то интегрировать выше упомянутую систему, то в первую очередь нужно выгрузить из своих баз те самые данные, а это и есть основная проблема.
Я как раз занимаюсь парсингом упомянутых XLS, XML, CSV и прочих редких API (кто предоставляет). Проблема как раз, что поставщик не может сгенерировать актуальную информацию (то цены не совпадают, то формат меняют, то вообще ресурс упал). Как только поставщик осилит этот шаг, то и не будут нужны подобные продукты. Подключить новый файл или API — максимум день работы прогера.
То есть проблема не в том, что не используются подобные системы, или что не хватает ресурсов или каких-то форматов и стандратов, а в том, что поставщик просто не хочет (не видит необходимости) реализовать это. Точнее уже многие реализовали, и через пару лет повысят качество этих сервисов.
Так у вас приложение или сайт?
Видимо вы не видели код API, чтобы говорить «грязном хаке кода».
Сделайте баш скрипт, который будет смотреть наличие этого файла, и при его наличие удалять папку /tmp/cache… (какая указанна в конфиге для домена в _cache_path) и удалять этот файл.
Одна строка на php
И 3 строки на bash
В крайнем случае можно эту проверку засунуть в php. А можно вместо создания файла сразу удалять папку с кэшем из php.
Вопрос может быть только в прав на файлы и папки кэша.
Если обращения редкие (и база небольшая) — то нужно повысить скорость выполнения самого скрипта, а не кэшировать на 30 минут.
А если приложение супер популярно, то нужно кэш перенести из файлов в memcache (поддерживается nginx), и генерить и обновлять кэш своим скриптом в зависимости от изменения контента, а не по времени.
Более того, не все роботы шлют $http_if_modified_since $http_if_none_match, поэтому очень часто запрос будет без кэша.
Сапожник без сапог.
Можно конечно сделать наброс: проблемы такого рода интересны пока ты сам в них копошишься, а как только перешел на другой уровень бабла, то даже обсуждение подобных случаев начинает мешать твоему светлому будущему. Хабр давно и прочно привлек внимание большой аудитории, теперь можно «навести порядок», никто никуда уже не соскочит с этого ресурча, а то уже пачка с письмами «убрать порочащую нас информацию» в окна офиса видна.