На страницу Пред. 1, 2, 3, 4, 5 След. |
|
Ср Авг 20, 2008 6:28 am |
Start Post: Выбираем язык программирования. |
Вацлав Сетевой Гугляка |
Зарегистрирован: 21.02.2006
Сообщений: 4965
|
Обратиться по нику
|
Вацлав |
Ответить с цитатой | | |
|
«А у вас нет такой же, только с перламутровыми пуговицами? Нету? Будем искать...».
Почти у каждого вебмастера в определенный момент начинается зуд в мозгах, вызванный желанием что-то переделать по своему. Запрограммировать какие-то рутинные процессы или сделать какой-то свой движок. Не открою секрета, если скажу, что все существующие готовые движки чего-либо (от счетчиков до блогов и CMS) сделаны мягко говоря «через жопу». Если быть точнее, то через жопу сферического усредненного пользователя. Чтобы нравиться и нашим и вашим. При разработке публичных приложений, чтобы угодить большинству пользователей обычно используется принцип маркетинговых весов «угодим-разозлим». Если на примере, то это ТВ-реклама. Не секрет, что многих людей старшего возраста раздражает реклама прокладок или презервативов. Но она нацелена на другую аудиторию, выгода от которой перевесит «разозленность». Так и в случае с публичными движками, которые идут по пути Windows — угодить домохозяйкам и плевать на производительность.
Впрочем, философские сентенции оставим философам, а сами озадачимся более приземленными вопросами.
1. А шо ви имеете таки мне предложить?
А предлагают нам нынче широчайший выбор языков применимых в сети. Я выбрал для сравнения только шесть, потому что знаю их в разной степени (седьмой — ASP я вычеркиваю из списка, потому что .... потому что вычеркиваю и все тут). Перечислять буду в соответствии со степнью владения мною. Многие оценки субъективны и базируются на старых привычках (например я считаю синтаксис и пространство имен языков Pascal и Xbase более выразительным, чем C и его производных, а «правила» бейсика и вовсе на дух не переношу). Сравнивать я буду простыми словами, не прибегая к страшным заклинаниям типа «инкапсуляция, полиморфизм, множественное наследование, обратная рекурсия». Да-да. Я знаю еще много страшных слов.
1.1. Старый добрый ПыХыПэ.
http://www.php.net/
Заслуженный ветеран броуновского движения и несомненный лидер в сайтопроизводстве.
Плюсы: есть на подавляющем числе хостингов, умеет встраиваться в html, прост в применении, обладает массой библиотек и классов, богатейшая документация, обилие учебников и сообществ.
Минусы: не самая удачная (мягко говоря) объектно-ориентированная модель, неудобный синтаксис, относительно низкая производительность.
Примечание: все остальные языки (за исключением Java) без «костылей» не умеют встраиваться в HTML. Это автоматически зачисляется им в минусы всем сразу же.
1.2. Рубероид, он же Ruby.
http://www.ruby-lang.org/en/
Пожалуй самый молодой язык из всей «шестерки». Очень красивый и удобный язык. Не путайте язык Ruby с его сверхпопулярным производным фреймворком Ruby on Rails (RoR).
Плюсы: потрясающе продуманный синтаксис, масса уникальных возможностей, самый «высокоуровневый язык» из рассматриваемых, самый маленький объем кода, прекрасная объектная модель, легок в освоении и «быстром программировании».
Минусы: малое распространение на хостингах, дефицит хороших бумажных учебников.
1.3. ... и друг его жемчужный Perl.
http://www.perl.org/
Не менее старый и не менее распространенный, чем PHP.
Плюсы: за исключением умения встраиваться в html имеет те же выраженные плюсы, что и PHP, но существенно быстрее оного.
Минусы: Он стар. Он очень стар. Место на кладбище его давно поджидает. Ну и плюс минусы того же PHP.
1.4. Они называли меня желтой рыбой? (с). Python.
http://www.python.org/
Вообще-то язык обязан названием не ползучему гаду, а Монти Пайтону, ну да это не важно. Язык хорош как синтаксисом, так и производительностью. То что его использует Google наверное говорит само за себя, не так ли?
Плюсы: хороший и крепкий середнячок. Достаточно быстрый, в меру удобный.
Минусы: все еще мало распространен.
1.5. Java — это кофе, а не сигареты.
http://openjdk.java.net/
Ууу. Я бы назвал Яву царь-языком, но слишком уж слишком люблю изящество Ruby и привык к PHP. Но статус-кво таково, что Яву используют все кому не лень. Потому что это удобно, практично и даже модно.
Плюсы: это самый «быстрый» язык, самый гибкий язык и один из самых распространенных и перспективных. А его родственность с JavaScript и дает ему огромную фору. Умеет «встраиваться» в html маскируясь JSP страницами. Ну а после шикарного инструмента GWT от Гугла получает и еще большее количество призовых очков.
Минусы: сложноват в освоении, имеет массу весьма запутанных реализаций, не очень хорошо распространен на «бюджетных» хостингах.
1.6. abC. До-Ре-Ми-Фа-Соль-Ля-Си.
http://gcc.gnu.org/
Все разновидности языка (C, CPP, C#) очень популярны и вполне заслуженно. Мощный язык с отличной производительностью.
Плюсы: высокая производительность, огромное количество документации, богатая история.
Минусы: крайне хреновая интеграция в WWW, сложность для освоения.
2. Вам шашечки или ехать?
Вообще-то, лучший язык тот, который вы лучше знаете. Но для разных задач лучше подходят разные языки. С обслуживанием нетяжелых www проектов отлично подходит старый добрый PHP. Perl и python по сути уже встраиваются в большинство линуксов и могут служить там скриптовыми языками (впрочем они и в Windows это могут, только кому это нужно?). Ruby, благодаря своей простоте и компактности, отлично подойдет начинающим программистам, как весьма универсальный язык для автоматизации рутинных задач. Java и Си позволяют достичь в большинстве случаев феноменальной производительности при тяжелых нагрузках, а вот программировать на них примитивные задачи мне представляется нецелесообразным.
3. Производительность.
Самым узким местом в веб-программировании остаются http-запросы. Запрос-ожидание-ответ. Эта фаза зачастую на корню гробит преимущества в скорости таких языков как Java или Си. Трудно ехать на Феррари через московские пробки. Но при росте нагрузок и количестве запросов становится актуальным и фаза обработки данных на сервере и отдача ответа. Да так важно, что старичок PHP с трудом справляется с задачами TDS например. Генерацию или же синонимизацию контента лучше поручать и вовсе Яве. Но с другой стороны, стоимость железа нынче не так уж и высока, так что «ускорить» ПО можно и методом Microsoft — нарастить системные ресурсы. Иногда это оказывается существенно эффективнее и дешевле, чем нанимать специалиста или изучать язык самостоятельно.
Ну померять письками-то языки все же надо
Вот тут можно посмотреть замеры:
http://elliottback.com/wp/archives/2008/01/17/ruby-vs-php-performance-revisited/
Если вкратце, то Java в 200 раз быстрее PHP.
И маленькая поправка: в указанном тесте рассматривалась старая версия Ruby (1.8.5). Новая (1.9.0) работает в 4(!) раза быстрее старой, что переносит Ruby на третье место после Java и C++. Думаете остальные языки тоже подтянулись? Увы, но нет. Ruby молодой язык и у него еще остался запас для оптимизации, в отличии от оттюнингованных до последних процентов ветеранов.
4. Казуальное программирование.
Не знаю, есть такой термин или его я изобрел (лень гуглить), но делать быстрые наброски и простенькие скрипты удобнее всего на ... правильно На Руби. Я действительно влюбился в этот язык и весьма пристрастен. Хотя Python тоже очень и очень неплох.
5. Вацлав, гад! Ты еще больше меня запутал! Что же выбрать!?
Все зависит от задачи. Какой язык лучше — это такой же бессмысленный вопрос как и «какой дистрибутив Linux лучше и не лучше ли вообще Windows?». Ориентируйтесь на свои задачи, как и я. Я тоже использую разные языки для разных задач.
а) Слабонагруженные Web-проекты: лучшее — враг хорошего. Пользуйтесь PHP и всеми его плюсами. А про минусы забудьте.
б) Средние нагрузки, с потребностью быстро обрабатывать данные — вот тут лучше заменить старый Perl на новый Python.
в) Средние нагрузки, с обработкой большого числа запросов (например AJAX и прочие «вебдванольности») - Java + GWT = JavaScript + PHP.
г) Высокие нагрузки и обработка большого числа данных: Java.
д) Наброски рутинных скриптиков — Ruby.
Как видите, Руби не особо где нужен, если честно. Но благодаря его удобству я его использую в о всех группах кроме «Г». Но, как я уже говорил — удобство языка это дело вкуса. Если же смотреть более объективно на вещи, то на первое место по перспективности я поставлю Java, а на второе Python. |
|
|
|
|
|
Второе пришествие Вацлава. Камингсуново. |
Cabal Гуру |
Зарегистрирован: 20.10.2007
Сообщений: 1360
|
Обратиться по нику
|
Cabal |
Ответить с цитатой | | |
|
Вацлав писал(а): |
Cabal, гхм. Я себя часто на страницах форума называю старпером и ветераном Но это не значит, что я себя дискредитирую
|
Ой. А я пока ты отвечал пост дополнял... Короче там ещё буковки появились... |
|
|
|
|
|
|
Вацлав Сетевой Гугляка |
Зарегистрирован: 21.02.2006
Сообщений: 4965
|
Обратиться по нику
|
Вацлав |
Ответить с цитатой | | |
|
Cabal, когда пишешь сам и всерьез от публичных классов часто приходится отказываться, либо выдирать из них нужные фрагменты кода. Публичные классы хороши тем, что они "усредненные". А для хорошей производительности, гибкости и безопасности - ничего лучше чем 100% своего кода не придумать. Поэтому любя Ruby я недолюбливаю Ruby on Rails (Джангу для Питона, соответственно). Мне нравится изучать чужие классы и фреймворки и брать из них для себя отдельные приемы, чтобы они работали так, как нужно именно мне, а не "среднему сферическому пользователю".
"Знай свой код!" - отличный девиз программирования. За десяток лет я не раз спотыкался на том, что какой-нибудь умник дает какой-нибудь переменной в классе или в функции общеупотребимое название (например GetRSSFeed) и потом придется головой об стену биться, если у тебя есть такая же переменная, которая почему-то теряет свое значение. |
|
|
|
|
|
Второе пришествие Вацлава. Камингсуново. |
Cabal Гуру |
Зарегистрирован: 20.10.2007
Сообщений: 1360
|
Обратиться по нику
|
Cabal |
Ответить с цитатой | | |
|
Вацлав, пример не понял... А как же область видимости? В PHP5 он может их хоть как в примерах в официальном мануале обзывать чтоб уж точно похожие переменные в коде пользователя его класса найшлись, но толку не будет - их не видно вне функций и вне класса если не обозвать глобальными в функциях или правильно не обратиться к классу. В целом вопросы только по примеру, в остальном я тебя понял. Позиция безупречна. Даже завидую наверно чуть чуть. Но на данном этапе жизни мне главное быстрее чем качественнее . Ну и вопрос а нужно ли это ООП тому кто пишет сам а не юзает чужое конечно не последний в списке... |
|
|
|
|
|
|
Вацлав Сетевой Гугляка |
Зарегистрирован: 21.02.2006
Сообщений: 4965
|
Обратиться по нику
|
Вацлав |
Ответить с цитатой | | |
|
Cabal, в этом и проблема, что некоторые "умники" не устанавливают областей видимости, а то и шпарят свои переменные как GLOBAL.
Ну вот и для "быстрее" чем качественнее я использую как раз Ruby И уже после обточки самого алгоритма и его слабых звеньев переписываю (или заказываю) на более производительных языках. |
|
|
|
|
|
Второе пришествие Вацлава. Камингсуново. |
Cabal Гуру |
Зарегистрирован: 20.10.2007
Сообщений: 1360
|
Обратиться по нику
|
Cabal |
Ответить с цитатой | | |
|
Вацлав, ну вот я же и говорю какой PHP5 отличный язык программирования . Там надо объявить переменную глобальной чтобы она стала а к переменным внутри классов своя процедура обращения. Короче там уже не накосячишь как раньше . |
|
|
|
|
|
|
GFox Опытный |
Зарегистрирован: 14.10.2007
Сообщений: 232
|
Обратиться по нику
|
GFox |
Ответить с цитатой | | |
|
Cabal писал(а): |
Ну и вопрос а нужно ли это ООП тому кто пишет сам
|
ООП нужно обязательно! Эта просто маст-кноу парадигма программирования , один раз написав грамотно класс , можешь всегда его везде юзать без проблем. Вообще я ультра-аццкий приверженец и фанат ООП , т.к считаю это самым гибким способом создания приложений. А язык программирования плохо поддерживающий ООП , для меня не серьёзная вещь. |
|
|
|
|
|
|
Cabal Гуру |
Зарегистрирован: 20.10.2007
Сообщений: 1360
|
Обратиться по нику
|
Cabal |
Ответить с цитатой | | |
|
GFox, ну это фанатизм. Одобряю, но ведь не все здесь - фаны ООП. А потом судя по подписи у тебя другие потребности нежели у меня. Я софт только для себя пишу и в общем то грамотности у меня нет достаточной чтобы коммерческие приложения разрабатывать. Но ведь и у большинства начинающих изучать программирование с нуля причём сразу именно в разрезе написания мини money-dowload-скриптов потребности близки к моим, а не к потребностям коммерческой разработки на продажу или под заказ. Главное быстро пока тема не ускользнула всё разрулить а какой там код - чистый-грязный, прямой-кривой, переносимый-не переносимый, стоит в конце списка. |
|
|
|
|
|
|
GFox Опытный |
Зарегистрирован: 14.10.2007
Сообщений: 232
|
Обратиться по нику
|
GFox |
Ответить с цитатой | | |
|
Ну ты прав в целом , я сам начинал кодить с PHP Когда нужно быстро и для себя , о коде не заморачиваешся вообще |
|
|
|
|
|
|
grozny Опытный |
Зарегистрирован: 03.02.2006
Сообщений: 121
|
Обратиться по нику
|
grozny |
Ответить с цитатой | | |
|
Сам Руби хорош для маленьких скриптов за счет своего супер краткого синтаксиса.
Но почему забыли про ruby on rails?
Имхо вся сила руби именно в нем.
По моему опыту, этот фреймворк резко увеличивает производителньность труда програмера, я не побоюсь сказать раза в 3 по сравнению с пхп.
На пхп есть кастрированная версия рельсов - symfony, но она все равно не дотягивает немного.
Конечно когда нужны "системные" или консольные скрипты то Ror нафик нужен.
А вот для построения сайтов - это просто песня. |
|
|
|
|
|
What to do, how to be... |
Вацлав Сетевой Гугляка |
Зарегистрирован: 21.02.2006
Сообщений: 4965
|
Обратиться по нику
|
|
|
Второе пришествие Вацлава. Камингсуново. |
nerezus Свой |
Зарегистрирован: 22.05.2009
Сообщений: 5
|
Обратиться по нику
|
nerezus |
Ответить с цитатой | | |
|
Цитата: |
все остальные языки (за исключением Java) без «костылей» не умеют встраиваться в HTML. Это автоматически зачисляется им в минусы всем сразу же.
|
Отсутствие вредной неиспользуемой возможности - минус?
Читаем http://ru.wikipedia.org/wiki/MVC
Цитата: |
PHP - относительно низкая производительность.
|
По сравнению с руби он держит гораздо большую нагрузку.
Цитата: |
Python. Плюсы: хороший и крепкий середнячок. Достаточно быстрый, в меру удобный.
Минусы: все еще мало распространен.
|
Очень широко распространен, тот же tiobe рейтинг глянь. Тот же YouTube на питоне, к примеру, как и многие гугловые вещи.
Цитата: |
Все разновидности языка (C, CPP, C#)
|
C# так же относится к C, как говно страуса к Юпитеру.
Это абсолютно разные языки с абсолютно разными технологиями и подходами.
C# можно назвать клоном джавы(ОЧЕНЬ похожи), но вот на C он нисколько не похож.
Цитата: |
Минусы: крайне хреновая интеграция в WWW, сложность для освоения.
|
Фееричный бред, про ASP.NET слышали?
Цитата: |
Самым узким местом в веб-программировании остаются http-запросы. Запрос-ожидание-ответ.
|
А мужики то и не знали, что это не СУБД.
А проблемы с http-нагрузкой легко решаются через проксирующие вебсервера для статики. И бэкенд уже за ними. И первым дохнет всегда бэкенд.
Цитата: |
Если вкратце, то Java в 200 раз быстрее PHP.
|
Нет понятия "быстрее" в вебе. Есть "производительнее". И они не пересекаются, а быстрота никому не нужна. |
|
|
|
|
|
|
DrKronos SEO-доктор |
Зарегистрирован: 11.03.2008
Сообщений: 13024
|
Обратиться по нику
|
DrKronos |
Ответить с цитатой | | |
|
Вы занимались HiLoad нагрузками? Не в теории, а на практике?
Статья ориентирована на АВМ-ов, если о чём-то это вам говорит.
Попробуйте их быстро перевести с LAMP на Python/Nginx. Я пробовал. Сложно.
MVC? Для сферического проекта отлично. Как и Django или ROR. Но для HiLoad да ещё и в высокорисковых нишах - самоубийство. В лучшем случае - web.py или CherryPy.
Цитата: |
По сравнению с руби он держит гораздо большую нагрузку.
|
Готовы поспорить на хорошую сумму денег?
Цитата: |
Очень широко распространен, тот же tiobe рейтинг глянь. Тот же YouTube на питоне, к примеру, как и многие гугловые вещи.
|
Я ковыряю Google App Engine ещё с его закрытых тестов, так что прекрасно знаю о возможностях и распространённости Python.
Но аудитория статьи - АВМы. Которые слаще чем WP в своей жизни ничего не видели. И для них Python - это экзотика. Объясните-ка обычному вебмастеру (не кодеру), как развернуть что-то под Nginx. Как скомпилить ручками Nginx для поддержки WSGI, как развернуть хотя бы FastCGI через юникс-сокеты и демонизировать процесс Python веб-приложения.
Цитата: |
C# так же относится к C, как говно страуса к Юпитеру.
Это абсолютно разные языки с абсолютно разными технологиями и подходами.
C# можно назвать клоном джавы(ОЧЕНЬ похожи), но вот на C он нисколько не похож.
|
Согласен, здесь накосячил и крепко.
Цитата: |
Фееричный бред, про ASP.NET слышали?
|
Я даже про Mono слышал. ASP.NET - это унылое корпоративное говно, уж простите мой французский. Win-платформа для HiLoad хороша только при фееричном бюджете.
Цитата: |
А мужики то и не знали, что это не СУБД.
|
Наивная точка зрения. В вебмастерских проектах, СУБД можно вывести из игры достаточно просто. Перенеся всё в Memcached или на раздел tmpfs файловой системы линукс. Слышали про такое?
Цитата: |
А проблемы с http-нагрузкой легко решаются через проксирующие вебсервера для статики. И бэкенд уже за ними. И первым дохнет всегда бэкенд.
|
И тем не менее, http - остаётся самым уязвимым и медленным звеном. Про ДДос тоже слышали наверное?
Цитата: |
Нет понятия "быстрее" в вебе. Есть "производительнее". И они не пересекаются, а быстрота никому не нужна.
|
Что, серьёзно? Ну пускай так и думает большинство. А я точно знаю, что скорость ответа сервера и передача контента клиенту влияют непосредственно на мою прибыль. Скажем, процентов 20 прироста. |
|
|
|
|
|
Здесь могла быть ваша реклама |
nerezus Свой |
Зарегистрирован: 22.05.2009
Сообщений: 5
|
Обратиться по нику
|
nerezus |
Ответить с цитатой | | |
|
Цитата: |
Вы занимались HiLoad нагрузками? Не в теории, а на практике?
|
Да, но лишь однажды, проект с бюджетом 5к для города. Школьная сеть для 164 школ города, 300к пользователей(школьники, родители, учителя).
Цитата: |
Статья ориентирована на АВМ-ов, если о чём-то это вам говорит.
|
Проще нанять специалиста, это дешевле обойдется, если принять, что время=деньги.
А если человек хочет серьезно заниматься, то сразу стоит на качество упирать.
Цитата: |
Наивная точка зрения. В вебмастерских проектах, СУБД можно вывести из игры достаточно просто. Перенеся всё в Memcached или на раздел tmpfs файловой системы линукс. Слышали про такое?
|
Для обльшого набора индексироанных данных это слабо поможет. Для таблиц на полгига это слишком жестоко.
Но с замечанием согласен, но подойдет это не везде, а только в случае частоиспользуемых небольших структур данных.
+ не стоит забывать и про кеширование самой СУБД.
Цитата: |
Объясните-ка обычному вебмастеру (не кодеру), как развернуть что-то под Nginx.
|
У всех заказчиков были свои админы, которые все делали. Минимальный проект был за 500 баксов(tube). Я сомневаюсь, что это такое везение, что были админы. В крайнем случае сам настрою.
Цитата: |
Наивная точка зрения. В вебмастерских проектах, СУБД можно вывести из игры достаточно просто. Перенеся всё в Memcached или на раздел tmpfs файловой системы линукс. Слышали про такое?
|
Сложновато.
Цитата: |
Готовы поспорить на хорошую сумму денег?
|
RoR vs PHP? Какую сумму? Как будет проводиться тестирование? На какой задаче?
Цитата: |
Win-платформа для HiLoad хороша только при фееричном бюджете.
|
Судя из опыта, гораздо проще докупить железок, чем выделить денег на програмимиста. Оптимизация выйдет дороже, т.к. время программиста дороже.
Цитата: |
А я точно знаю, что скорость ответа сервера и передача контента клиенту влияют непосредственно на мою прибыль. Скажем, процентов 20 прироста.
|
На сколько процентов увеличит прибыль уменьшение времени генереции страницы с ~0.1с до 0.05с?) 50мс пользователь не заметит.
Цитата: |
Про ДДос тоже слышали наверное?
|
Как правило первой не справляется база. Хотя если поток идет в 800мбит, то уже ничего не поможет.
P.S. вы в ПМ написали? не могу прочитать по кол-ву голосов. |
|
|
|
|
|
|
Lab Свой |
Зарегистрирован: 20.07.2007
Сообщений: 60
|
Обратиться по нику
|
Lab |
Ответить с цитатой | | |
|
nerezus писал(а): |
Да, но лишь однажды, проект с бюджетом 5к для города. Школьная сеть для 164 школ города, 300к пользователей(школьники, родители, учителя).
|
Это даже близко не HiLoad. Это, пардон, детский сад. HiLoad - это 100К пользователей, смотрящих видео онлайн.
Цитата: |
Проще нанять специалиста, это дешевле обойдется, если принять, что время=деньги. А если человек хочет серьезно заниматься, то сразу стоит на качество упирать.
|
Бывают проекты, в которые лишних людей нанимать вообще нельзя. Дабы пресечь утечки. И удачно выбранный язык программирования и платформа реализации обойдутся дешевле при масштабировании на 2-5-10 серверов.
Цитата: |
Для обльшого набора индексироанных данных это слабо поможет. Для таблиц на полгига это слишком жестоко.
Но с замечанием согласен, но подойдет это не везде, а только в случае частоиспользуемых небольших структур данных.
+ не стоит забывать и про кеширование самой СУБД.
|
И зачем нам таблицы в полтера? Если в веб-проекте таблица в полтерабайта, это означает только одно - нужно уволить того, кто проектировал базу данных. А. Вы о 500Мб? Так это детский лепет на лужайке, а не таблица. Около 100000 записей. Проблема с задержками решается через кэширование в памяти или на диске наиболее востребованных веб-документов.
Цитата: |
У всех заказчиков были свои админы, которые все делали. Минимальный проект был за 500 баксов(tube). Я сомневаюсь, что это такое везение, что были админы. В крайнем случае сам настрою.
|
Не у каждого вебмастера есть свои админы и уж тем более умения администрировать. Мы тут, в общем-то, в основном торгуем изображениями ебущихся людей
Цитата: |
RoR vs PHP? Какую сумму? Как будет проводиться тестирование? На какой задаче?
|
$5K устроит? В качестве приза за движок, который лучше выдержит 20 тысяч ежедневных просмотров видео, общим объемом терабайт. Плюс комментарии, плюс чат, плюс система рейтингования и естественно защита. Нет, конкурс вообще глупый, ибо лучше с этой задачей справится Python или Java (С++ ещё лучше, но мы пока остановимся не на AOT-компилируемых языках)
Цитата: |
Судя из опыта, гораздо проще докупить железок, чем выделить денег на програмимиста. Оптимизация выйдет дороже, т.к. время программиста дороже.
|
Время программиста = копейки по сравнению с ростом издержек при масштабировании Win-систем.
Цитата: |
На сколько процентов увеличит прибыль уменьшение времени генереции страницы с ~0.1с до 0.05с?) 50мс пользователь не заметит.
|
В реальности, разрыв доходит с 2 с per request до 0.1 sec per request. Это означает, что один и тот же сервер выдержит в десяток раз большую нагрузку перед тем как рухнуть. А ещё, это означает, что пришедшие боты поисковиков не обрушат ваш сайт и успеют сожрать и проиндексировать больше страниц.
Цитата: |
Как правило первой не справляется база. Хотя если поток идет в 800мбит, то уже ничего не поможет.
|
Базу, умный разработчик, уберёт на отдельный сервер и закэширует так, что она вообще не будет задействована в игре. А вот забить канал slow-connection-ами, существенно проще. |
|
|
|
|
|
|
nerezus Свой |
Зарегистрирован: 22.05.2009
Сообщений: 5
|
Обратиться по нику
|
nerezus |
Ответить с цитатой | | |
|
Цитата: |
Это даже близко не HiLoad. Это, пардон, детский сад. HiLoad - это 100К пользователей, смотрящих видео онлайн.
|
На тестах держало 20 запросов в секунду на динамику. Это примерно 1200k запросов или 120к уников, считая 10 запросов на уника.
Цитата: |
А. Вы о 500Мб? Так это детский лепет на лужайке, а не таблица.
|
Только вот как ее эффективно кешировать? Я вижу эту задачу нетривиальной. Не каждый же раз полгига ворочать.
Цитата: |
Не у каждого вебмастера есть свои админы и уж тем более умения администрировать.
|
Админ хостинга в конце концов. Если нет админа - могу сам базовую конфигурацию поставить и настроить.
Цитата: |
$5K устроит? В качестве приза за движок, который лучше выдержит 20 тысяч ежедневных просмотров видео, общим объемом терабайт. Плюс комментарии, плюс чат, плюс система рейтингования и естественно защита. Нет, конкурс вообще глупый, ибо лучше с этой задачей справится Python или Java (С++ ещё лучше, но мы пока остановимся не на AOT-компилируемых языках)
|
facebook как пример не покатит? PHP.
Далее по производительности: как пункты кроме видео и чата влияют на производительность? Или они для суммы, типа чтобы мбыло много чего делать и я не спорил, т.к. на рор это ощутимо проще реализовать?
Цитата: |
В реальности, разрыв доходит с 2 с per request до 0.1 sec per request. Это означает, что один и тот же сервер выдержит в десяток раз большую нагрузку перед тем как рухнуть. А ещё, это означает, что пришедшие боты поисковиков не обрушат ваш сайт и успеют сожрать и проиндексировать больше страниц.
|
Ну я же не битрикс юзаю, чтобы 2 секунды было
Цитата: |
А вот забить канал slow-connection-ами, существенно проще.
|
Согласен. Только это не канал забивается, а памяти не хватает, т.е. проблема из-за канала, но нагрузка на память.
P.S. Пудумал, что я неправ в:
Цитата: |
Цитата: |
А. Вы о 500Мб? Так это детский лепет на лужайке, а не таблица.
|
Только вот как ее эффективно кешировать? Я вижу эту задачу нетривиальной. Не каждый же раз полгига ворочать.
|
На том же питоне или джаве это вполне удобно, а вот в PHP нет многопоточного режима, а при работе со shmop придется каждый раз КОПИРОВАТЬ данные. Так что это существенный минус пхп, признаю. |
|
|
|
|
|
|
|
|
Партнеры
|