Comments 25
В связи с чем, не могу не подметить настораживающую меня тенденцию: все больше вычислительно нагруженных приложений пишется на Java, Java Script, HTML5, Ruby, Python, Perl,…А что тут пугающего?
Никого это не пугает?
В связи с чем, не могу не подметить настораживающую меня тенденцию: все больше вычислительно нагруженных приложений пишется на Java, Java Script, HTML5, Ruby, Python, Perl,…Почему это должно пугать? Если приложение достигло своей цели, то какая разница на каком языке оно написано?
Никого это не пугает?
Если речь идет о функциональных целях, то — да! Разницы никакой нет. Но я сомневаюсь, что с помощью Java или Java Script можно достичь амбициозных целей по производительности.
Опять же, я говорю только о вычислительно емких приложениях.
Опять же, я говорю только о вычислительно емких приложениях.
Я писал о целях приложения а не «функциональных целях» если меня (или заказчика) производительность (тоже цель приложения) устраивает то почему нет?
Мы сейчас должны или начать говорить конкретно про какое то приложение, или скатимся в обсуждения «сферетического приложения в вакууме». Точнее уже скатились, так как Вы не рассматривали достижение необходимой производительности как цель написания приложения.
Мы сейчас должны или начать говорить конкретно про какое то приложение, или скатимся в обсуждения «сферетического приложения в вакууме». Точнее уже скатились, так как Вы не рассматривали достижение необходимой производительности как цель написания приложения.
А разве социальные сети являются вычислительно емкими приложениями?
Быть может я по-другому помнимаю вычислительную емкость. Для меня это, например, расчет каких-то физических процессов, какие-то большие математические задачи. Расчеты траекторий, сворачивание белков, криптография. Короче, везде где узким местом является CPU.
В соц. сетях узким местом являются системы хранения, базы данных. А что там считать-то?
Быть может я по-другому помнимаю вычислительную емкость. Для меня это, например, расчет каких-то физических процессов, какие-то большие математические задачи. Расчеты траекторий, сворачивание белков, криптография. Короче, везде где узким местом является CPU.
В соц. сетях узким местом являются системы хранения, базы данных. А что там считать-то?
В самом деле, что такое? всем срочно перейти на Erlang + OCaml =) заодно проблема с кешированием решиться на уровне языка.
Тема актуальная (для высоконагруженных сайтов).
Из сделанных выводов похоже, что все опять свелось к «нужно, чтобы кеш вмещался в оперативку».
Только теперь предлагают использовать кеш БД.
А «толстый клиент» — это то, во что ревращается сайт с кучей JS.
И это уже даже не тенденция, это данность.
Тенденцией это было, когда google выпускал chrome и оптимизировал JS.
Насчет языка программирования, это тоже давно свершившаяся данность.
Если посчитать расходы на разработку (ЗП, железо, поддержка) сайт на C/C++ вам обойдется очень дорого по деньгам и времени.
Крупный бизнес это давно понял, поэтому пишут корпоративные веб приложения на Java.
Сайты типа facebook составляют нишу, где уже можно было бы писать на чем-то типа C++, но для них уже дешевле переписать php, чем писать на СИ :)
Из сделанных выводов похоже, что все опять свелось к «нужно, чтобы кеш вмещался в оперативку».
Только теперь предлагают использовать кеш БД.
А «толстый клиент» — это то, во что ревращается сайт с кучей JS.
И это уже даже не тенденция, это данность.
Тенденцией это было, когда google выпускал chrome и оптимизировал JS.
Насчет языка программирования, это тоже давно свершившаяся данность.
Если посчитать расходы на разработку (ЗП, железо, поддержка) сайт на C/C++ вам обойдется очень дорого по деньгам и времени.
Крупный бизнес это давно понял, поэтому пишут корпоративные веб приложения на Java.
Сайты типа facebook составляют нишу, где уже можно было бы писать на чем-то типа C++, но для них уже дешевле переписать php, чем писать на СИ :)
Почему все думают, будто я предлагал писать сайты на C++? Когда речь шла о языке, я довольно четко обозначил, что меня настораживают кэш-менеджеры, написанные на JS. Сайты можно писать можно на чем угодно. А вот опорные фреймворки желательно делать пошустрее…
Я прочитал уже отредактированный пост и не видел текста, в котором вы, видимо, про это написали)
Поэтому, не совсем понимаю, какую сторону вы имеете в виду — клиент, или сервер.
На стороне клиента выбор, мягко говоря, невелик — только JS.
Вроде бы внедряют Dart и Python в браузеры, но пока этому далеко до мейнстрима.
А на сервере не встречал кеш менеджер на JS в широком применении.
Если только в составе nodejs.
Поэтому, не совсем понимаю, какую сторону вы имеете в виду — клиент, или сервер.
На стороне клиента выбор, мягко говоря, невелик — только JS.
Вроде бы внедряют Dart и Python в браузеры, но пока этому далеко до мейнстрима.
А на сервере не встречал кеш менеджер на JS в широком применении.
Если только в составе nodejs.
И вот не надо говорить плохого про индусских программистов!
У меня был опыт, который по всей видимости имеет много общего с этим видео: простой запрос к postgres был быстрее чем десериализация данных из кеша.
Если бы БД работали со скоростью кеша то и кеш особо был бы не нужен… но мне кажется такое уже есть у Google — DataStore. Если из БД убрать join (и много чего ещё) то можно получить сопоставимые результаты (а заодно сможем удобно кластеризовать данные).
Если бы БД работали со скоростью кеша то и кеш особо был бы не нужен… но мне кажется такое уже есть у Google — DataStore. Если из БД убрать join (и много чего ещё) то можно получить сопоставимые результаты (а заодно сможем удобно кластеризовать данные).
Читаем по запросам — «денормализация данных» и «mysql как key-value хранилище»
Странно… Но интересно :) Какого типа у вас были данные в базе? И какие запросы вы использовали?
скорость DataStoreне особо не впечатляет (по наблюдениям паролетней давности)
хоть джойнов там и нету, но из-за распределёнки есть zigzag merge, что по сути тотже джойн, но на стопицот таблиц.
хоть джойнов там и нету, но из-за распределёнки есть zigzag merge, что по сути тотже джойн, но на стопицот таблиц.
Sign up to leave a comment.
Хороший, плохой и злой… кэш