Комментарии 80
*шутка о названии*
оффтоп: почему на заглавной картинке Шварц не обхватывает штангу большими пальцами?
Это открытый хват. Возможно, чтобы снять нагрузку с предплечья.
Это «открытый хват». Очень опасный, т.к. гриф может соскользнуть, но часто видел что его используют опытные спортсмены. Вот тут не знаю почему — особых преимуществ и отличий от «закрытого хвата» он не даёт (по крайней мере, так пишут). Может потому что могу? :)
P.S. Не обновил комментарии.
P.S. Не обновил комментарии.
Открытый хват используется лишь в тренировочных подходах (на соревнованиях он запрещен) для большего включения всех пучков трицепса, ну и кому-то, он может быть более удобен для кистей/предплечий, но это индивидуально: например, французский жим кому-то убивает локти, а кому-то вполне себе удобное упражнение.
В моем случае, так проще жать, + 5кг :)
Вернее одна проблема – размер БД. Есть, конечно, шардинг, но стандартного решения для PostgreSQL без падения производительности пока не нашли. Если кто-то может поделиться практическим опытом – welcome!
Pl/Proxy, Postgres-XC (3x при 5 нодах), Postgres-XL, Pg_shard? Понятное дело, что при 2-3 нодах шардинг система не имеет особого смылса.
Как клиент, готов подтвердить, что api работает мгновенно, так же как и виджеты. И радует то, что мы даже не подозреваем о каких-либо проблемах с базой на вашей стороне. Случай редкий и очень радует. Спасибо.
У вас видимо nginx староват, по вашей же ссылке в прокси-модуле можно обнаружить вкусности типа директив proxy_cache_lock*, которые могут заметно сгладить всплески просачивающихся на бэкенд запросов при устаревании кеша.
А почему вы не хотите сделать шардинг сами, на уровне приложения?
А почему вы не хотите сделать шардинг сами, на уровне приложения?
>А почему вы не хотите сделать шардинг сами, на уровне приложения?
Все идет именно к этому =)
PS: спасибо за proxy_cache_lock, посмотрю!
Все идет именно к этому =)
PS: спасибо за proxy_cache_lock, посмотрю!
Посмотрел proxy_cache_lock, это не много не то, вернее вообще не то =)
Как я понимаю, данная опция просто блокирует остальных, кто ждет кеша, пока первый кто-то его не заполнит.
Думаю в нашем случае это ухудшит производительность сделав заметным небольшие «замирания» системы, а так все асинхронно, никто ни от кого не зависит.
Как я понимаю, данная опция просто блокирует остальных, кто ждет кеша, пока первый кто-то его не заполнит.
Думаю в нашем случае это ухудшит производительность сделав заметным небольшие «замирания» системы, а так все асинхронно, никто ни от кого не зависит.
Во-первых, замирание будет равно времени ответа бэкенда.
Во-вторых, вы говорите про 2700 запросов в секунду в пике. Предположим, кеш протух и его обновление занимает 100мс (т.е. бэкенд на этот запрос отвечает за 100мс). Соответственно, в момент протухания кеша на ваш бэкенд пойдет примерно 270 одинаковых запросов практически одновременно! И все эти клиенты получат ответ не ранее чем через 100мс, а скорее даже позже, т.к. ваш бэкенд в любом случае будет работать медленнее при множестве одновременных запросов.
В случае использования proxy_cache_lock на ваш бэкенд уйдет всего один запрос, который обновит кеш за 100мс и все клиенты, ждущие этот кеш (грубо говоря 269 клиентов) получат ответ за те же 100мс, но при этом бэкенд обработал один запрос вместо 270.
Во-вторых, вы говорите про 2700 запросов в секунду в пике. Предположим, кеш протух и его обновление занимает 100мс (т.е. бэкенд на этот запрос отвечает за 100мс). Соответственно, в момент протухания кеша на ваш бэкенд пойдет примерно 270 одинаковых запросов практически одновременно! И все эти клиенты получат ответ не ранее чем через 100мс, а скорее даже позже, т.к. ваш бэкенд в любом случае будет работать медленнее при множестве одновременных запросов.
В случае использования proxy_cache_lock на ваш бэкенд уйдет всего один запрос, который обновит кеш за 100мс и все клиенты, ждущие этот кеш (грубо говоря 269 клиентов) получат ответ за те же 100мс, но при этом бэкенд обработал один запрос вместо 270.
в самом загрузчике (widget.js), выбирая бекенд случайным образом.
Зачем? Чтобы браузеры каждый раз перезагружали ваш виджет снова и снова? Считая, что они грузят их с разных сайтов.
Сделайте DNS round-robin, укажите 20 серверов — тогда можно будет закешировать после 1 обращения.
Спасибо!
DNS round-robin — рассматривали, но он в разы менее гибок (если надо что-то срочно менять), чем round-robin на JS.
DNS round-robin — рассматривали, но он в разы менее гибок (если надо что-то срочно менять), чем round-robin на JS.
Понимаю, но как мне видится, у вас должно быть сейчас очень много трафика лишнего за счет того, что клиент не может закешировать надолго загружаемые файлы. И что хуже — решение не масштабируется.
Если пока не готовы делать как я описал ниже — то попробуйте вынести всю статику на вообще отдельные хосты и поставить их на хорошие каналы.
Если пока не готовы делать как я описал ниже — то попробуйте вынести всю статику на вообще отдельные хосты и поставить их на хорошие каналы.
BGP должно вас спасти. Но для этого нужны свои IP адреса. Время простоя при BGP-балансировке на 2 порядка меньше, чем при DNS/JS балансировке
Какой размер данных (количество / размер) у вас в микрокэшах? При большой частоте перезаписи дисковая подсистема становится узким местом.
Вообще у вас очень странно устроена сетевая часть.
С одной стороны — приличный трафик, сервера стоят в разных странах, а с другой — рандомные хосты в урлах.
При таком трафике лучше сделать свою автономную систему и провайдеро-незаввисимую сеть адресов.
Далее: анонсируете сетку из каждой точки присутствия. И каждый пользователь автоматически пойдет на ближайшее к себе зеркало и заберет оттуда статику. Кроме того: микрокеши нгинкса вы сможете размещать максимально близко к пользователю. Если вдруг пошла мощная нагрузка, то она пошла на одно зеркало и там и осталась.
Плюсы:
+ ускорение загрузки — всегда берется с ближайшего зеркала
+ повышение отказоустойчивости — если одно зеркало упало, нагрузка сама перетечет на другие
+ улучшение кеширования статики — вы можете сильно увеличить DNS TTL и Expires — хоть на год — т.к. и домен и адреса ваши
+ легкость масштабирования — ставите в нужный ДЦ поближе к юзерам, включаете — все работает
+ сокращение расходов на трафик — да, вы получите качество намного выше за заметно меньшие деньги
Минусы:
— вам нужен грамотный сетевой администратор
С одной стороны — приличный трафик, сервера стоят в разных странах, а с другой — рандомные хосты в урлах.
При таком трафике лучше сделать свою автономную систему и провайдеро-незаввисимую сеть адресов.
Далее: анонсируете сетку из каждой точки присутствия. И каждый пользователь автоматически пойдет на ближайшее к себе зеркало и заберет оттуда статику. Кроме того: микрокеши нгинкса вы сможете размещать максимально близко к пользователю. Если вдруг пошла мощная нагрузка, то она пошла на одно зеркало и там и осталась.
Плюсы:
+ ускорение загрузки — всегда берется с ближайшего зеркала
+ повышение отказоустойчивости — если одно зеркало упало, нагрузка сама перетечет на другие
+ улучшение кеширования статики — вы можете сильно увеличить DNS TTL и Expires — хоть на год — т.к. и домен и адреса ваши
+ легкость масштабирования — ставите в нужный ДЦ поближе к юзерам, включаете — все работает
+ сокращение расходов на трафик — да, вы получите качество намного выше за заметно меньшие деньги
Минусы:
— вам нужен грамотный сетевой администратор
Если я правильно вас понимаю, то речь о своем CDN?
Скорее о anycast. посмотрите как устроен root dns.
в сетевом мире есть такая штука, называется она hot potato routing.
в сетевом мире есть такая штука, называется она hot potato routing.
По сути да.
Причем вас никто не обязывает сразу строить огромную сеть — можно начать всего с 2 узлов и вы уже почувствуете экономию. А дальше просто добавляете по мере необходимости. Масштабирование практически линейное. Вся система даже с учетом зарплаты хорошего админа быстро отбивает свои вложения. Когда построите, поймете сколько шкур дерут провайдеры с CDN :)
Причем вас никто не обязывает сразу строить огромную сеть — можно начать всего с 2 узлов и вы уже почувствуете экономию. А дальше просто добавляете по мере необходимости. Масштабирование практически линейное. Вся система даже с учетом зарплаты хорошего админа быстро отбивает свои вложения. Когда построите, поймете сколько шкур дерут провайдеры с CDN :)
При таком трафике лучше сделать свою автономную систему и провайдеро-незаввисимую сеть адресов.
Насколько сложно сейчас получить PI адреса и свою AS? Хотя бы /24?
А, давайте, я вам задам вопрос: почему «какл»? Уж очень неблагозвучно.
Хм, странно. Мне казалось, что такой вопрос уже был, но оказывается, это был не вопрос.
Blue water еще интереснее звучит :)
В качестве CDN для статических данных рассматривались варианты с CloudFlare и Яндекс.Диском?
Про Яндекс ничего не слышали, а вот CloudFlare конечно, но там такие цены… уже лучше свой сделать.
1) У Cloudflare первые три тарифа стоят 0, 20 и 200 долларов за сайт, т.е. более чем умеренно.
Кэширование статики доступно даже на бесплатном.
2) «Про Яндекс ничего не слышали» — это Вы про Яндекс вообще, или только про Яндекс.Диск???
Слышать тут нечего — заходите на disk.yandex.ru, размещаете на нём статический контент, веб-ссылки на него вставляете в динамический, который раздаёте сами. Дальше забота Яндекса, чтобы доставить клиенту статику с максимальной надёжностью за минимальное время.
Кэширование статики доступно даже на бесплатном.
2) «Про Яндекс ничего не слышали» — это Вы про Яндекс вообще, или только про Яндекс.Диск???
Слышать тут нечего — заходите на disk.yandex.ru, размещаете на нём статический контент, веб-ссылки на него вставляете в динамический, который раздаёте сами. Дальше забота Яндекса, чтобы доставить клиенту статику с максимальной надёжностью за минимальное время.
Конечно, про Диск =)
ИМХО, но думаю у Яндекс.Диска есть лимиты по скорости (они вообще-то везде есть) так как bandwidth везде платный. Думаю для продакшена это плохое решение )
ИМХО, но думаю у Яндекс.Диска есть лимиты по скорости (они вообще-то везде есть) так как bandwidth везде платный. Думаю для продакшена это плохое решение )
1) У нас был опыт переговоров с компаниями предоставляющими CDN, их тарифы только для самих сайтов, не предоставляющих внешние (embedded) решения для других порталов.
Например вот это $200 per month for each website, означает, что статика будет доступна только для запросов с referer-ом самого сайта, а если вы виджет используете, то это уже 2й сайт, а у нас 34 000 сайтов =))
Например вот это $200 per month for each website, означает, что статика будет доступна только для запросов с referer-ом самого сайта, а если вы виджет используете, то это уже 2й сайт, а у нас 34 000 сайтов =))
Кстати, это случайно не то, что вам нужно?
habrahabr.ru/company/yandex/blog/255357
habrahabr.ru/company/yandex/blog/255357
Хотел написать про директиву proxy_cache_methods, которую можно использовать вместо условия с проверкой методов, но потом понял идею с кукой и сбросом кеша для тех, кто что-то запостил, красивое решение.
Вы пишите о нерешенной проблеме с размером БД. Можно поинтересоваться, о каких объемах речь и что было сделано в плане тюнинга?
Большое спасибо за интересную статью!
Касательно ручного шардинга PostgreSQL. Судя по отзывам, неплохо работает схема вроде следующей.
Определяете, по какому ключу шардите. Например, это id пользователя. Заводите множество небольших БД, каждая, например, ровно на 1000 пользователей. База 1 держит пользователей 1-1000, база 2 — пользователей 1001-2000 и так далее. Если в БД уже есть 1000 пользователей, заводите новую. Один сервер PostgreSQL держит несколько баз, в зависимости от крутости железа и числа запросов к этим БД. Если нагрузку сервер больше не держит, заводите новый сервер. При обновлении сервера в поднятый на нем PostgreSQL можно перенести бОльшее число баз. Для определения какая БД на каком сервере лежит используется «словарь» который можно держать, скажем, в Redis.
Остается проблема распределенных транзакций, если приложению нужно передавать что-то между пользователями живущими в разных БД. Почти рабочее решение описано в этой статье (в описанном там чтении нет изолированности, решается выполнением транзакции на запись тех же значений, что считали). Альтернативный вариант, более колхозный, описан здесь. Кто-то предпочитает 2PC, но он его сложно реализовать, чтобы он работал при падении узлов или клиента, выполняющего транзакцию, нужно какой-то Raft/Paxos еще прикручивать.
С удовольствием прочитал бы другие заметки о том, как у вас все устроено. Интересуют вопросы из этого списка, например, вы совсем не рассказали про ваши метрики, мониторинг и агрегацию логов.
Касательно ручного шардинга PostgreSQL. Судя по отзывам, неплохо работает схема вроде следующей.
Определяете, по какому ключу шардите. Например, это id пользователя. Заводите множество небольших БД, каждая, например, ровно на 1000 пользователей. База 1 держит пользователей 1-1000, база 2 — пользователей 1001-2000 и так далее. Если в БД уже есть 1000 пользователей, заводите новую. Один сервер PostgreSQL держит несколько баз, в зависимости от крутости железа и числа запросов к этим БД. Если нагрузку сервер больше не держит, заводите новый сервер. При обновлении сервера в поднятый на нем PostgreSQL можно перенести бОльшее число баз. Для определения какая БД на каком сервере лежит используется «словарь» который можно держать, скажем, в Redis.
Остается проблема распределенных транзакций, если приложению нужно передавать что-то между пользователями живущими в разных БД. Почти рабочее решение описано в этой статье (в описанном там чтении нет изолированности, решается выполнением транзакции на запись тех же значений, что считали). Альтернативный вариант, более колхозный, описан здесь. Кто-то предпочитает 2PC, но он его сложно реализовать, чтобы он работал при падении узлов или клиента, выполняющего транзакцию, нужно какой-то Raft/Paxos еще прикручивать.
С удовольствием прочитал бы другие заметки о том, как у вас все устроено. Интересуют вопросы из этого списка, например, вы совсем не рассказали про ваши метрики, мониторинг и агрегацию логов.
Спасибо!
>метрики, мониторинг и агрегацию логов
Это все делаем вручную, к сожалению, то есть надо что-то проанализировать, лог например, пишем свой парсер, мониторинг примерно так же устроен.
Проблема в том, что стандартные решения, при наших нагрузках, например мониторинг Tomcat-а, уронят нам всю систему =)
>метрики, мониторинг и агрегацию логов
Это все делаем вручную, к сожалению, то есть надо что-то проанализировать, лог например, пишем свой парсер, мониторинг примерно так же устроен.
Проблема в том, что стандартные решения, при наших нагрузках, например мониторинг Tomcat-а, уронят нам всю систему =)
НЛО прилетело и опубликовало эту надпись здесь
Единственный нюанс — это большие модификации базы (ALTER TABLE) при релизах. Делать их надо кусками, стараясь не выполнять за раз весь UPDATE.
А не пробовали использовать replication slot?
Меня как потенциального пользователя продуктов отталкивает две вещи:
1. Убогий дизайн продуктов. Даже если вдруг у вас есть возможность сверстать свой дизайн я хотел бы видеть «все красиво» из коробки, тот же Jivosite гораздо лучше в этом плане (хотя раньше он здорово отставал в этом вопросе). Siteheart тоже ничего.
Сюда же можно включить откровенно слабый дизайн офсайта (привет, бутстрап) и жуткий лого.
2. Название компании. В качестве примера — некоторые компании со звучными названиями типа «хуньсуй» в Россию приходят с адаптированным потребителю названием. Как и наоборот Mail.ru на американском рынке My.com. У вас же компания, насколько показало 20-секундное изучение вашего сайта — русская и выходить с названием «какл» на мой взгляд не очень удачно. Даже несмотря на то, что я какое-то время пользовался потребпродукцией Хуавей (пользовательский опыт, в общем-то, совпадает с названием).
Итого: возможно, хорошие продукты, интересный рассказ по серверной части, но пока все будет оставаться так, как есть сейчас — попыток пользоваться вашей продукцией я предпринимать не буду.
На мой вкус, тут требуется вмешательство маркетологов и ребрендинг. Надеюсь, мой комментарий поможет вам стать лучше.
1. Убогий дизайн продуктов. Даже если вдруг у вас есть возможность сверстать свой дизайн я хотел бы видеть «все красиво» из коробки, тот же Jivosite гораздо лучше в этом плане (хотя раньше он здорово отставал в этом вопросе). Siteheart тоже ничего.
Сюда же можно включить откровенно слабый дизайн офсайта (привет, бутстрап) и жуткий лого.
2. Название компании. В качестве примера — некоторые компании со звучными названиями типа «хуньсуй» в Россию приходят с адаптированным потребителю названием. Как и наоборот Mail.ru на американском рынке My.com. У вас же компания, насколько показало 20-секундное изучение вашего сайта — русская и выходить с названием «какл» на мой взгляд не очень удачно. Даже несмотря на то, что я какое-то время пользовался потребпродукцией Хуавей (пользовательский опыт, в общем-то, совпадает с названием).
Итого: возможно, хорошие продукты, интересный рассказ по серверной части, но пока все будет оставаться так, как есть сейчас — попыток пользоваться вашей продукцией я предпринимать не буду.
На мой вкус, тут требуется вмешательство маркетологов и ребрендинг. Надеюсь, мой комментарий поможет вам стать лучше.
Ну и еще мелочи — 
Каким образом стало возможно проставлять количество в нулях, а главное — зачем?
Минимальный объем заказываемой услуги никак не может быть меньше 1.
Каким образом стало возможно проставлять количество в нулях, а главное — зачем?
Минимальный объем заказываемой услуги никак не может быть меньше 1.
Спасибо за объемный комментарий. От части вы правы, НО…
Название, дизайн сайта, маркетинг — это не сделает наших клиентов счастливыми. А вот подъем конверсии их сайта, за счет наших сервисов, вполне себе осчастливит любого. Это мы и делаем, мы создаем системы, чтобы помогать людям!
Например, сравните хотя бы нашу систему сбора отзывов Cackle Reviews с подобными, разрекламированными, из рунета, и вы поймете о чем я ;)
Название, дизайн сайта, маркетинг — это не сделает наших клиентов счастливыми. А вот подъем конверсии их сайта, за счет наших сервисов, вполне себе осчастливит любого. Это мы и делаем, мы создаем системы, чтобы помогать людям!
Например, сравните хотя бы нашу систему сбора отзывов Cackle Reviews с подобными, разрекламированными, из рунета, и вы поймете о чем я ;)
оффтоп: В комментариях уже несколько раз упоминалось неблагозвучное название. А как вообще правильно произносить название Вашей компании? Не могли бы Вы по русски его написать?
Вы игнорируете написанное мной?
Я написал, что мне, как клиенту — не нравится дизайн в первую очередь продукта (онлайн-консультант), а не сайта.
С системой отзывов все то же — у нее проблемы с юзабилити, в отличие от того же Hypercomments.
Я написал, что мне, как клиенту — не нравится дизайн в первую очередь продукта (онлайн-консультант), а не сайта.
С системой отзывов все то же — у нее проблемы с юзабилити, в отличие от того же Hypercomments.
Будут очень благодарен, если услышу от вас хотя бы 3-4 проблемы юзабилити системы комментариев (в отличие от того же Hypercomments). Можете кстати их написать на support@cackle.me.
Вы все время уходите от вопроса дизайна основных продуктов, например, того же виджета Онлайн-консультанта.
А скриншот сравнения Hypercomments и вашего виджета консультирования приведен выше, любой юзабилист скажет что в нем можно изменить, дабы он не смотрелся как поделка 2005х годов.
Для начала обратите внимание на обводку иконок, их количество и шрифты.
А скриншот сравнения Hypercomments и вашего виджета консультирования приведен выше, любой юзабилист скажет что в нем можно изменить, дабы он не смотрелся как поделка 2005х годов.
Для начала обратите внимание на обводку иконок, их количество и шрифты.
>Для начала обратите внимание на обводку иконок, их количество и шрифты.
1) Кол-во провайдеров(если вы про них) клиент выбирает в настройках
2) Дизайн любого элемента виджета (в том числе шрифты, обводка) может быть определен через Редактор стиля(выбрать элемент, а затем свойства).
Также дизайн может быть переопределен через стили на сайте путём прописывания более глубоких селекторов и директивы !important.
3) Если этого недостаточно, то через api есть возможность определить html шаблон
1) Кол-во провайдеров(если вы про них) клиент выбирает в настройках
2) Дизайн любого элемента виджета (в том числе шрифты, обводка) может быть определен через Редактор стиля(выбрать элемент, а затем свойства).
Также дизайн может быть переопределен через стили на сайте путём прописывания более глубоких селекторов и директивы !important.
3) Если этого недостаточно, то через api есть возможность определить html шаблон
А еще можно купить Жигули, поставить двигатель от Мерседеса…
Я, как среднестатистический клиент, хочу видеть «красиво» из коробки, а не менять дизайн и подключать по API. Обратите внимание, я уже указывал это в комментарии выше.
Если конкуренты уже предоставляют мне консультанта в симпатичной обертке, зачем мне Какл?
Но, я так чувствую — тут бесполезно что-то доказывать, поскольку мое мнение никого не интересует.
Я, как среднестатистический клиент, хочу видеть «красиво» из коробки, а не менять дизайн и подключать по API. Обратите внимание, я уже указывал это в комментарии выше.
Если конкуренты уже предоставляют мне консультанта в симпатичной обертке, зачем мне Какл?
Но, я так чувствую — тут бесполезно что-то доказывать, поскольку мое мнение никого не интересует.
На вкус и цвет, как говорится…
Именно поэтому у нас сотни различных настроек и возможностей API, которые кстати и появились именно из потребностей наших клиентов — максимально подогнать наши решения под свой сайт. Темы постоянно обновляются, и мы внимательно слушаем различные предложения и вас услышали и подумаем, что можно улучшить.
Не нравится дизайн Cackle и не хотите ничего подстраивать под свой сайт, и знаете что есть подходящие решения — так и используйте их. Или с этим какие-то проблемы?
Именно поэтому у нас сотни различных настроек и возможностей API, которые кстати и появились именно из потребностей наших клиентов — максимально подогнать наши решения под свой сайт. Темы постоянно обновляются, и мы внимательно слушаем различные предложения и вас услышали и подумаем, что можно улучшить.
Не нравится дизайн Cackle и не хотите ничего подстраивать под свой сайт, и знаете что есть подходящие решения — так и используйте их. Или с этим какие-то проблемы?
Вынужден признать, что название выбрано действительно удачно. Посту уже 5 дней, а я все никак не могу выкинуть из головы этот какл.
Почему какл если кейкл?:)
Не факт — вот на мой комментарий о правильном произношении ( habrahabr.ru/company/cackle/blog/255013/#comment_8370875 ) представители компании не ответили :)
Почему используется Debian, а не FreeBSD?
потому что KDE пропачить не смогли?
KDE? На сервере??
Хороший троллинг! =)
Хороший троллинг! =)
Я страшно извиняюсь, если неправильно понял, но мне показалось, что вы не в курсе…
Nginx и PostgreSQL в портах FreeBSD гораздо свежее, чем в Debian.
А что будет, если один из серверов для виджетов будет недоступен?
В те года идея таких стартапов витала в воздухе, появились, вы, Disqus, hypercomments.
Но многих останавливали правовые вопросы.
Представьте, что прошёлся бот по всем сайтам и оставил разные запрещённые комментарии, которые так не любит роскомнадзор. Или банально ссылка на бесплатную mp3. Обязательную модерацию не все осилят, вовремя удалить комментарий — тоже. В этом случае есть опасность блокировки и ресурса, где размещен комментарий, и вашего ресурса как технологической платформы?
Прост я с таким сталкивался, видел предписание прокуратуры, и блокировку сервера датацентром, даже за простую ссылку на mp3 (то что можно яндексу/гуглу, нельзя простым людям).
Но многих останавливали правовые вопросы.
Представьте, что прошёлся бот по всем сайтам и оставил разные запрещённые комментарии, которые так не любит роскомнадзор. Или банально ссылка на бесплатную mp3. Обязательную модерацию не все осилят, вовремя удалить комментарий — тоже. В этом случае есть опасность блокировки и ресурса, где размещен комментарий, и вашего ресурса как технологической платформы?
Прост я с таким сталкивался, видел предписание прокуратуры, и блокировку сервера датацентром, даже за простую ссылку на mp3 (то что можно яндексу/гуглу, нельзя простым людям).
Хороший вопрос!
Мы на практике с этим начали сталкиваться примерно года 2 назад. В каждом случае, Роскомнадзор сначала оповещает сайт, что вот на этой странице есть у вас вот такой комментарий, надо его убрать. Блокировок пока ни разу не видели, но если бы они и были, то естественно затронули бы сам сайт клиента, а не нашу систему.
Кстати мы даже добавили причину бана (удаления) — «Не соответствует требованию Роскомнадзора» :)
Мы на практике с этим начали сталкиваться примерно года 2 назад. В каждом случае, Роскомнадзор сначала оповещает сайт, что вот на этой странице есть у вас вот такой комментарий, надо его убрать. Блокировок пока ни разу не видели, но если бы они и были, то естественно затронули бы сам сайт клиента, а не нашу систему.
Кстати мы даже добавили причину бана (удаления) — «Не соответствует требованию Роскомнадзора» :)
почему tomcat а не netty если у вас такие высокие нагрузки?
В интернете очень много статей на счет сравнения производительности Tomcat и Netty, дак вот на больших нагрузках последний начинает вести себя гораздо хуже. Tomcat проверенное «production-ready» решение, советую именно его.
В статье написано, что используется WebSocket, как один из возможных средств доставки сообщений клиенту, Tomcat, как servlet контейнер. А как Вы web socket в Tomcat реализовывали? С помощью Tomcat-зависимых «штук»? А то, насколько я знаю, в Java пока ещё нет стандарта на WebSocket.
Конечно нет, при таких нагрузка Tomcat ну никак нельзя соединять с Real-time.
Мы используем github.com/wandenberg/nginx-push-stream-module, если интересно, то вот об этом подробнее habrahabr.ru/company/cackle/blog/167895. Tomcat просто оповещает сервер Nginx с данным модулем асинхронным POST сообщением о новом событии (публикация комментария, отзыва, сообщение, редактирование, голосование и т.д.).
PS: И вообще-то в Tomcat-е есть WebSocket на 7ке с подключенным jdk7, мы используем 6 и при старте каждый раз вот такое сообщение получаем:
Мы используем github.com/wandenberg/nginx-push-stream-module, если интересно, то вот об этом подробнее habrahabr.ru/company/cackle/blog/167895. Tomcat просто оповещает сервер Nginx с данным модулем асинхронным POST сообщением о новом событии (публикация комментария, отзыва, сообщение, редактирование, голосование и т.д.).
PS: И вообще-то в Tomcat-е есть WebSocket на 7ке с подключенным jdk7, мы используем 6 и при старте каждый раз вот такое сообщение получаем:
INFO: JSR 356 WebSocket (Java WebSocket 1.0) support is not available when running on Java 6. To suppress this message, run Tomcat on Java 7, remove the WebSocket JARs from $CATALINA_HOME/lib or add the WebSocketJARs to the tomcat.util.scan.DefaultJarScanner.jarsToSkip property in $CATALINA_BASE/conf/catalina.properties. Note that the deprecated Tomcat 7 WebSocket API will be available.Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Облачные сервисы под высокой нагрузкой. Опыт Cackle