Комментарии 76
Прекрасная и очень вменяемая статья, спасибо большое.
Внятно, по делу и без приукрас вида «мы тут hello world за 10 минут сделали».
Комментарий: Sync, безусловно жизненно необходим, хотя и уродлив. Лучше, чем без него, но что поделать. Как он, кстати, будет пробрасывать исключения? Файбер или тред клевы именно тем, что в них внятно пробрасываются исключения.
Вопрос: можете ли вы отказаться от nginx в этой ситуации? Я бы ради кометов и вебсокетов не особо волнуясь поставил бы веб-сервер на erlang вместо nginx.
Просто порт 4000 — всё таки штука стремная, отвалится у многих пользователей.
Насколько можно сервер на ноде втыкать вперед?
Внятно, по делу и без приукрас вида «мы тут hello world за 10 минут сделали».
Комментарий: Sync, безусловно жизненно необходим, хотя и уродлив. Лучше, чем без него, но что поделать. Как он, кстати, будет пробрасывать исключения? Файбер или тред клевы именно тем, что в них внятно пробрасываются исключения.
Вопрос: можете ли вы отказаться от nginx в этой ситуации? Я бы ради кометов и вебсокетов не особо волнуясь поставил бы веб-сервер на erlang вместо nginx.
Просто порт 4000 — всё таки штука стремная, отвалится у многих пользователей.
Насколько можно сервер на ноде втыкать вперед?
> Комментарий: Sync, безусловно жизненно необходим, хотя и уродлив.
Нотацию «someObject.someMethod.sync(someObject, arg1, arg2)» необходимо использовать только для вызова сторонних функций, которые не обернуты в ".async()". Свои же функции можно вызывать напрямую: gist.github.com/1159101 (getUserSummary_nodejs_sync.js)
> Как он, кстати, будет пробрасывать исключения?
Так же, как и Fiber — нативно.
> Вопрос: можете ли вы отказаться от nginx в этой ситуации?
Не могу. На нем много другой логики, которую очень не хочется доверять nodejs.
> Я бы ради кометов и вебсокетов не особо волнуясь поставил бы веб-сервер на erlang вместо nginx.
Я вообще скоро комет перепишу на Erlang :)
> Просто порт 4000 — всё таки штука стремная, отвалится у многих пользователей.
Пока не сталкивался, вроде у всех работает. А в чем может быть проблема?
> Насколько можно сервер на ноде втыкать вперед?
Не стоит. Nginx сейчас — как «guard», в котором я всегда уверен, который никогда не отвалится. Тем более, upstream позволяет в случае таймаута перебросить запрос на другой сервер. Он, как бы, сглаживает нестабильность nodejs.
Нотацию «someObject.someMethod.sync(someObject, arg1, arg2)» необходимо использовать только для вызова сторонних функций, которые не обернуты в ".async()". Свои же функции можно вызывать напрямую: gist.github.com/1159101 (getUserSummary_nodejs_sync.js)
> Как он, кстати, будет пробрасывать исключения?
Так же, как и Fiber — нативно.
> Вопрос: можете ли вы отказаться от nginx в этой ситуации?
Не могу. На нем много другой логики, которую очень не хочется доверять nodejs.
> Я бы ради кометов и вебсокетов не особо волнуясь поставил бы веб-сервер на erlang вместо nginx.
Я вообще скоро комет перепишу на Erlang :)
> Просто порт 4000 — всё таки штука стремная, отвалится у многих пользователей.
Пока не сталкивался, вроде у всех работает. А в чем может быть проблема?
> Насколько можно сервер на ноде втыкать вперед?
Не стоит. Nginx сейчас — как «guard», в котором я всегда уверен, который никогда не отвалится. Тем более, upstream позволяет в случае таймаута перебросить запрос на другой сервер. Он, как бы, сглаживает нестабильность nodejs.
Проблема с 4000 в том, что у админов параноиков все порты закрыты, а 80-й ходит через squid.
Там даже PUT запрещен.
Насчёт nginx понял. Выставить erlang на гигабитный интерфейс — не страшно. Дальше, пока не знаю.
Там даже PUT запрещен.
Насчёт nginx понял. Выставить erlang на гигабитный интерфейс — не страшно. Дальше, пока не знаю.
сталкивались. решаеться переводом комета на 443 порт — он обычно даже не проверяеться на траффик и по нему можно плаин-сокетами ходить или вебсокетами
Хорошая мысль, надо посмотреть. Хотя, не исключаю больной на голову политики отсекать не SSL трафик по 443
там фишка в том, что сначала идет стандартный HTTP-заголовок Connection:upgrade и все такое, поэтому даже если есть промежуточные проверки, то они проходятся. А дальше уже соединение открыто и обычно ssl внутри не проверяеться. Будет сложно только с сильно умными, которые проверяют траффик и все пакеты, тогда да — не пройдет. Пока с такими не встречались
Точно. Сделаю завтра comet.tactoom.com:80
Спасибо за статью.
Несколько вопросов:
Насколько node-cluster надёжен? Как вы его контролируете?
Пользовались ли чем-то другим кроме него (forever)?
Несколько вопросов:
Насколько node-cluster надёжен? Как вы его контролируете?
Пользовались ли чем-то другим кроме него (forever)?
> Насколько node-cluster надёжен?
В плане работы — надежен. Но у него глючный интерфейс cli() start/restart/shutdown. Иногда, при удаленном запуске (через capistrano) не убивает старые процессы, либо вообще ничего не делает. Если зайти на сервер напрямую, то все работает нормально. Все никак не могу с этим разобраться.
У node-cluster нет нативной демонизации, по сему пришлось писать обертку, которая форкает сама себя с setsid=true.
При работае со «stand-alone» (для Cloud процессов, которые не слушают http), пришлось допиливать graceful shutdown/restart.
Еще панисал плагин для node-cluster для слежения за памятью воркеров (если нужно, могу выложить).
> Пользовались ли чем-то другим кроме него (forever)?
Да, forever использую для демонизации Beseda (COMET), поскольку у него всего один процесс.
В плане работы — надежен. Но у него глючный интерфейс cli() start/restart/shutdown. Иногда, при удаленном запуске (через capistrano) не убивает старые процессы, либо вообще ничего не делает. Если зайти на сервер напрямую, то все работает нормально. Все никак не могу с этим разобраться.
У node-cluster нет нативной демонизации, по сему пришлось писать обертку, которая форкает сама себя с setsid=true.
При работае со «stand-alone» (для Cloud процессов, которые не слушают http), пришлось допиливать graceful shutdown/restart.
Еще панисал плагин для node-cluster для слежения за памятью воркеров (если нужно, могу выложить).
> Пользовались ли чем-то другим кроме него (forever)?
Да, forever использую для демонизации Beseda (COMET), поскольку у него всего один процесс.
Откройте секрет вот такого подхода:
<div class="json-data" style="display: none" data-data="%JSON_STRING%"></div>
Простите, а какая нагрузка на ваш проект в целом? (сколько примерно пользователей, сколько уников в день)
Тот же вопрос по-другому: нужна ли вся эта чехарда с масштабированием и т.п., явно нацеленная на огромную аудиторию проекта, непосредственно вам?
Тот же вопрос по-другому: нужна ли вся эта чехарда с масштабированием и т.п., явно нацеленная на огромную аудиторию проекта, непосредственно вам?
> Простите, а какая нагрузка на ваш проект в целом? (сколько примерно пользователей, сколько уников в день)
~2к хостов в день
~300-500 человек онлайн
> Тот же вопрос по-другому: нужна ли вся эта чехарда с масштабированием и т.п.
А вы попробуйте без «чехарды» поднять такой проект и держать хотя бы 100 онлайн :)
~2к хостов в день
~300-500 человек онлайн
> Тот же вопрос по-другому: нужна ли вся эта чехарда с масштабированием и т.п.
А вы попробуйте без «чехарды» поднять такой проект и держать хотя бы 100 онлайн :)
2000 хостов в день это мало. Справиться один сервер, по крайней мере для обычного сайта.
А как вы считаете количество человек онлайн?
Нашёл тут у вас одну неэффективность — на странице tactoom.com/interest/Tactoom-Feedback при наведении на подпись (Tactoom-Feedback, например) делается POST Ajax запрос для каждой ссылки заново.
А как вы считаете количество человек онлайн?
Нашёл тут у вас одну неэффективность — на странице tactoom.com/interest/Tactoom-Feedback при наведении на подпись (Tactoom-Feedback, например) делается POST Ajax запрос для каждой ссылки заново.
А в чем проблема?
Стандартные форумы на относительно стандартных виртуальных хостингах такую нагрузку держат легко. nginx, разумеется, поднят.
Стандартные форумы на относительно стандартных виртуальных хостингах такую нагрузку держат легко. nginx, разумеется, поднят.
Стандартные форумы на стандартных виртуальных хостингах (не впс, а именно хостинг) сто человек онлайн?
Ну-ну.
Не, если там только текст, если нгинкс поднят с proxy_cache/fastcgi_cache, то еще может быть и поверю, но даже если на сервере просто странички с большим количеством графики и комментариев, не удержит хостинг за ~100 рублей 100 человек онлайн, точно говорю.
Ну-ну.
Не, если там только текст, если нгинкс поднят с proxy_cache/fastcgi_cache, то еще может быть и поверю, но даже если на сервере просто странички с большим количеством графики и комментариев, не удержит хостинг за ~100 рублей 100 человек онлайн, точно говорю.
Ну один выделенный сервер точно удержит 100 человек онлайн и больше. Что вы там делаете с этими людьми онлайн, что требуется такая развесистая архитектура?
Дык то выделенный сервер, в том-то и дело. Даже слабенький сервер при наличии рук, растущих из правильного места, удержит. И более того, может творить те еще чудеса.
А виртуальный хостинг — увы, нет, не удержит.
А виртуальный хостинг — увы, нет, не удержит.
Так тут-то не виртуальный хостинг, тут дофига серверов, а нагрузки всего ничего.
Я отвечал на коммент, что стандартный форум на стандартном виртуальном хостинге легко удержит нагрузку порядка ~100 человек онлайн.
Я не автор и к разработке tactoom никакого отношения не имею.
А что в tactoom такого сложного делается, не знаю.
Подозреваю, что они постоянно на любое действие пользователя через ajax (а то и через websocket) дергают слой бизнес-логики, а то и базу данных, отсюда и нагрузка такая, более высокая, чем от стандартного plain web 1.0 форума.
Только что глянул: да, там от каждого залогиненного пользователя раз в ~10 секунд отходит ajax-запрос — видимо, используется технология long polling для организации чата.
Ну и практически нет переходов по страничкам, практически все действия осуществляются через ajax — все взаимодействие с людьми, новые посты и т.п.
Я не автор и к разработке tactoom никакого отношения не имею.
А что в tactoom такого сложного делается, не знаю.
Подозреваю, что они постоянно на любое действие пользователя через ajax (а то и через websocket) дергают слой бизнес-логики, а то и базу данных, отсюда и нагрузка такая, более высокая, чем от стандартного plain web 1.0 форума.
Только что глянул: да, там от каждого залогиненного пользователя раз в ~10 секунд отходит ajax-запрос — видимо, используется технология long polling для организации чата.
Ну и практически нет переходов по страничкам, практически все действия осуществляются через ajax — все взаимодействие с людьми, новые посты и т.п.
И кстати, более интересно сколько запросов выполняется за день
IP.Board
5-6k хостов, 70-75k хитов в сутки
в пиках около 300-350 человек онлайн (сейчас прямо 200)
nginx на отдачу статики, за ним apache с mod_php5 (практически не тюненый, много лишнего висит)
Что мы неправильно делаем? :)
Хостинг, правда, за 510 рублей и с несколько задранными параметрами (для новых аккаунтов их урезали). Памяти 500 метров — сейчас упираемся в предел и ищем варианты оптимизации.
5-6k хостов, 70-75k хитов в сутки
в пиках около 300-350 человек онлайн (сейчас прямо 200)
nginx на отдачу статики, за ним apache с mod_php5 (практически не тюненый, много лишнего висит)
Что мы неправильно делаем? :)
Хостинг, правда, за 510 рублей и с несколько задранными параметрами (для новых аккаунтов их урезали). Памяти 500 метров — сейчас упираемся в предел и ищем варианты оптимизации.
Видимо вы фанат nodejs :) 2К хостов в день это как раз на тему преждевременной оптимазации, что говорят зло (многие умные и известные дядьки в их книгах по программированию).
Жду инвайтов на сайт, зарегался не дали мне ничо, элита блин с 2К хостами… :)
Жду инвайтов на сайт, зарегался не дали мне ничо, элита блин с 2К хостами… :)
У нас один серв на достаточно обычном Core2Duo с четырмя Гб ОЗУ и обычных сказёвых дисках выдерживает при еджениксе-«тупом и медленном пыхе» (самописный движок) сносно держит до 700 активных пользователей и роботов (специально отключали кеш и проверяли). Это социальная сеть с общением, блогами, файлохранилищем и магазином.
Ваше заявление настораживает. Вы проведите нагрузочное тестирование на всякий случай. Может овчинка выделки не стоит в общем процессе.
Ваше заявление настораживает. Вы проведите нагрузочное тестирование на всякий случай. Может овчинка выделки не стоит в общем процессе.
Выглядит так что было интереснее написать сверхэффективный проект на node.js способный невиданно масштабироваться, до того как понять будет ли это востебованно.
Вы не путайте максимальную нагрузочную ёмкость и скорость генерации страницы.
Человек описывал, как он хотел сделать быстро работающий сайт.
Человек описывал, как он хотел сделать быстро работающий сайт.
Как я понял ее просто как хотел, а как сделал. И я понял как раз как наоборот, сделано так чтобы можно было легко и масштабировать, когда web/cloud процессы могут работать на любых машинах. Наверника техническая задача решена отлично, хочется пожелаем проекту испытать ту нагрузку, на которую заложена архитектура.
Инвайт можно получить также от других участников тут
С @visionmedia в плане пуллов действительно всё очень грустно. С другой стороны они в числе тех, кто добился чего-то на Ноде и может немного позволить расслабится. С удовольствием прочитаю вторую часть :)
P.S. А не много ли 300мс в среднем при такой масштабной подготовке?
P.S. А не много ли 300мс в среднем при такой масштабной подготовке?
> кто добился чего-то на Ноде и может немного позволить расслабится
Они гипер-вальяжные.
> P.S. А не много ли 300мс в среднем при такой масштабной подготовке?
Есть минимум, ниже которого отклик не может быть быстрее физически, как не масштабируй. 300ms — это золотая середина. И это не много.
Поиск, например, 10-50ms.
Они гипер-вальяжные.
> P.S. А не много ли 300мс в среднем при такой масштабной подготовке?
Есть минимум, ниже которого отклик не может быть быстрее физически, как не масштабируй. 300ms — это золотая середина. И это не много.
Поиск, например, 10-50ms.
Вы написали, что использовали redis в качестве очереди. Скажите, рассматривали ли вы другие альтернативы (например, rabbitmq) и почему именно redis.
Я работал с MemcacheQ, Amazon SQS, Active MQ… Все они неплохие. Но зачем добавлять еще одну технологию в стэк, если Redis справляется с этой задачей просто идеально?
редис очень-очень быстрый и не только очереди, тогда как все остальное — большое и дает только очереди (при этом с сложным протоколом и большим оверхедом — это я про AMQP)
Участвовало только 2 человека в разработке? Сколько времени потребовалось на нее?
Как бекапы устроены?
Это там, где «секрет»
Mongodb journaling, Mongodelay 4h, redis slave + snapshots.
Mongodb journaling, Mongodelay 4h, redis slave + snapshots.
Почему Rackspace Cloud Storage, а не Amazon S3?
Ощущения от прочтения схожи с ощущениями от экскурсии с рассказом о том, как строили пирамиды. Дикое количество кода, огромное количество проблем… И ещё один G+ в результате.
Ну и от описания просто дико, люто, бешено веет ровно тем же самым снобизмом, которым веет от поста и комментариев автора. В принципе, это можно считать комплиментом — настолько, насколько снобизм можно считать стилем.
Ну и от описания просто дико, люто, бешено веет ровно тем же самым снобизмом, которым веет от поста и комментариев автора. В принципе, это можно считать комплиментом — настолько, насколько снобизм можно считать стилем.
Хорошо написано, спасибо. Наглядная иллюстрация к принципу о танцоре и тапочках. И проект интересный, жду инвайта.
А чем профилируете? Вы там писали, что профилировали сборку объектов из базы.
Собственно, а почему вы выбрали «сырую и спорную технологию» для реализации?
Спасибо за статью, с нетерпением буду ждать второй части, очень не хватает таких обзоров реальных рабочих проектов.
Кстати, сходу вопрос, а вот не пожалели что связались с нодой? Стоило ли потраченное время полученной отдачи?
Там выше в комментариях говорили что 300-500 онлайн это мало, но я так понимаю все делалось не для 300-500, а с зазором на рост в десятки и сотни раз. Если все правильно понимаю держать это все будет в разы дольше. Кстати не проводили нагрузочное тестирование, каков потолок при нынешних ресурсах и насколько легко все это будет масштабироваться (горизонтально как я понимаю).
Кстати, а чего связались со статикой на ноде против того же nginx, это хоть как-то оправдано?
P.S. < 0ms это сколько? o_O
Кстати, сходу вопрос, а вот не пожалели что связались с нодой? Стоило ли потраченное время полученной отдачи?
Там выше в комментариях говорили что 300-500 онлайн это мало, но я так понимаю все делалось не для 300-500, а с зазором на рост в десятки и сотни раз. Если все правильно понимаю держать это все будет в разы дольше. Кстати не проводили нагрузочное тестирование, каков потолок при нынешних ресурсах и насколько легко все это будет масштабироваться (горизонтально как я понимаю).
Кстати, а чего связались со статикой на ноде против того же nginx, это хоть как-то оправдано?
P.S. < 0ms это сколько? o_O
[-Inf; 0)
> Кстати, сходу вопрос, а вот не пожалели что связались с нодой? Стоило ли потраченное время полученной отдачи?
Не жалею. Но и не скажу, что особо рад.
> Кстати, а чего связались со статикой на ноде против того же nginx, это хоть как-то оправдано?
Статику отдает nginx. На node написаны скрипты, которые ее собирают.
> < 0ms это сколько
0.9 ms
Не жалею. Но и не скажу, что особо рад.
> Кстати, а чего связались со статикой на ноде против того же nginx, это хоть как-то оправдано?
Статику отдает nginx. На node написаны скрипты, которые ее собирают.
> < 0ms это сколько
0.9 ms
Какая версия Mongoose текла и коматозила? В комментах вы упоминали, что все было написано за 8 месяцев. Вторая версия mongoose была выпущена меньше 2х месяцев назад, вроде переделали ее хорошо. Я сам отказался от первой — она не так сильно тормозила, как была сырая. Если у вас не взлетела вторая, значит, не стоит переходить на нее?
Я сейчас занимаюсь разработкой проекта на ноде + html5. В качестве kvs и связи между серверами разделенной логики redis, в качестве основной БД — mongo и как ORM — mongoose. Было интересно почитать.
Есть и вопрос. Судя по вашим словам mongoose показал себя не с очень хорошей стороны. А вы не пробовали определить какие именно места являются самыми проблемными? Все же не хотелось бы от него отказываться, но сделать реальные замеры производительности сейчас не является возможным.
Есть и вопрос. Судя по вашим словам mongoose показал себя не с очень хорошей стороны. А вы не пробовали определить какие именно места являются самыми проблемными? Все же не хотелось бы от него отказываться, но сделать реальные замеры производительности сейчас не является возможным.
Поклацайте вот этот доклад spf13.com/post/mongodb-e-commerce-and-transactions
Там все сказано по поводу целостности и атомарных операций в mongo.
Денормализации много, на каждое денормализованное значение есть функция пересчета/починки.
Там все сказано по поводу целостности и атомарных операций в mongo.
Денормализации много, на каждое денормализованное значение есть функция пересчета/починки.
все очень интересно
спасибо
спасибо
Добрый день. Прошло 3 года с момента написания этой статьи (вроде как самой свежей Вашей статьи). Статья написана очень подробно и интересно. Но всё-таки прошло некоторое время, достаточно большое для современных технологий. Хотелось бы узнать Вашу точку зрения, насколько такая модель оказалась эффективной? Или Вы что-то более интересное нашли? Было рад услышать от Вас комментарии, а также мысли на тему «плюсы, минусы, подводные камни».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL