Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 20
В свете динамических развивающихся framework’ов (react, angular, node, sping и др.), не всегда стоит их применять для разработки продуктов
А где логика? В вашем примере все уперлось в постоянно открытый сокет, а не фреймворк или язык. И так на минуточку «JS фреймоврк» — это тоже «javascript». Видимо ваша стизя тестирования, в программирование лезть не стоит :)
Для большей полезности могли бы описать какие инструменты использовали, мне как не искушенному в тестировании человеку очень интересно :)
А где логика?
Логика только в том, что бы прежде чем использовать новый framework, лучше его сначала изучить и понять как он работает. Подумать подходит ли он под ваши требования, что бы потом в спешке не пришлось его менять.
Да, я тестировщик, что тестирование показало, то я и описал здесь :)
Для большей полезности могли бы описать какие инструменты использовали, мне как не искушенному в тестировании человеку очень интересно :)
К сожалению это была коммерческая утилита, которая больше не продается. Не думаю что имеет смысл ее указывать.
Логика только в том, что бы прежде чем использовать новый framework, лучше его сначала изучить и понять как он работает. Подумать подходит ли он под ваши требования, что бы потом в спешке не пришлось его менять.
Это да, соглашусь, вот только из вашего вывода вообще это не следует. Следует что нужно выкинуть все фреймворки, а использовать pure js и будет счастье. Хотя дело далеко не в этом. И в тех же самых фреймворка есть как минимум готовые инструменты для кеширования (это если говорить про бэк).
В вашем примере глубоко пофиг какой используется frontend фреймворк, у вас проблема с нагрузкой бэка, а не отрисовкой фронта. Так что все таки вывод неверный на счет javascript.
А разве современные фреймворки не плюс минус одинаковые все?
Ну т.е. реальна ли ситуация когда один не подходит из за каких то прям жёстких ограничений и переписывание на новый решает все проблемы?
Плюс там и проблемы новые придут с новым фреймворком)
А разве современные фреймворки не плюс минус одинаковые все?
React и Vue — разные подходы. Symfony/Laravel и Yii — разные подходы.
Так что нет, они плюс минус одинаковые на первый взгляд.
Ну т.е. реальна ли ситуация когда один не подходит из за каких то прям жёстких ограничений и переписывание на новый решает все проблемы?
Нет, конечно, решит все проблемы правильная архитектура и правильное использование технологий. Только где об этом речь?
Изучить конечно правильно, тут с вами полностью согласен, что людям часто не хватает опыта и знаний. Меня вот лично очень смущает, что тестировщик, без должного опыта разработки highload, лезет в работу программистов, системных архитекторов и главное советует им что делать. Фреймворки никогда не решали всех проблем, и самое главное, они не разрабатывают архитектуру приложения, это делают только программисты. Винить в своих проблемах фреймворки, языки программирования, технологии, ничего не зная про полную архитектуру приложения и не описывая архитектуру приложения, это сверх безграмотности. Безграмотная архитектура и плохой код легко могут похоронить все их преимущества. Конечно согласен, что рендеринг на стороне клиента может решить часть проблем, и уменьшить количество запросов и количество передаваемых данных, но чаще всего тормоза с серверов переходят в тормоза браузера клиента. И такое наблюдается мной на большой количестве крупных сайтов, на некоторых даже флагманские смартфоны знатно подвисают, а все потому что архитектура не правильная, плохое качество кода, тянут непонятные фреймворки, библиотеки! Хоть предпочитаю клиентский рендеринг, чаще всего все его преимущества портят плохие программисты. Копипаст программисты это просто бич современного ИТ… Поэтому сейчас выгоднее вкладывать в студентов и нанимать их, что делают все крупные ИТ компании. Плохого программиста перевоспитать очень сложно и значительно дороже… Очередная статья из разряда плохому танцору даже яйца мешают…
В данной статье нет советов. Тут есть только моменты на которые стоит обращать внимание при разработке той или иной системы.
В статье описано, что мы предоставляли результаты, заказчики сами переписывали свое приложение так как им удобно и так как хотели они. Мы не давали советов. Я лишь озвучил то, что сначала был WS, а в результате стал JS.
Я считаю, что тестировщик не должен лезть в работу разработчика, он показывает только результаты тестирования.
Я никого не призываю отказываться от framework'ов. Я выражаю свое мнение, что порой новое это не всегда то, что вам нужно. Что и показал здесь реальный пример из практики и не более того.
В статье описано, что мы предоставляли результаты, заказчики сами переписывали свое приложение так как им удобно и так как хотели они. Мы не давали советов. Я лишь озвучил то, что сначала был WS, а в результате стал JS.
Я считаю, что тестировщик не должен лезть в работу разработчика, он показывает только результаты тестирования.
Я никого не призываю отказываться от framework'ов. Я выражаю свое мнение, что порой новое это не всегда то, что вам нужно. Что и показал здесь реальный пример из практики и не более того.
Я лишь озвучил то, что сначала был WS, а в результате стал JS.
Сначала был JS и использование WS, а потом остался только JS, т.е. отказались от WS. Таким образом весь вывод можно оформить так: «Проблемы с нагрузкой были из-за использования сокетов». Зачем тут нужно приплетать JS и фреймворки, которые в данной ситуации вообще ни на что не влиют?
Я никого не призываю отказываться от framework'ов. Я выражаю свое мнение, что порой новое это не всегда то, что вам нужно. Что и показал здесь реальный пример из практики и не более того.
Опять все в кашу. При чем тут фреймворки и что-то новое?
> Иногда наши ожидания возможностей системы не всегда совпадают с реальностью. И в этом случае следует очень глубоко анализировать получаемые данные. Возможно стоит пересмотреть критерии оценки работоспособности системы, использовать другие метрики для ее измерения.
Т.е. не надо делать адекватные требования изначально, надо гибко их менять в зависимости от получаемых результатов?
> В свете динамических развивающихся framework’ов (react, angular, node, sping и др.), не всегда стоит их применять для разработки продуктов. Порой javascript будет работать намного эффективнее, чем что-то еще. Необходимо инструменты реализации подбирать под задачу, и думать как ваша система будет работать.
При чем тут вообще фреймворки? Проблема была не в них, а в том, какие МЕТОДЫ взаимодействия клиент-сервер были выбраны. В том числе странно, что не применяли CDN при таких требованиях. Почему бы не сделать максимально разгруженное взаимодействие с бекендом и фронтовое приложение в CDN?
PS: Node.js это не фреймворк.
Т.е. не надо делать адекватные требования изначально, надо гибко их менять в зависимости от получаемых результатов?
> В свете динамических развивающихся framework’ов (react, angular, node, sping и др.), не всегда стоит их применять для разработки продуктов. Порой javascript будет работать намного эффективнее, чем что-то еще. Необходимо инструменты реализации подбирать под задачу, и думать как ваша система будет работать.
При чем тут вообще фреймворки? Проблема была не в них, а в том, какие МЕТОДЫ взаимодействия клиент-сервер были выбраны. В том числе странно, что не применяли CDN при таких требованиях. Почему бы не сделать максимально разгруженное взаимодействие с бекендом и фронтовое приложение в CDN?
PS: Node.js это не фреймворк.
Простите, а что же такое Node.js если не фреймворк?
На хабр с каждым днем все безграмотнее статьи становятся. Статья никак не относится к теме высокой производительности. В статье нет речи про полную архитектуру приложения и схему кешированию. Без этого даже нет смысла заводить речь про highload. Только непонятные выводы и придумки автора. Нет слова про кеширование обьектов в памяти приложения, про то какая схема БД используется, про качество кода тоже нет речи(как показывает опыт, несколько строк плохого и безграмотного кода легко могут похоронить всю производительность)…
Добавлю что еще не хватает:
0. Нет указания в каком году все это происходит, и неясно что существует из решений.
1. Что именно использовали для websocket сервера? Как его масштабировали?
2. Что с БД? Как её масштабировали?
3. Что значит «Новые сервера опять же не успевали загружаться.»? Админ вручную сервера включал и они не успевали загружаться? Или был оркестратор?
4. Кто за балансировку трафика отвечал? Железяка? Nginx?
websocket сервер, так же как и БД тоже надо было мониторить во время выполнения тестов, ну и банальные параметры cpu/memory usage для сервера/ов.
0. Нет указания в каком году все это происходит, и неясно что существует из решений.
1. Что именно использовали для websocket сервера? Как его масштабировали?
2. Что с БД? Как её масштабировали?
3. Что значит «Новые сервера опять же не успевали загружаться.»? Админ вручную сервера включал и они не успевали загружаться? Или был оркестратор?
4. Кто за балансировку трафика отвечал? Железяка? Nginx?
websocket сервер, так же как и БД тоже надо было мониторить во время выполнения тестов, ну и банальные параметры cpu/memory usage для сервера/ов.
В статье существует явный разрыв между телом поста и выводами. Полезной информации можно выудить с гулькин нос. И темы для отображения статьи явно не корректны.
Подойдет: Песочница, халивар (ожидания-реальность) и т.д.
Подойдет: Песочница, халивар (ожидания-реальность) и т.д.
" отказались от технологии WebSocket"
здесь я закрыл статью
оценка 1\10
здесь я закрыл статью
оценка 1\10
отказались от технологии WebSocketпотому, что websocket не для этого. не для загрузки картинок и всего прочего при первоначальной загрузки страницы.
Ощущение что статья написана некомпетентным в разработке «руководителем», который спросил подчинённых в чём была проблема и не поняв 50% ответа(ов) — выдал эту кашу в статью.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы тестировали web систему с требованием в 42 000 пользователей