Если покупатель приобрел лицензию до внедрения этой ограничивающей функции, то и включать ее без ведома пользователя нельзя, согласно действующему гражданскому кодексу. Появилась опция — покажите, но не включайте. Захочет — сам включит. Но если платил за одно, а получил другое, то будет ай-яй-яй. Договоры нельзя менять в одностороннем порядке в сторону ухудшения условий. Даже если такой пункт вписать, он будет незаконным.
Я писал не про уместность закона, а про неуместность его упоминания, поскольку он абсолютно не касается производителей ПО. Можете даже не ходить в Конституционный суд, чтобы это понять. :)
Нет, речь идёт о самоуправстве. Пользователи не были осведомлены о таких ограничениях ПО при покупке и ограничения внесены не законом, который производителей ПО не касается вообще.
Вообще то это очень спорный момент. По зпп продавец обязан информировать обо всех существенных свойствах товара. Кроме того, не допускается внесение в договор ограничений уже после его заключения (это норма гк). Таким образом производитель этого антивируса не имеет права ограничивать доступ к сайтам по новому критерию для всех своих более ранних покупателей, без их письменного согласия. И тут уже офертой не отделаешься.
Получается логическая и правовая коллизия. Антивирус не имеет возможности определять являетесь ли персонально вы владельцем авторских прав на контент блокированного сайта. Из-за этого даже правообладатели, по логике производителей указанного ПО, не получат доступа к собственному произведению, в том числе для составления судебного иска. Какой выход вы видите из этой ловушки — специальный антивирус без фильтра для правообладателей и представителей следственных, судебных и законодательных органов или запрет на использование этого ПО всеми, причастными к авторским правам?
Закон, который вы так ненавязчиво призывание уважать, вообще то не касается производителей ПО. Посему пожалуйста отложите этот аргумент, как неуместный.
придется повторить rsync :) fuse берет на себя и перезапуск соединений и обработку ошибок, так что будет то же самое, что и с обычной файловой системой — надо только следить за статусами операций.
Просто у меня есть негативный опыт, которым я поделился. Конкретно работы encfs+dropbox на десктопе
Вот видите, вы увидели в моей реплике dropbox, а на остальные сетевые fs не обратили внимания. Хотя суть была не в том, чтобы использовать именно dropbox, а в том, чтобы вместо закрытого зашифрованного архива оперировать на своем сервере нормально доступными открытыми данными.
Проблем с инкрементальными резервными копиями на серверах у меня нет, rsync — наше всё.
Вот об этом я и талдычу! fuse+cryptfs при всех прочих равных (зашифрованном сетевом хранилище) дают работать rsync для нормальной автоматизации инкрементальных резервных копий.
Не кривите душой. FUSE дает не меньше, а даже больше вариантов хранилищ (даже такие экзотические, как GridFS, Gitfs, gmailfs). Дело не в дропбоксе, как вы выразились, а в том, что при наложении cryptfs/encfs на любую обычную файловую систему (а fuse превращает в нее почти что угодно), с файлами в ней можно прозрачно работать, например для создания инкрементальных резервных копий, не выгружая весь архив. Вы, в данном случае, просто пропагандируете собственную инфраструктуру хранилищ, а не новый способ сохранения резервных копий. Так что не берите на себя так уж много, утверждая, что только ваш подход обеспечивает сохранность данных. Лучше сосредоточтесь на недостатках вашего решения — например архитектурной проблеме с инкрементальными резервными копиями.
Мне тоже эта система кажется какой-то громоздкой. Лично я предпочитаю делать резервные копии при помощи cryptfs, который не собирает все файлы в один архив, а оставляет их россыпью, но шифруя в том числе и имена. Это позволяет очень серьезно экономить трафик и элементарно автоматизируется через обычный механизм монтирования простым bash-скриптом. При гибкость этого механизма в том, что не важно куда направляется резервная копия: на ftp, dav или в dropbox — разницу этих технологий скрывает за собой fuse, а cryptfs, расположенный поверху, скрывает данные от провайдеров этих хранилищ.
Ну так везде производительность достигается компромиссами. Нет никакой серебряной пули. Но и дела у Mongo не так уж и плохи на самом деле. Главное не запускать ее без репликации :) Кстати я не имел в виду шардинг. Простая полная репликация практически не приносит проблем.
1. Может, но без апача будет больше свободной памяти. Да и зачем вам два веб-сервера? На фронтенд apache ставить нельзя категорически, ведь его легко заставить исчерпать память даже с мобилки. Если все задачи веб-сервера можно переложить на nginx (который к тому же в памяти не размножается), то это следует сделать хотя бы поэтому. Да и оперативка лишней не бывает — ее лучше использовать для query_cache или apc.
2. У php главная проблема производительности не в способе запуска интерпретатора. А в издержках самого интерпретатора. Не так уж важно сэкономить 10 мсек на замене mod_php yf php_fpm, когда движок сайта формирует страницу целую секунду. Если обработка запроса в вашем приложении тормозит, то главным образом не из-за апача, как такового, а из-за того, что код или его подгрузка занимает очень много времени, или работу блокируют операции с базой и фс.
С какой стати переменные окружения из спецификации CGI стали вдруг Апачевыми? :)
Конечно есть. wiki.nginx.org/HttpCoreModule#Variables
И с авторизацией всё в порядке. Читайте доки.
я нигде опять же не говорил, что «апач рулит, а fpm отстой», нет.
Кстати php-fpm отлично подключается и к Apache. Я так делаю на серверах, где нужно совмещать сайты с .htaccess с остальными — на одних Работает nginx + apache + php-fpm, а н адругих nginx + php-fpm. И это получается даже стабильнее, чем с mod_php.
От веб-сервера надо не так уж много. Тем более, что после создания nginx.inc его разработка серьезно ускорилась. Но уже сейчас его преимущества с лихвой покрывают архитектурные недостатки Apache. Буквально сегодня я собирал для нового сервера ngnix + cache_purge + pagespeed. И при том, что на нем будет работать в том числе и wordpress, мне не пришлось ничего переписывать на php или отказываться от каких-то возможностей.
более подробно можно понять чем сервер в конкретный момент времени занимается например
Ну так это не недостаток — это достоинство nginx. Он в рамках одного потока исполняет до десятков тысяч запросов и просто незачем рассматривать что именно в какой момент он делает. Однако статистика у него тоже есть из коробки и я ее использую для мониторинга нагрузки через munin.
быстрый фронтенд, не нагруженный лишними настройками и более тяжелый бекенд.
Фронтенд быстрый потому, что он асинхронный неблокирующийся. Когда и бекенд станет использовать такую архитектуру, то можно будет очень сильно экономить на серверах и намного легче масштабировать с влучае нужды. И Apache в этом смысле просто старый и менее удачный опыт, который постепенно уступает место новой и более эффективной архитектуре.
Я никого не призываю юзать Apache, я просто против категоричных «не нужен, выкинуть» :)
Иными словами вы так же катеогично протестуете против субъективного мнения из-за его категоричности. :)
Ищите себя в теме статьи. Я же тоже мог начать рассказывать какая php плохая штука рядом с hadoop/erlang/tornado/nodejs/watever-async для проектов, которые надо масштабировать. Но я сдержусь, поскольку автору хотелось рассказать о проблемах тяжелых приложений на php и о том, о чем надо задуматься владельцам всяких drupal/joomla/wordpress, которые дошли до серьезной посещаемости. Я и сам как-то встрял с популярным сайтом на drupal настолько, что пол движка переписал, чтобы только серверов не докупать. Но и там мог возникнуть предел, за которым только горизонтальное масштабирование.
я считаю достаточно нагруженным 10-12 миллионов просмотров динамики в сутки — с этим вполне справляется и Apache+mod_php
Вот почему мне не хотелось приходить к фактическим цифрам. Ведь тогда надо лезть в дебри. Мне в принципе не сложно, но будет ли всем полезен этот разговор, особенно учитывая, что вы «знаете» проекты с 10-12 млн просмотров, а я в таких копаюсь. Ну ладно. Попробую без занудства.
Для нагруженного сайта критически важно не суточное число запросов, а мгновенное. Что такое 10 млн суточных хитов (динамики)? Это 116 запросов в секунду при совершенно равномерном распределении за сутки. Так почти не бывает. Более харктерным является 16 нагруженных часов с двумя/тремя пиками нагрузки (развлекаловка вроде фишки.нет) или 50-100-200 рывков по 300-700% хитов на фоне тех же 16 часов среднего трафика (электронные сми). По той нагрузке, что есть у меня, 10 млн хитов должны давать пики в районе 400-500 запросов в секунду, которые по условиям задачи нужно обработать без DoS. Но и это еще не та цифра, которую стоит обсуждать. Нам надо посчитать количество одновременно обрабатываемых запросов и необходимые для этого ресурсы.
Берем идеальные условия — никаких тяжелых запросов к СУБД, nginx уберает необходимость держать процесс Apache в памяти пока посетитель не скачает всю сгенерированную страницу. Сколько времени в этих условиях будет занимать обработка одного запроса? Это снова сложный вопрос для абстрактного размышления — если взять за основу работу сложного фреймворка с большим bootstrap, то время работы процесса составит 80-100 мсек. Если это нечто легковесное, написанное без тяжелых абстракций, то 40-50 мсек. Для большей точности возьмем вилку 40 — 100 мсек. При нагрузке 500 запросов в секунду это даст нам от 20 до 50 параллельных процессов. Накладные расходы Apache составляют порядка 10 Мб и не забывайте процессорные затраты на fork. Итого лишних 200-500 Мб RAM и около 5-10 мсек драгоценного времени на процесс только ради того, чтобы отработали директивы из .htaccess.
И это, повторяю, в идеальных условиях. На практике же, чем больше параллельных запросов, тем больше времени процессы блокируются базой и другими издержками, вроде дисковых операций, обращения к memcache b/или opcode cache, затрат на переключение процессов в конце концов. А всё ради устаревшей архитектуры CGI и нежелания расставаться с .htaccess. Я вас уверяю — если ваши знакомые найдут в себе силы выбросить apache из цепочки обработки запроса, то они получат для серверов практически бесплатно запас стабильности еще процентов на 10-15, за счет использования сэкономленной памяти и времени. Вообще не меняя ничего в коде своих программ.
Разве я говорил, что уступает? Конечно нет — вопрос «религии» скорее.
Если в случае php-fpm речь идет исключительно об экономии ресурсов на запуск интерпретатора php, то при использовании настоящего асинхронного fast-cgi, вроде упомянутого выше react, (это не выходя за пределы php) можно вообще избежать в ходе обработки запроса накладных расходов на bootstrap, производя его один раз при старте приложения. Вот где на заметном объеме будет существенный выигрыш и Apache потеряет смысл как класс. И в тех же идеальных условиях такое приложение будет тратить на обработку запроса уже не десятки, а единицы милисекунд (ну или упираться в производительность СУБД и других синхронных компонентов).
Статья явно для «начинающих», у которых софтовую часть можно, скорее всего, «перепилить» так, что оно еще проживет какое-то время не то, что без fpm/hhvm etc, а и без масштабирования вообще.
А вот мне так не показалось. Apache тут упомянут вскользь, как не существенная часть идеи, а рецепта построения кластера вообще нет. Это исключительно обзорная статья для тех, кто хочет понять принципы решения задачи масштабирования, а не побыстрячку и не разбираясь, сделать антиDoS на дешевом vps/vds.
софтовую часть можно, скорее всего, «перепилить» так, что оно еще проживет какое-то время не то, что без fpm/hhvm etc, а и без масштабирования вообще.
Статья именно о масштабировании, так что вы явно не правы.
откуда у пресловутых «начинающих», которым и адресована статья, возьмутся «большие» ip-сети хотя бы с десятком реальных ip?
Вопрос единой точки отказа становится актуальным уже при наличии двух параллельных серверов в кластере. Повторяю — статья о горизонтальном масштабировании предназначается только для тех, кто готов завести два и более сервера и вопрос об отсутствии реальных ip в такой ситуации не поднимается вообще. Вы с непонятным мне упорством пытаетесь притянуть за уши чужой материал к актуальному для вас положению вещей. Хотя фактически это для вас же статья для расширения понимания как работать с высокой нагрузкой, когда оптимизации приложения и базы уже не хватает для обслуживания всех желающих.
Да аплинк с реальным гарантированным гигабитом будет стоить часто дороже второго сервера.
Места надо знать. Сервер i7/32G/2T/1gbit стоит всего €41 в месяц у Hezner (без VAT, который жители наших стран не платят). Это копейки для проекта с 10 млн посещений в сутки. И там кстати каналов на 430Gbit, так что хватит на приличный кластер.
Про шаред хостинги я вообще молчу, вполне реальны ситуации, когда 1 IP на сотню «сайтов»
Я о них вспомнил только для того, чтобы проиллюстрировать вашу заботу о начинающих.
я нигде опять же не говорил, что «апач рулит, а fpm отстой», нет. Речь шла о том, что он такой же инструмент, им достаточно много пользуются, и он имеет место быть
Сейчас практически все хостеры прикрыли Apache nginx-ом снаружи, и с удовольствием бы от него избавились совсем, если бы не .htaccess, без которого ни один начинающий не сможет запустить свой сайт. :) Вот он и «имеет место быть».
Вот видите, вы увидели в моей реплике dropbox, а на остальные сетевые fs не обратили внимания. Хотя суть была не в том, чтобы использовать именно dropbox, а в том, чтобы вместо закрытого зашифрованного архива оперировать на своем сервере нормально доступными открытыми данными.
Вот об этом я и талдычу! fuse+cryptfs при всех прочих равных (зашифрованном сетевом хранилище) дают работать rsync для нормальной автоматизации инкрементальных резервных копий.
2. У php главная проблема производительности не в способе запуска интерпретатора. А в издержках самого интерпретатора. Не так уж важно сэкономить 10 мсек на замене mod_php yf php_fpm, когда движок сайта формирует страницу целую секунду. Если обработка запроса в вашем приложении тормозит, то главным образом не из-за апача, как такового, а из-за того, что код или его подгрузка занимает очень много времени, или работу блокируют операции с базой и фс.
Конечно есть. wiki.nginx.org/HttpCoreModule#Variables
И с авторизацией всё в порядке. Читайте доки.
Кстати php-fpm отлично подключается и к Apache. Я так делаю на серверах, где нужно совмещать сайты с .htaccess с остальными — на одних Работает nginx + apache + php-fpm, а н адругих nginx + php-fpm. И это получается даже стабильнее, чем с mod_php.
От веб-сервера надо не так уж много. Тем более, что после создания nginx.inc его разработка серьезно ускорилась. Но уже сейчас его преимущества с лихвой покрывают архитектурные недостатки Apache. Буквально сегодня я собирал для нового сервера ngnix + cache_purge + pagespeed. И при том, что на нем будет работать в том числе и wordpress, мне не пришлось ничего переписывать на php или отказываться от каких-то возможностей.
Ну так это не недостаток — это достоинство nginx. Он в рамках одного потока исполняет до десятков тысяч запросов и просто незачем рассматривать что именно в какой момент он делает. Однако статистика у него тоже есть из коробки и я ее использую для мониторинга нагрузки через munin.
Фронтенд быстрый потому, что он асинхронный неблокирующийся. Когда и бекенд станет использовать такую архитектуру, то можно будет очень сильно экономить на серверах и намного легче масштабировать с влучае нужды. И Apache в этом смысле просто старый и менее удачный опыт, который постепенно уступает место новой и более эффективной архитектуре.
Иными словами вы так же катеогично протестуете против субъективного мнения из-за его категоричности. :)
Вот почему мне не хотелось приходить к фактическим цифрам. Ведь тогда надо лезть в дебри. Мне в принципе не сложно, но будет ли всем полезен этот разговор, особенно учитывая, что вы «знаете» проекты с 10-12 млн просмотров, а я в таких копаюсь. Ну ладно. Попробую без занудства.
Для нагруженного сайта критически важно не суточное число запросов, а мгновенное. Что такое 10 млн суточных хитов (динамики)? Это 116 запросов в секунду при совершенно равномерном распределении за сутки. Так почти не бывает. Более харктерным является 16 нагруженных часов с двумя/тремя пиками нагрузки (развлекаловка вроде фишки.нет) или 50-100-200 рывков по 300-700% хитов на фоне тех же 16 часов среднего трафика (электронные сми). По той нагрузке, что есть у меня, 10 млн хитов должны давать пики в районе 400-500 запросов в секунду, которые по условиям задачи нужно обработать без DoS. Но и это еще не та цифра, которую стоит обсуждать. Нам надо посчитать количество одновременно обрабатываемых запросов и необходимые для этого ресурсы.
Берем идеальные условия — никаких тяжелых запросов к СУБД, nginx уберает необходимость держать процесс Apache в памяти пока посетитель не скачает всю сгенерированную страницу. Сколько времени в этих условиях будет занимать обработка одного запроса? Это снова сложный вопрос для абстрактного размышления — если взять за основу работу сложного фреймворка с большим bootstrap, то время работы процесса составит 80-100 мсек. Если это нечто легковесное, написанное без тяжелых абстракций, то 40-50 мсек. Для большей точности возьмем вилку 40 — 100 мсек. При нагрузке 500 запросов в секунду это даст нам от 20 до 50 параллельных процессов. Накладные расходы Apache составляют порядка 10 Мб и не забывайте процессорные затраты на fork. Итого лишних 200-500 Мб RAM и около 5-10 мсек драгоценного времени на процесс только ради того, чтобы отработали директивы из .htaccess.
И это, повторяю, в идеальных условиях. На практике же, чем больше параллельных запросов, тем больше времени процессы блокируются базой и другими издержками, вроде дисковых операций, обращения к memcache b/или opcode cache, затрат на переключение процессов в конце концов. А всё ради устаревшей архитектуры CGI и нежелания расставаться с .htaccess. Я вас уверяю — если ваши знакомые найдут в себе силы выбросить apache из цепочки обработки запроса, то они получат для серверов практически бесплатно запас стабильности еще процентов на 10-15, за счет использования сэкономленной памяти и времени. Вообще не меняя ничего в коде своих программ.
Если в случае php-fpm речь идет исключительно об экономии ресурсов на запуск интерпретатора php, то при использовании настоящего асинхронного fast-cgi, вроде упомянутого выше react, (это не выходя за пределы php) можно вообще избежать в ходе обработки запроса накладных расходов на bootstrap, производя его один раз при старте приложения. Вот где на заметном объеме будет существенный выигрыш и Apache потеряет смысл как класс. И в тех же идеальных условиях такое приложение будет тратить на обработку запроса уже не десятки, а единицы милисекунд (ну или упираться в производительность СУБД и других синхронных компонентов).
А вот мне так не показалось. Apache тут упомянут вскользь, как не существенная часть идеи, а рецепта построения кластера вообще нет. Это исключительно обзорная статья для тех, кто хочет понять принципы решения задачи масштабирования, а не побыстрячку и не разбираясь, сделать антиDoS на дешевом vps/vds.
Статья именно о масштабировании, так что вы явно не правы.
Вопрос единой точки отказа становится актуальным уже при наличии двух параллельных серверов в кластере. Повторяю — статья о горизонтальном масштабировании предназначается только для тех, кто готов завести два и более сервера и вопрос об отсутствии реальных ip в такой ситуации не поднимается вообще. Вы с непонятным мне упорством пытаетесь притянуть за уши чужой материал к актуальному для вас положению вещей. Хотя фактически это для вас же статья для расширения понимания как работать с высокой нагрузкой, когда оптимизации приложения и базы уже не хватает для обслуживания всех желающих.
Места надо знать. Сервер i7/32G/2T/1gbit стоит всего €41 в месяц у Hezner (без VAT, который жители наших стран не платят). Это копейки для проекта с 10 млн посещений в сутки. И там кстати каналов на 430Gbit, так что хватит на приличный кластер.
Я о них вспомнил только для того, чтобы проиллюстрировать вашу заботу о начинающих.
Сейчас практически все хостеры прикрыли Apache nginx-ом снаружи, и с удовольствием бы от него избавились совсем, если бы не .htaccess, без которого ни один начинающий не сможет запустить свой сайт. :) Вот он и «имеет место быть».