очень интересные ребята, нет никакого анинстала

мои рекомендации - прописать все сервисы из докер-композа на локальной тачке + localunixsocket в /etc/hosts

а вдруг получится

Антон, вы не поверите, я вчера попробовал подцепить кеш одного хрома на другой хром через resilio, и ЗАРАБОТАЛО. Хромы были на разных виртуалках.

127.0.0.1 localunixsocket localunixsocket.local db app ruby redis rabbitmq

в самой ос надо в настройках сетки поставить exclude short names

и примерно 30% быстрее начинает работать

ну там достаточно умная система была

Очень интересно. Охотно бы учился. Есть какой-то must read по скраппингу?

за счет быстрого резолвинга

напишу как-нить пост

с тем, что смог

Антон, вы не поверите, я вчера попробовал подцепить кеш одного хрома на другой хром через resilio, и ЗАРАБОТАЛО. Хромы были на разных виртуалках.

ну тогда общий волюм и можно не париться. а точно оно видело закешированное другим хромом?

есть еще kickass шел скрипт

в принципе фантом и есть хром

Да вроде, просто некоторых апи нет

который отключает purge

и ускоряет docker на маке еще на 30%

это обычный курл с запуском в параллели через multiget

Спасибо, посмотрю.

Очень интересно. Охотно бы учился. Есть какой-то must read по скраппингу?

только опыт) ну и против реакта только хром/вебкит

вчера фронтенд-разраб пришел, грит, чет твой солюшен медленно работает, он бедняга два дня фронт строил с рендером страницы в 40 секунд

применили последовательно все ускорители - ща за 2,5 секунды рисует через докер страницу

nginx + passenger/ruby -> docker -> хром

ну тогда общий волюм и можно не париться. а точно оно видело закешированное другим хромом?

Ага, посмотрел в Chrome DevTools -> Network -> куча "from disk cache" и довольно упала время загрузки (27-33 сек -> 8-11 сек)

вчера фронтенд-разраб пришел, грит, чет твой солюшен медленно работает, он бедняга два дня фронт строил с рендером страницы в 40 секунд

Мдаа

применили последовательно все ускорители - ща за 2,5 секунды рисует через докер страницу

Очень круто получилось!

nginx + passenger/ruby -> docker -> хром

passenger это штука чисто для руби?

применили последовательно все ускорители - ща за 2,5 секунды рисует через докер страницу

А что за ускорители?

ну тогда общий волюм и можно не париться. а точно оно видело закешированное другим хромом?

Просто как я понял, resilio дает что-то похоже на транзакционность, а вот если через volume?

ну и включенные оптимизации на стороне руби)

звучит опасно, но работает как часы

ну меня в общем сейчас напрягает больше работа с fs)

а что сделает выключение full-sync-on-flush?

на маке большую часть времени занимает именно внутренний резолв хостов

оно перестает трясти диск

хм, спасибо, потестирую

Добрый день, товарищи!) Подскжите, пожалуйста: юзаю swarm, у меня 2 мастера (воркеров нет). По докам надо держать нечетное количество мастеров. Однако, когда вырубается на обнову один из мастеров, то второй остается в одиночестве. Вроде-как он должен придти к консенсусу быстро, ан нет. Почему так?

точнее, там и консенсуса быть не может - мастер один живой

почему выборы из трех работают лучше выбора из двух или одного?

когда ты один - ты не можешь стать главным, тебя никто не назначит

passenger это штука чисто для руби?

passenger не нужен, есть пума и уникорн для олдфагов

пума имеет свои интересные особенности, о которых узнаешь на высокой скорости запросов

но да ладно, свой опыт - это свой опыт)

пума имеет свои интересные особенности, о которых узнаешь на высокой скорости запросов

очень интересно, а можно поподробнее ;)

ключевой вопрос в архитектуре

ага, понял. Ок, как тогда лучше организовать? У меня есть 2 сервера, где надо развернуть приложение. Я так понимаю, swarm тут не зайдет?

фьюжн делает много процессов, пума пускает несколько нитей, далее думайте сами, что произойдет, если один из пострадавших отъезжает

Даже если я сделаю 3 сервера, то как их организовывать? 3 мастера? После начал обновления одного два других поссорятся. Если сделаю 2 мастера + 1 воркер, то опять останется один.

когда остается два - один выбирает другого, выборы завершены

но в этот момент лучше послать весточку родным

чтобы родили и привели нового

а, понял

когда два - один дома, и так несколько серий подряд

тогда самый главный вопрос - почему заакрывается соединение на момент выбора лидера? Т.е. почему оно не висит до тех пор?

Т.е. клиент приходит, а у меня срач между контейнерами. Так логичнее было бы держать соединение до тех пор, пока не придет еще один контейнер и не решит вопрос

ну эт вроде можно решать на уровне балансера

и стики сешнс

хм, а чем стики тут поможет?

старые не отвалятся, это главное

новые могут подождать

ну стики пробрасывает запрос напрямую в контейнер не учитывая балансер. А у меня контейнер говорит user@sm-aida:~$ curl localhost:3001 curl: (7) Failed to connect to localhost port 3001: Connection refused

пока не придет второй

или тут стики на уровне swarm?

надо делать хелсчек

как только контейнер отваливается, сварм должен подымать нового

так и есть

и всех новых на него пускать

пускай там товарищи голосуют

так, тогда вообще не понял(

как выборы закончились, отваливать этого новенького

как такое организовать?

вручную, сварм в такое не умеет

ааа

я то думал =)

ну как бы 80% кейсов решит нечетное число мастеров, минимум три

выборы будут короткими

сколько в среднем?

от 30 секунд до обработки первого

т.е. 30 секунд будет даунтайм?

я бы со сложной логикой шел бы в кубернетис

сварм это все таки на коленке

так и логика сложная не нужна

надо чтобы даунтайма не было