Спасибо за наводку! Действительно неплохое решение, но применимое скорее для больших проектов.
У меня была задача сделать что-то для небольших (обычно уже существующих со своей структурой) проектов + этим должны пользоваться джуниоры/мидлы и ничего не сломать :) А то за последнее время народилось кучи разносортных gulp/grunt файлов, в каждом проекте свой формат и свои костыли %)
Сложнее и не решает все задачи:
1. Код плохо читаем — будут баги при переносе и редактировании
2. В качестве аргументов не запихаешь весь накопленный опыт. Например, мы используем plumber для глушения ошибок, чтоб процесс не завершался. Очень бесит когда в фоне watch процесс умер, а ты несколько секунд рефрешишь браузер и не понимаешь почему не работает.
3. Если нужно добавить что-то более сложное, то в cmd это уже не запихаешь, т.к. большинство плагинов ее не поддерживает
Ну вы конечно молодцы, сократили задержку — похвастались. А нам то что с вашей статьи? Технических подробностей и секретов вы не хотите рассказывать, кроме того, что используется wowza. Это не совсем формат хабра.
Это пздц, товарищи… Чтож за день то такой…
Если по делу:
Автор, ваш говнокод никому в не интересен, тем более в таком виде. То, что у вас «работает» — не означает что этим можно делиться.
Попробуйте оформить это как отдельный плагин к jQuery, хотя бы, избавьтесь от echo, привязке к элементам по айдишникам и т.д… а пока что уберите этот стыд в черновики.
Gii в планах, но не в ближайших, хотя вполне может кто-нибудь заняться его реализацией. Сами формы в еще более далеких планах. Jii ориентирован на более сложные приложения, где много логики на клиенте, а значит отрисовка вьюшек будет происходить какими-либо фреймворками/библиотеками (backbone/sencha/dojo/...) и Jii будет предоставлять каркас приложения, модели и контроллеры. И сделает все возможное, чтобы другие библиотеки могли параллельно с ней работать. Такое мое видение на данный момент, его можно менять :)
Загуглить, конечно, не долго было, но пару предложений о том, что такое «Рутокен» — можно было вставить.
В репозитории у вас и исходники, и nw.js (nw.exe + всякие dll) и билд для windows… А еще примеры сишной библиотеки в app прям лежат, в билде пути C:\… и т.д… Чистить, чистить и еще раз чистить репозиторий и проект.
Лучше nw.js вообще выкинуть из репозитория, а билды хранить в отдельной папке.
И, я так понимаю, это все только для windows актуально? Об этом статье/репозитории стоит указать
Спасибо за подробный ответ! У нас тоже есть немного схожего с вашей архитектурой: тоже есть мастер процесс, который следит за остальными и не работает с запросами и бизнес логикой, процессы перезагружаются раз в сутки в разнобой (не все разом), нормально завершая свою работу (обрабатывая последние запросы и не принимая следующие), а состояние все в редисе хранится.
Но я очень рад слышать, что все-таки можно иметь приложение без утечек, нам уже казалось это из ряда фантастики для node.js.
У нас в глубине приложения используются express и sockjs. Есть какой-то опыт с ними по поводу утечек?
А у вас нода без перезапусков работает? Утечек вообще никаких нет?
Мы стараемся данные держать где-нить в Redis'е. При обильном использовании памяти нода быстро уходила в цпу 100%, правда это еще было при версии ноды ~0.5…
А что значит «критический объем утечки»? Почему после какого-то предела по памяти нода залипает по цпу?
У нас на серверах памяти много, по ней не упираемся в какие-то лимиты, но если нода начинает много памяти кушать, то она начинает залипать по цпу… и это проблема.
У нас ~500 запросов в секунду в пиках, каждый из воркеров потребляет ~200 мб памяти
Большое спасибо на находку и ее исследования!
А при данном баге память постоянно течет? Т.е. даже после каких-то долгих таймаутов (2 минуты, например) не очищается?
У нас есть high-load приложение на ноде, 3-4 тысячи пользователей онлайн на каждом из серверов, запросов очень много. Память течет, исследовать настолько глубоко нет времени/средств, пришлось делать под 20 воркеров на каждом сервере (которые расходуют по 10-20% цпу) и перезагружать раз в сутки эти воркеры, чтобы очистить память. Если делаем мало воркеров (10, например), то в пиках нагрузки они начинают грузить проц под 100%, не могут обработать запрос и цпу не снижается даже сли нагрузку вообще убрать.
Как думаете, ваш багфикс сможет нам помочь?
Да, меня тоже немного это опечалило. Переход скорее всего связан с большими возможностями sass + скорость компиляции выше.
Значит нужно просто менять свои принципы и переходить на sass :)
А по сколько строк в каждом из небазовых (типа Web.php) конфигов? Мы обычно сводим такие настройки в один файл production.php, т.е. на каждый env — свой дополнительный файл, который мержится с base и web/cli.
А вообще в данном аспекте «пули» быть не может, конфигурация сильно зависит от масштабов проекта. Но в одном всегда одинакого — должен быть файл config.php, который лежит в корне и которого нет в гите (на каждой машине — свой). И там идут переопределения настроек индивидуально для машины + пароли для БД/токены/… от продакшена, т.к. хранить пароли в гите — зло :)
Недавно для своего фреймворка делал основу для конфигурация, вот такие примеры получились — github.com/jiisoft/jii-workers/tree/master/examples
нет, там одновременно записывается звук и с телефона и с компа, а затем сравнивается. Но в реале это вряд ли будет работать, тупить будет так же как авторизация по отпечатку пальцев сейчас в телефонах (через раз работает, на айфоне)
Если тормозит так же как и стандартный браузер телефона, то значит кордова ни при чем, ибо кордова это в минимальном виде приложение с единственным контролом — WebView.
Ни в статье, ни на сайте не нашел информации о том, какие нагрузки может выдержать комет сервер и вообще почему я должен купить ваш сервис и пользоваться им, а не написать свой простой комет-сервер, примеров которых есть 100500+ в интернете?
У меня была задача сделать что-то для небольших (обычно уже существующих со своей структурой) проектов + этим должны пользоваться джуниоры/мидлы и ничего не сломать :) А то за последнее время народилось кучи разносортных gulp/grunt файлов, в каждом проекте свой формат и свои костыли %)
1. Код плохо читаем — будут баги при переносе и редактировании
2. В качестве аргументов не запихаешь весь накопленный опыт. Например, мы используем plumber для глушения ошибок, чтоб процесс не завершался. Очень бесит когда в фоне watch процесс умер, а ты несколько секунд рефрешишь браузер и не понимаешь почему не работает.
3. Если нужно добавить что-то более сложное, то в cmd это уже не запихаешь, т.к. большинство плагинов ее не поддерживает
Если по делу:
Автор, ваш говнокод никому в не интересен, тем более в таком виде. То, что у вас «работает» — не означает что этим можно делиться.
Попробуйте оформить это как отдельный плагин к jQuery, хотя бы, избавьтесь от echo, привязке к элементам по айдишникам и т.д… а пока что уберите этот стыд в черновики.
В репозитории у вас и исходники, и nw.js (nw.exe + всякие dll) и билд для windows… А еще примеры сишной библиотеки в app прям лежат, в билде пути C:\… и т.д… Чистить, чистить и еще раз чистить репозиторий и проект.
Лучше nw.js вообще выкинуть из репозитория, а билды хранить в отдельной папке.
И, я так понимаю, это все только для windows актуально? Об этом статье/репозитории стоит указать
Но я очень рад слышать, что все-таки можно иметь приложение без утечек, нам уже казалось это из ряда фантастики для node.js.
У нас в глубине приложения используются express и sockjs. Есть какой-то опыт с ними по поводу утечек?
Мы стараемся данные держать где-нить в Redis'е. При обильном использовании памяти нода быстро уходила в цпу 100%, правда это еще было при версии ноды ~0.5…
У нас на серверах памяти много, по ней не упираемся в какие-то лимиты, но если нода начинает много памяти кушать, то она начинает залипать по цпу… и это проблема.
У нас ~500 запросов в секунду в пиках, каждый из воркеров потребляет ~200 мб памяти
А при данном баге память постоянно течет? Т.е. даже после каких-то долгих таймаутов (2 минуты, например) не очищается?
У нас есть high-load приложение на ноде, 3-4 тысячи пользователей онлайн на каждом из серверов, запросов очень много. Память течет, исследовать настолько глубоко нет времени/средств, пришлось делать под 20 воркеров на каждом сервере (которые расходуют по 10-20% цпу) и перезагружать раз в сутки эти воркеры, чтобы очистить память. Если делаем мало воркеров (10, например), то в пиках нагрузки они начинают грузить проц под 100%, не могут обработать запрос и цпу не снижается даже сли нагрузку вообще убрать.
Как думаете, ваш багфикс сможет нам помочь?
Значит нужно просто менять свои принципы и переходить на sass :)
А вообще в данном аспекте «пули» быть не может, конфигурация сильно зависит от масштабов проекта. Но в одном всегда одинакого — должен быть файл config.php, который лежит в корне и которого нет в гите (на каждой машине — свой). И там идут переопределения настроек индивидуально для машины + пароли для БД/токены/… от продакшена, т.к. хранить пароли в гите — зло :)
Недавно для своего фреймворка делал основу для конфигурация, вот такие примеры получились — github.com/jiisoft/jii-workers/tree/master/examples
И разве хабр не запрещает копировать статьи? Я про comet-server.ru/wiki/doku.php/comet:cometql