Сделка чисто русский атавизм системы Тейлора который юзают только у нас. Сделка 1. Разлагает менеджмент которому плевать на организацию работ ок работник сам будет бегать в поисках работы и заискивать перед менеджером чтобы получить неё 2 приводит к тотальному браку в производстве что вы и подтверждаеие
Можно и фрилансера хорошего найти и с фирму плохую. Главное что проверить то невозможно зараннее. Фирма может для не очень перспективных задач найти такого же фрилансера и платить фрилансеру как фрилансеру а с заказчика взять как фирма. И знаю конкретный правда ровно один случай когда очень хорошего фрилансера кинули менеджеры от заказчика и его собственный «импрессарио» когда два менеджера устроили междусобойчик и платили ему за разработку сумму на порядок меньше. Фрилансер как-то узнал прекратил сотрудничество и его пришлось заменять одним сеньором, двумя миддлами на бэкэнде + одним миддлом на фронтенде + привлекать верстальщика дя всех новых фич. Но это скорее исключение из правил. При ценах на фриланс (500р — 3000р а что там делать?) ему надо работать очень много и очень быстро тут не до изысков.
Как свидетельстует подпись в эккаунте атора он не имеет отношения к цветочному бизнесу. Он такой-же фрилансер и как и приглащенный им фрилансер-эксперт. Так что фраза «мы облажались» это автор к себе не тоносит т.к. деньги потерял владеец бизнеса а ошибка была неизвестно чья. Т.к. разработчики тот самый сбойный оператор не втсавляли в текст. И посе того как его убрали у меня сразу возщник вопрос. А что же с кассой. Этот оператор был заплаткой т.к. у них не была настроена связь с кассой и не печаталась часть чеков. Ненормативная лексика должна была способствовать продвижению статьи. А статья продвижению сайта автора. См. СЕО, граждане, СЕО.
ДДОС это специфическая тема. 99% сайтов которые не под защитой лягут под простым стресс-тестированием. Правда его легко вычисить по ip адресу и отключить. Просто защита должна быть поставлена точно так эе как настроен почтовый сервер или сервер баз данных. Если ее нет тодаже маленька атака на 7-й уровень с минимального количества устройств достаточного для того чтобы их нельзя было отключить по одному положит среднестатистический сайт с вероятностью 100%.
Как правило, в агентствах одной командой одновременно ведется большое количество проектов. И количество времени, которое они тратят на работу над одним проектов в день, сильно ограничено. Перерабатывать смысла нет, так как сидят за оклад. Мотивация минимальна. Да, фрилансер тоже ведет много проектов одновременно, но здесь он отвечает своей репутацией, в то время как в компании сотрудник – это приходящее/уходящее звено. Не вышел на связь – ну и ладно. Рабочий день закончился – завтра посмотрю.
Не совсем отвечает реальности. Фирлансер в качестве эксперта если Вам с ним конечно повезло сделает независимую оценку Тут главное что никто не знает зараннее хороший фрилансер или не очень. Фрилансер в качестве разработчика — в принципе если хороший сделает хорошо. Но с поддержкой будет сложнее. Его проект не будет знать никто кроме него. По поводу незамотивированных разработчиков из агенств которые сидят на окладе мнение неверное (хотя не исключает то что такие фирмы сущетсвуют и даже в Вашем случае была именно такая фирма). Их форма оплаты завуалированная сделка. Т.к. все часы относятся к проектам и время строго учитывается. В особо тяжелых случаях учет настолько тотальный, что на компьютер устанавливают программы которые делают снимки экранов и в зачет берут только время, когда работник типа топил клавиши. Да и репутации фирме не менее важна, чем фрилансеру.
Да Максим спасибо сам учился по этим учебникам официальная документация по flax особенно просто была слишком непостижима. Немного не хватало год назад учебника по четвёртому роутеру.
Два раза перечитал статью в поисках шуток про java.
Про
Переменные окружения — одна из фундаментальных конструкций среды Node.js,
можно спросить что значит фундаментальность.
Если говорить о переменных окружения то наиболее приемлемый кажется вариант с использованием PM2 pm2.keymetrics.io/docs/usage/environment и вцелом запуск под PM2 кажется наиболее приемлемым для продакшна. Т.к. можно запустить приложение на нескольких ядрах, перезапускать приложение при сбоях и при перерасходе памяти.
А параметры вообще лучше перенести в обычный файл parameters.json, который не хранится в репозитарии а генерируется в диалоге при npm install. (В репозитарии обчыно хранится parameters.dist.json с значениями по умолчанию)
Личные кабинеты, корзины покупателей, или же внутрикорпоративные приложения индексировать не нужно. В любом интернет-магазине самый важный контент это товары. Как правило реализуются как веб-приложение. Их индексировать нужно. Новостные сайты. Так же реализованы как веб-приложения. Тоже их нужно индексировать.
Приндексированный вход в приложение в ряде случаев не поможет. Т.к. клиент скорее всего будет искать поиском «iPhone Y» чем «интернет-магазин электротоваров в Пензе».
prerender.io сейчас работет очень хорошо практически как браузер особено с headless chrome. Но есть одна больша проблема — это скорость. Сложный JavaScript может грузиться 10-20 секунд. Страницы конечно можно кэшировать. Но если страницы постоянно обновляются то кэшировать надолго их не имеет смысла, т.к. они станут неактуальными. А кэшировать не малвй срок (например час или день) тодже не имеет смысла т.к. боты тоже нечасто ходят по ссылкам то есть из кэша ничего не будет браться.
Остается запускать своего бота и несколько раз в день все индексировать. Такие вот проблемы разработчики сами себе создают. Так что наиболее оптимальный путь это все же универсальные приложения (или даже «классические» веб-приложения)
Я наконец понял в чем Ваш вопрос. Автор не говорит что у него было 5000 запрсов в секунду. И для вебсокетов (не в серверном варианте) высокая нагрузка совсем другое подразумевает. Это когда у Вас 5 или 150 тысяч одновременно пользователей открыли соединения из браузера и все они работают не секунду а час или например цеоый день у них приложение открыто и нужно держать постоянно соединение. Я-то думаю откуда у Вас на ноде такие показатели на слабых девайсах.
Или если перейти на серверы то это у вас со всего мира 150 000 серверов к Вами присоединились и держат коннекты. А если у Вас пусть даже миллион сообщений в секунду но от сотни серверов то это как раз сто содеинений а не сто миллионов соединений.
Ага у Вас свой нативный модуль. А как с fallback если веб-скоеті на поддерживаются и актуальнно ли сейчас делать fallback? Говорят что например в некоторых странах (Китай) и некоторые провайдеры (мобилного интернета) эти веб-сокеты не поддерживают. Также поддержка веб-сокетов из соображений скажем безопасности моет быть отключна администраторами корпоративной сети для доступа к внешним сверерам/сайтам.
То есть у Вас одновременно около 1 миллиона одновременно подключившихся активных клиентов? Икакие при этом параметры по серверу/серверам (количество серверов/ядер/объем памяти)?
т. Плюс-минус километр если, то на 200 пользователей при 400 звонках в день и 300 задачах в системе + 40 отправленных сообщений по API в сутки, пиковая нагрузка по RAM была 81mb
На ноде такая загрузка была? Конечно одновременных 200 соединений это почти ничего но все равно я предполагал большую цифру.
Если посмотреть на код можно наверное сказать почему был лимит 5000. Но это не ответит на вопрос какой может быть реальный лимит и какие при этом будут затраты (сколько ядер, сколько памяти, сколько нодов. У Вас есть реаьные данные по nodejs как у атора этой статьи есть реальные данные по фениксу? Расскажите, это интересно.
Не сочтите за наезд. Я просто реально хочу получить реальные данные о реальных серверах (как у автора этой статьи). Какая нагрузка была на приложение? Какие были затраты по памяти/процессорам? Как мониторилась доступнасть веркеров? Сколько было запущено веркеров? Каки были организованы сессии в смысле как отслеживалось чтобы лиибо было соединение с одинм и тем же веркером или же данные расшарвались между веркерами? Расскажите. Это интересно.
Вобщем-то автор не скрывает что это были лишь тесты со «своим клиентом». Цель была присоединиться и держать соединение на что не использщуется основной процесс в коором віполняется JavaScript а только средства NIO. Что будет когда все эти коннеты «заговорят» и потребуют свою долю от движка JavaScript. Большой плюс автора обсуждаемй статьи на Хабре это то что он сделал реальное приложение и показал нам графики реальной загрузки реальной конфигураци сервера.
wouter
April 13, 2015 at 20:37 /
What did you use to generate 620k connections?
And did you send a message over every connection every x seconds or was is just a silent connection?
Daniel Kleveros
April 14, 2015 at 08:11 /
I created my own client with the same websocket lib websockets/ws which I then deployed on a cluster of M1.Large instances.
It was silent connections but to keep the connections alive, if you are behind a elastic load balancer, you need to check the idletimeout setting on the loadbalancer and send a ping before that time expires. If not the load balancer will start to drop your connections.
Далее я рассмотрел Node.JS WS. Этот фреймворк показал неплохие результаты – около 5 тысяч коннектов на тестовом стенде без дополнительных настроек
Возможно 5000. Ссылки на сайт автора у меня нет.
По поводу использования конерктно nodе.js и конерктно для веб-сокетов очень большие вопросы есть. Если бы был реальный пример то можно было бы пробовать реализовать в нагруженном (хотя бы) проекте.
Не совсем отвечает реальности. Фирлансер в качестве эксперта если Вам с ним конечно повезло сделает независимую оценку Тут главное что никто не знает зараннее хороший фрилансер или не очень. Фрилансер в качестве разработчика — в принципе если хороший сделает хорошо. Но с поддержкой будет сложнее. Его проект не будет знать никто кроме него. По поводу незамотивированных разработчиков из агенств которые сидят на окладе мнение неверное (хотя не исключает то что такие фирмы сущетсвуют и даже в Вашем случае была именно такая фирма). Их форма оплаты завуалированная сделка. Т.к. все часы относятся к проектам и время строго учитывается. В особо тяжелых случаях учет настолько тотальный, что на компьютер устанавливают программы которые делают снимки экранов и в зачет берут только время, когда работник типа топил клавиши. Да и репутации фирме не менее важна, чем фрилансеру.
Про можно спросить что значит фундаментальность.
Если говорить о переменных окружения то наиболее приемлемый кажется вариант с использованием PM2 pm2.keymetrics.io/docs/usage/environment и вцелом запуск под PM2 кажется наиболее приемлемым для продакшна. Т.к. можно запустить приложение на нескольких ядрах, перезапускать приложение при сбоях и при перерасходе памяти.
А параметры вообще лучше перенести в обычный файл parameters.json, который не хранится в репозитарии а генерируется в диалоге при npm install. (В репозитарии обчыно хранится parameters.dist.json с значениями по умолчанию)
Приндексированный вход в приложение в ряде случаев не поможет. Т.к. клиент скорее всего будет искать поиском «iPhone Y» чем «интернет-магазин электротоваров в Пензе».
Остается запускать своего бота и несколько раз в день все индексировать. Такие вот проблемы разработчики сами себе создают. Так что наиболее оптимальный путь это все же универсальные приложения (или даже «классические» веб-приложения)
Или если перейти на серверы то это у вас со всего мира 150 000 серверов к Вами присоединились и держат коннекты. А если у Вас пусть даже миллион сообщений в секунду но от сотни серверов то это как раз сто содеинений а не сто миллионов соединений.
Не сочтите за наезд. Я просто реально хочу получить реальные данные о реальных серверах (как у автора этой статьи). Какая нагрузка была на приложение? Какие были затраты по памяти/процессорам? Как мониторилась доступнасть веркеров? Сколько было запущено веркеров? Каки были организованы сессии в смысле как отслеживалось чтобы лиибо было соединение с одинм и тем же веркером или же данные расшарвались между веркерами? Расскажите. Это интересно.
Возможно 5000. Ссылки на сайт автора у меня нет.
По поводу использования конерктно nodе.js и конерктно для веб-сокетов очень большие вопросы есть. Если бы был реальный пример то можно было бы пробовать реализовать в нагруженном (хотя бы) проекте.