> Про apache/freebsd могу поверить, про php нет, разве что на фронтенде его используют.
ну про фронтенд и речь. конечно, в таком сложном хозяйстве одним языком не обойдёшься. поиск, ясное дело, на C++.
имейте в виду, что ebay я записал в актив ms, хотя там на нём только фронтенд. так что лучше не спорьте. :)
вообще, yahoo известный сторонни FOSS: они, помимо того что используют freebsd, ещё и хостят их сервера, бесплатно, под крышей apache foundation поддерживают и разрабатывают hadoop — альтернативу гугловому gfs и mapreduce.
> стоимость всех лицензий обычно составляет 3-5% от стоимости всего остального в проекте.
понятно, что это немного. но 3-5% от, скажем, операционных расходов (я не говорю доходов) — это. уверяю вас, много. если такие расходы не компенсируется подавляющим превосходством над свободными аналогами, то они будут сэкономлены. по факту, когда жти самые 3-5% становятся заметными деньгами, то есть на больших проектах, то есть на тех самых top100, ms не имеет подавляющего превосходства над конкурентами.
прикиньте, сколько бы фейсбуку стоили ~1800 лицензий на mssql, на мультиядерные машины. 1800 mysql серверов не стоят ничего и обслуживаются (по их словам) то ли двумя, то ли пятью dba (точно не помню, могу поискать видео где они рассказывали об этом).
> Вам часто приходилось переписывать MySQL или PHP под свои нужды?
вы не понимаете. мы говорим об alexa top 100. эти ребята переписывают не моргнув глазом. более того, не знаю как там myspace (я слышал, чтоу них какие-то свои, особые отношения с ms), но абсолютно все остальные из top10 значительно модифицируют используемый софт. берусь утверждать, что на таких больших веб-проектах это абсолютно необходимо, без этого никак. ну или очень, очень плохо.
местный пример: думаете, от хорошей жизни одноклассники переписали всё с asp.net/mssql на java? та же фигня была и в orkut.
> В отличие от Oracle, MS SQL не позволяет делать прозрачное горизонтальное масштабирование.
я вам открою тайну: sql вообще не масштабируется до нагрузок порядка alexa top100. ни ms, ни my, ни postgres, ни oracle. «простого» автоматического масштабирования до таких нагрузок, с сохранением семантики sql и на более-менее реальном железе не бывает.
фактически, у каждого участника топа алексы есть своя реализация хранилища данных для основного сервинга. sql может стоять где-то сзади, за ним, а может и совсем его не быть.
обо всём вышесказанном можно спорить — дешевле/не дешевле, надо/не надо. предлагаю этого не делать. я как раз предлагаю смотреть с длругой стороны: простой факт, что технологии ms используются менее, чем десятью из сайтов в alexa top100 (включая, так уж и быть, сайты самой ms) говорит о том, что для реально нагруженных проектов выбирают всё-таки не ms. о причинах можно спорить, но это факт: абсолютно независимые.
и уж совсем близко к теме данной статьи: начинать веб-проект на технологиях мс не стоит, потому что если «выстрелит», то придётся или мучаться, или переписывать, или и то, и другое.
> Странно. Yahoo тоже на дотнете, если мне склероз не изменяет. С Yahoo получается 5 сайтов в топ-10.
изменяет (ну, или если буквально, то склероз и правда не изменяет :)
yahoo стоит на трёх столпах — apache, php, freebsd.
так что нет, не получается.
> А на счёт остальных — каким методом проверяли?
смотрел на строку server в ответах, а также пользовался инфой собранной в инете (про ebay, например, была статья, что у них на фронтенде по-прежнему IIS, аппсервера на яве и база на оракле).
> Максимум, что я могу понять — по знакомым расширениям, типа php, aspx
они обманчивы. например «www.orkut.com/Main#Home.aspx» ничего не значит — оркут был переписан, когда для поддержки понадобилось более 10 серверов. душераздирающая история :)
> Если по неткрафту судить, на каждые 3 сайта приходиться 1 на IIS и 2 на апаче, где-то так)
моё объяснение такое: мелкие сайты на технологиях мс запускаются легко, а вот масштабируются они плохо: лицензирование, невозможность модификации, недоступность кода мешают сторонним разработчикам широко их внедрять. вернее, FOSS для этого лучше подходит.
> полицейские просмотрели информацию на компьютере обвиняемого. И тут открылись интересные факты.
при чём здесь Google? эта новость была бы связана с Google, если бы человек вычистил свой комп, а Google выдал его последние запросы и по этим данным его бы осудили.
в данном же случае имеет место простая человеческая глупость — искал на своём компе, да ещё и не вычистил.
не будем устраивать разборки кто что знал или не знал (нет, не знал — я не читаю каждый коммент к статье).
> я писал второпях так как знал, что если не я, то кто-то другой об этом напишет.
ага, значит мотивация — «успеть тиснуть». с позволения сказать, присунуть. не, вы правда считаете это оправданием?
поговорка есть такая: «спешка хороша при ловле блох...» (поищите продолжение в вашей любимой поисковой системе, если интересно).
удачи.
> Но важным может быть то, что крупные компании начали более-менее массированно покупать услуги по региональному кешированию, и небольшим компаниям, как только они начнут выходить из фазы стартапов, придётся думать о покупке не только трафика, но и кешей.
Впрочем я не буду удивлён, если это происходит уже сейчас.
именно. вы так говорите, будто проблемы с задержками появились только вчера. региональное кеширование было, есть и будет оставаться насущной необходимостью как минимум до тех пор, покуда не будет найден способ передачи информации быстрее скорости света. то есть ещё довольно долго.
по моему мнению, нет ничего плохого в том, что компания покупает услуги крупных региональных, — подчёркиваю: покупает обычные провайдерские услуги, без qos, — и ставит у провайдеров свои сервера.
теперь — да. а чтобы пояснить что означает несколько и против чего собственно я выступал — изначальный заголовок статьи был «Google выступил против принципов сетевой нейтральности», а содержание как раз и было почти дословной перепечаткой WSJ.
я рад что вы исправились, статься стала более взвешенной. но хочу сказать, что столь кардинальные правки после публикации — это неуважение к комментаторам. например, моё выступление выглядит теперь совершенно необоснованным, в то время как оно было справедливо по отношению к изначальному тексту статьи.
я надеялся, что до хабрахабра этот бред не дойдёт или по крайней мере не выйдет на главную, что хватит ума не переводить тупо каждый высер, тем более когда уже предостаточно вполне развёрнутых ответов и разъяснений в чём именно этот осёл из wsj неправ.
но материал дошёл и вышел на главную. к сожалению, хабр проверку на адекватность не прошёл. не могу сказать, что это пробуждает во мне желание плюсануть того, кто это говно перепечатал.
лично для меня это просто является показателем того, насколько сильна в журнализдских кругах анти-гугл паранойя. уж не знаю, бескорыстно или нет, но факт: самый безобидный повод, искажается до неузнаваемости и раздувается до совершенно непотребных размеров.
ещё вчера сорвал голос на западных форумах, доказывая что построение региональных кэшей — это абсолютно нормальная практика и единственный, фактически, способ снизить задержки… на сегодня меня уже не осталось. думайте что хотите.
со встроенным перлом он начнёт захлёбываться куда раньше.
таким образом, сервить «тяжёлые» страницы вместе с «лёгкими» (статикой) становится невозможно, потому что тяжёлые страницы (на встроенном перле) блокируют всё подряд (эффект, которым апач не страдает).
начинаем добавлять воркеров, сгружать статику (чтоб не тупила), оставляем только тяжёлые страницы… что получается? получается тот же апач 1.3, только с извращениями. польза? знакомство со внутренностями nginx, изощрённый трах с embedded перлом, но никак не рабочее решение.
я думаю мы говорим об одном и том же.
если цель состояла в избавлении от «бэкенда», т.е. отдельного сервера для обработки скриптов и совмещения его с «лёгким», использующимся для раздачи статики, то она не выполнена. а всё потому, что обработка перла тормозит всю работу воркера nginx. так что в этом смысле полученный резльтат даже хуже чем апач 1.3: если воркер nginx обрабатывает 1000 запросов на отдачу картинок и ему приходит 1001-й запрос, который уходит во встроенный перл и заставляет его задуматься, то обработка остальных запросов останавливается.
nginx очень хорошо справляется с задачей по «перекладыванию» данных между файл-дескрипторами (отдача статики, проксирование), но производить какие-либо нетривиальные вычисления в этом цикле категорически нельзя.
как хак — пойдёт, молодцы ребята. в продакшн — боже сохрани.
nginx — сервер не мультитредовый, исполнение перла блокирует обработку запросов.
в итоге все его преимущества разом идут лесом. в итоге вы получили масштабируемость от числа воркеров.
поздравляю, вы изобрели апач 1.3 :)
чего я не понял, так это почему не существует полной схемы оригинального устройства, в то время как их ещё сохранилось несколько штук, а одно даже находится в музее компьютерной истории (из него вытаскивали и коипровали ПЗУ). почему было не срисовать заодно и схему?
слово replica надо переводить, и переводить как 'копия". как совершенно правильно сказано далее по тексту, калькулятор называется Busicom 141-PF. а это — более-менее похожая на него (хотя и не точная) копия.
что значит — зря? это факт. сведения надёжные, уж поверьте мне.
про рунет я не спорю — сам в соседнем топике писал, что опера — российско-украинский феномен. в рунете её больше чем 17, в рунете её 25, а в укрнете почти 30. но и всё, больше в мире нигде существенной доли у неё нет.
а рунет+уанет — это ничтожная его часть. так что не удивительно что опера едет в россию — им, в общем-то. и ехать больше некуда.
ну про фронтенд и речь. конечно, в таком сложном хозяйстве одним языком не обойдёшься. поиск, ясное дело, на C++.
имейте в виду, что ebay я записал в актив ms, хотя там на нём только фронтенд. так что лучше не спорьте. :)
вообще, yahoo известный сторонни FOSS: они, помимо того что используют freebsd, ещё и хостят их сервера, бесплатно, под крышей apache foundation поддерживают и разрабатывают hadoop — альтернативу гугловому gfs и mapreduce.
> yahoo на пару лет появился раньше, чем php. :)
в 2002 году перешли с перла на PHP: Yahoo Moving to PHP
> стоимость всех лицензий обычно составляет 3-5% от стоимости всего остального в проекте.
понятно, что это немного. но 3-5% от, скажем, операционных расходов (я не говорю доходов) — это. уверяю вас, много. если такие расходы не компенсируется подавляющим превосходством над свободными аналогами, то они будут сэкономлены. по факту, когда жти самые 3-5% становятся заметными деньгами, то есть на больших проектах, то есть на тех самых top100, ms не имеет подавляющего превосходства над конкурентами.
прикиньте, сколько бы фейсбуку стоили ~1800 лицензий на mssql, на мультиядерные машины. 1800 mysql серверов не стоят ничего и обслуживаются (по их словам) то ли двумя, то ли пятью dba (точно не помню, могу поискать видео где они рассказывали об этом).
> Вам часто приходилось переписывать MySQL или PHP под свои нужды?
вы не понимаете. мы говорим об alexa top 100. эти ребята переписывают не моргнув глазом. более того, не знаю как там myspace (я слышал, чтоу них какие-то свои, особые отношения с ms), но абсолютно все остальные из top10 значительно модифицируют используемый софт. берусь утверждать, что на таких больших веб-проектах это абсолютно необходимо, без этого никак. ну или очень, очень плохо.
местный пример: думаете, от хорошей жизни одноклассники переписали всё с asp.net/mssql на java? та же фигня была и в orkut.
> В отличие от Oracle, MS SQL не позволяет делать прозрачное горизонтальное масштабирование.
я вам открою тайну: sql вообще не масштабируется до нагрузок порядка alexa top100. ни ms, ни my, ни postgres, ни oracle. «простого» автоматического масштабирования до таких нагрузок, с сохранением семантики sql и на более-менее реальном железе не бывает.
фактически, у каждого участника топа алексы есть своя реализация хранилища данных для основного сервинга. sql может стоять где-то сзади, за ним, а может и совсем его не быть.
обо всём вышесказанном можно спорить — дешевле/не дешевле, надо/не надо. предлагаю этого не делать. я как раз предлагаю смотреть с длругой стороны: простой факт, что технологии ms используются менее, чем десятью из сайтов в alexa top100 (включая, так уж и быть, сайты самой ms) говорит о том, что для реально нагруженных проектов выбирают всё-таки не ms. о причинах можно спорить, но это факт: абсолютно независимые.
и уж совсем близко к теме данной статьи: начинать веб-проект на технологиях мс не стоит, потому что если «выстрелит», то придётся или мучаться, или переписывать, или и то, и другое.
изменяет (ну, или если буквально, то склероз и правда не изменяет :)
yahoo стоит на трёх столпах — apache, php, freebsd.
так что нет, не получается.
> А на счёт остальных — каким методом проверяли?
смотрел на строку server в ответах, а также пользовался инфой собранной в инете (про ebay, например, была статья, что у них на фронтенде по-прежнему IIS, аппсервера на яве и база на оракле).
> Максимум, что я могу понять — по знакомым расширениям, типа php, aspx
они обманчивы. например «www.orkut.com/Main#Home.aspx» ничего не значит — оркут был переписан, когда для поддержки понадобилось более 10 серверов. душераздирающая история :)
> Если по неткрафту судить, на каждые 3 сайта приходиться 1 на IIS и 2 на апаче, где-то так)
моё объяснение такое: мелкие сайты на технологиях мс запускаются легко, а вот масштабируются они плохо: лицензирование, невозможность модификации, недоступность кода мешают сторонним разработчикам широко их внедрять. вернее, FOSS для этого лучше подходит.
понимаете, когда машин становится много, такие фичи как гибкость, возможность доводки под себя и, да, стоимость софта выходят на первый план.
как говорится, делайте выводы сами.
при чём здесь Google? эта новость была бы связана с Google, если бы человек вычистил свой комп, а Google выдал его последние запросы и по этим данным его бы осудили.
в данном же случае имеет место простая человеческая глупость — искал на своём компе, да ещё и не вычистил.
> я писал второпях так как знал, что если не я, то кто-то другой об этом напишет.
ага, значит мотивация — «успеть тиснуть». с позволения сказать, присунуть. не, вы правда считаете это оправданием?
поговорка есть такая: «спешка хороша при ловле блох...» (поищите продолжение в вашей любимой поисковой системе, если интересно).
удачи.
Впрочем я не буду удивлён, если это происходит уже сейчас.
именно. вы так говорите, будто проблемы с задержками появились только вчера. региональное кеширование было, есть и будет оставаться насущной необходимостью как минимум до тех пор, покуда не будет найден способ передачи информации быстрее скорости света. то есть ещё довольно долго.
по моему мнению, нет ничего плохого в том, что компания покупает услуги крупных региональных, — подчёркиваю: покупает обычные провайдерские услуги, без qos, — и ставит у провайдеров свои сервера.
я рад что вы исправились, статься стала более взвешенной. но хочу сказать, что столь кардинальные правки после публикации — это неуважение к комментаторам. например, моё выступление выглядит теперь совершенно необоснованным, в то время как оно было справедливо по отношению к изначальному тексту статьи.
но материал дошёл и вышел на главную. к сожалению, хабр проверку на адекватность не прошёл. не могу сказать, что это пробуждает во мне желание плюсануть того, кто это говно перепечатал.
ещё вчера сорвал голос на западных форумах, доказывая что построение региональных кэшей — это абсолютно нормальная практика и единственный, фактически, способ снизить задержки… на сегодня меня уже не осталось. думайте что хотите.
таким образом, сервить «тяжёлые» страницы вместе с «лёгкими» (статикой) становится невозможно, потому что тяжёлые страницы (на встроенном перле) блокируют всё подряд (эффект, которым апач не страдает).
начинаем добавлять воркеров, сгружать статику (чтоб не тупила), оставляем только тяжёлые страницы… что получается? получается тот же апач 1.3, только с извращениями. польза? знакомство со внутренностями nginx, изощрённый трах с embedded перлом, но никак не рабочее решение.
если цель состояла в избавлении от «бэкенда», т.е. отдельного сервера для обработки скриптов и совмещения его с «лёгким», использующимся для раздачи статики, то она не выполнена. а всё потому, что обработка перла тормозит всю работу воркера nginx. так что в этом смысле полученный резльтат даже хуже чем апач 1.3: если воркер nginx обрабатывает 1000 запросов на отдачу картинок и ему приходит 1001-й запрос, который уходит во встроенный перл и заставляет его задуматься, то обработка остальных запросов останавливается.
nginx очень хорошо справляется с задачей по «перекладыванию» данных между файл-дескрипторами (отдача статики, проксирование), но производить какие-либо нетривиальные вычисления в этом цикле категорически нельзя.
nginx — сервер не мультитредовый, исполнение перла блокирует обработку запросов.
в итоге все его преимущества разом идут лесом. в итоге вы получили масштабируемость от числа воркеров.
поздравляю, вы изобрели апач 1.3 :)
слово replica надо переводить, и переводить как 'копия". как совершенно правильно сказано далее по тексту, калькулятор называется Busicom 141-PF. а это — более-менее похожая на него (хотя и не точная) копия.
про рунет я не спорю — сам в соседнем топике писал, что опера — российско-украинский феномен. в рунете её больше чем 17, в рунете её 25, а в укрнете почти 30. но и всё, больше в мире нигде существенной доли у неё нет.
а рунет+уанет — это ничтожная его часть. так что не удивительно что опера едет в россию — им, в общем-то. и ехать больше некуда.