Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 45
Интересно, они используют rails для рендеринга?
Скорее всего нет. В последнее время они плотно занимаются разработкой на Scala.
субъективное «подтормаживание» страниц
Нифига себе субъективное! Там разворот Conversation'а тормозит вообще безбожно, а если их около 4х развернуть — то вообще, пиши пропало.
ааа. новые технологии, уникальные возможности, прирост скорости в разы — просто генерируйте страницу на сервере
Похоже всё таки ещё рановато для разработки REST Full приложений.
хорошо что есть смелость признавать свои ошибки
наконец-то!
Ну не знаю, у меня на клиенте щаблоны генерятся шустро.
Мне кажется тут либо плохой шаблонизатор либо просто страница была сильно перегружена скриптом.
Мне кажется тут либо плохой шаблонизатор либо просто страница была сильно перегружена скриптом.
«xxx: я всё больше подозреваю, что четырех-ядерный процессор мне понадобится не из-за игр, а для комфортного чтения твиттера» (с) bash.im.
На этой неделе новую архитектуру выкатили для статичных ссылок (пермалинков). Как показали тесты, скорость загрузки страницы в браузер пользователя выросла в среднем в пять раз...
Ха-ха-ха, насмешили. Ну конечно же скорость выросла в пять раз, ведь раньше при открытии ссылки на отдельный статус (даже скопированной вручную в новый таб) было невооружённым глазом видно, что сначала грузилась вся обычная лента и только через пару секунд поверх неё уже выводился слой с отдельным статусом =)
А если перейти по ссылке на фотографию — сначала мелькала своя лента, потом пустая лента, потом пустая лента другой ширины, потом заготовка под страницу с фотографией, потом собственно фотография с описанием. Итого 2-5 секунд от загрузки страницы до появления фотографии, вне зависимости от скорости интернета.
Вебдваноль такой вебдваноль, да.
Вебдваноль такой вебдваноль, да.
Самый тормозной сайт современного большого интернета потеряет своё лидерство… Странно, неужто существующее решение невозможно оптимизировать до приемлимого уровня. Идея-то неплохая для высоконагруженного сервиса.
Может там всем рулят менеджеры?
Думаю, грамотный технический специалист с большим авторитетом в компании сумел бы отстоять позицию, что всё переделывать не стоит, а надо заняться оптимизацией.
А вообще интересно было бы почитать, что думают технические специалисты twitter по этому поводу, какая неразрешимая проблема на пути встала.
Думаю, грамотный технический специалист с большим авторитетом в компании сумел бы отстоять позицию, что всё переделывать не стоит, а надо заняться оптимизацией.
А вообще интересно было бы почитать, что думают технические специалисты twitter по этому поводу, какая неразрешимая проблема на пути встала.
А я то думаю, почему каждый раз при заходе на внутренние страницы вначале рендериться главная лента, а потом то что нужно…
Генерировать HTML на стороне сервера в сотни раз дешевле аналогичного на стороне клиента. Это можно было предсказать не занимаясь фигней с переводом всего проекта на «новые» технологии.
Ничего подобного, зависит от того как делать. Я в свободное время, делаю аналог phpMyAdmin, как раз в стиле одностраничного приложения (будет загружаться только индексная страница, всё остальное только JS). Так вот страница с простым запросом выдающим 50 строк таблицы, генерится в моем случае в 20 раз быстрее, чем в phpMyAdmin.
Но конечно я не юзаю метр JS-кода, и код тщательно профилируется.
Но конечно я не юзаю метр JS-кода, и код тщательно профилируется.
Я одностраничное приложение сделал еще 5 лет назад. Первый вариант был как раз с активным использованием JS. Так как данные были весьма разнообразные, вывод их требовал довольно большого количества HTML-темплейтов или JS-обработчиков. Код усложнялся с каждой итерацией модификаций. Стоимость внесения изменений росла по экспоненте. Через время начались проблемы со скоростью отображения в IE. Замена динамических таблиц на статические дали прирост почти на порядок.
Почему генерировать HTML на стороне клиента дорого? JS умеет работать с содержимым старницы только в двух режимах — модификация при помощи DOM-методов и innerHTML. DOM-методы не то, чтобы не предназначены для темплейтирования, они и в обычном коде используются только для примитивных вещей. innerHTML требует работы со строками через regexp или множественными split'ами, replace'ами, и так далее. Было бы гораздо легче, если бы JS умел выплевывать сгенерированный текст в stdout, как это делает любой серверный язык, но, к сожалению, такая функциональность не предусмотрена в силу специфики среды исполнения.
Темплейтирование же на стороне сервера облегчено наличием готовых темлейт-систем на любой вкус и цвет. Мало того, готовый HTML или другой контент легко кешировать в статику, т.е. браузеру не нужно будет каждый раз создавать темплейт наново. Вы скажете, что можно использовать LocalStorage для хранения готовых отрендеренных кусочков, но он не безразмерный, все хранить там не получится.
Еще один момент, нагрузку при работе с вашим приложением легко посчитать на серверной стороне, и невозможно посчитать на стороне клиента. Потому что конфигурацию серверов и мониторинг нагрузки вы можете сделать легко, а вот с профилированием клиента будет все гораздо сложнее. И рассчитать допустимые нагрузки, которые выдержит клиент, можно только очень приблизительно. Мало того, шансов на масштабирование почти нет, если контент генерируется на стороне клиента.
А вот теперь подумайте, наставили минусов моему предыдущему комментарию заслуженно, или не разобравшись в проблеме?
Почему генерировать HTML на стороне клиента дорого? JS умеет работать с содержимым старницы только в двух режимах — модификация при помощи DOM-методов и innerHTML. DOM-методы не то, чтобы не предназначены для темплейтирования, они и в обычном коде используются только для примитивных вещей. innerHTML требует работы со строками через regexp или множественными split'ами, replace'ами, и так далее. Было бы гораздо легче, если бы JS умел выплевывать сгенерированный текст в stdout, как это делает любой серверный язык, но, к сожалению, такая функциональность не предусмотрена в силу специфики среды исполнения.
Темплейтирование же на стороне сервера облегчено наличием готовых темлейт-систем на любой вкус и цвет. Мало того, готовый HTML или другой контент легко кешировать в статику, т.е. браузеру не нужно будет каждый раз создавать темплейт наново. Вы скажете, что можно использовать LocalStorage для хранения готовых отрендеренных кусочков, но он не безразмерный, все хранить там не получится.
Еще один момент, нагрузку при работе с вашим приложением легко посчитать на серверной стороне, и невозможно посчитать на стороне клиента. Потому что конфигурацию серверов и мониторинг нагрузки вы можете сделать легко, а вот с профилированием клиента будет все гораздо сложнее. И рассчитать допустимые нагрузки, которые выдержит клиент, можно только очень приблизительно. Мало того, шансов на масштабирование почти нет, если контент генерируется на стороне клиента.
А вот теперь подумайте, наставили минусов моему предыдущему комментарию заслуженно, или не разобравшись в проблеме?
>Мало того, шансов на масштабирование почти нет, если контент генерируется на стороне клиента.
А что это означает?:)
А что это означает?:)
Это означает, что вы не сможете обновить пользователю его компьютер, чтобы нарастить скорость работы. И использовать более одного компьютера для рендеринга тоже не получится. В отличие от сервера, где вы вольны делать любые изменения в архитектуре и подключать любые мощности для формирования ответа.
Не судите все приложения/технологию, существует множество сайтов которые прекрасно работают (могли бы работать) с генерацией HTML на стороне клиента, где рендеринг страницы завершался бы раньше загрузки готовой страницы (особенно на узком канале клиента). Где введенные пользователем данные отображаются мгновенно, без ожидания ответа сервера с готовым HTML.
К тому же можно использовать частичную генерацию (часть на сервере, часть на клиенте).
> нагрузку при работе с вашим приложением легко посчитать на серверной стороне, и невозможно посчитать на стороне клиента.
На клиенте можно засечь время генерации страницы и отправить информацию на сервер, часто этого достаточно, и это возможно.
> Было бы гораздо легче, если бы JS умел выплевывать сгенерированный текст в stdout, как это делает любой серверный язык
Не понял к чему это и зачем.
Каждый способ генерации HTML имеет свои плюсы и минусы.
Вообщем, как говориться: «выбирать инструмент по задаче».
К тому же можно использовать частичную генерацию (часть на сервере, часть на клиенте).
> нагрузку при работе с вашим приложением легко посчитать на серверной стороне, и невозможно посчитать на стороне клиента.
На клиенте можно засечь время генерации страницы и отправить информацию на сервер, часто этого достаточно, и это возможно.
> Было бы гораздо легче, если бы JS умел выплевывать сгенерированный текст в stdout, как это делает любой серверный язык
Не понял к чему это и зачем.
Каждый способ генерации HTML имеет свои плюсы и минусы.
Вообщем, как говориться: «выбирать инструмент по задаче».
Это все теория. На практике все гораздо мрачнее, прозаичнее, меркантильнее. Основная задача любого продукта — приносить пользу. Чем быстрее ПО обновляется и начинает удовлетворять потребностям рынка, тем оно полезнее. И при выборе технологий для продукта нужно следовать балансу между красотой архитектуры и скоростью разработки.
Нагрузку на стороне клиента собирать не нужно. Берете самый медленный и самый быстрый компьютер и тестируете на самом медленном и самом быстром браузере. В итоге вы получаете разброс значений, иногда даже на порядки. И какие выводы можно будет сделать из этих данных? А никаких. Это не ответит вам ни на один из поставленных вопросов, какие возможности для масштабирования существуют, какой тип масштабирования доступен и так далее.
По поводу stdout пояснять не буду, это слишком долго, если интересно — в приват.
С последним согласен. Но добавлю, что не стоит идеализировать технологии и доводить их использование до маразма. Все должно быть экономически целесообразным в первую очередь.
Нагрузку на стороне клиента собирать не нужно. Берете самый медленный и самый быстрый компьютер и тестируете на самом медленном и самом быстром браузере. В итоге вы получаете разброс значений, иногда даже на порядки. И какие выводы можно будет сделать из этих данных? А никаких. Это не ответит вам ни на один из поставленных вопросов, какие возможности для масштабирования существуют, какой тип масштабирования доступен и так далее.
По поводу stdout пояснять не буду, это слишком долго, если интересно — в приват.
С последним согласен. Но добавлю, что не стоит идеализировать технологии и доводить их использование до маразма. Все должно быть экономически целесообразным в первую очередь.
Все-таки генеринг страниц, а не рендернг. А то заголовок создает впечатление, что браузер подгружает скриншоты страниц.
Нынешний вес сайта с сообщениями в 140 символов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Twitter возвращается к генерации страниц на сервере