Комментарии 12
мм, может хабракат добавить?)
Неструктурированная статья без идеи и конца.
А главное, откровение-то где?
Не нужно жертвовать избыточностью в погоне за производительностью. Все хорошо, что в меру.
Вот Вам и откровение :)
Вот Вам и откровение :)
Сомнительное какое-то откровение… В проекте, которым занимаюсь я, повышение производительности как раз избыточностью часто и достигается, жертвы-то тут при чем? В общем, неубедительно!
Все так. Но я имел в виду не только избыточность данных, но и «избыточность проектирования». Абстракции, шаблоны — это ведь тоже избыточность, верно? А это палка о двух концах. Все хорошо в меру — вот истинное откровение.
Мне очень жаль автора. Ему слили карму и больше он ничего не напишет. Но он ведь настоящий разработчик, а не геймер или обозреватель сомнительных устройств. Такие люди нужны хабру.
Мне очень жаль автора. Ему слили карму и больше он ничего не напишет. Но он ведь настоящий разработчик, а не геймер или обозреватель сомнительных устройств. Такие люди нужны хабру.
В этом топике основная идея вытекает из названия «откровение разработчика». Попросту говоря — это своего рода попытка поделиться с аудиторией своими размышлениями и выводами. Все эти соображения навеяны нашей повседневной «кухней веб-индустрии» в которой 5 дней в неделю каждый разрабочик ведет свой нелегкий проект. А так как нашей работе нет «конца», то и мой пост будет иметь продолжение, если конечно аудитория поддержит. Возможно кто-то ожидал другого откровения, но увы, я только про разработку.
Мне понравилось ваше откровение.
Возможно, оно очевидно. Но иногда, после прочтения некоторых упоротых комментов, нет-нет да и начнешь сомневаться. В таких случаях нужны подтверждения вроде вашего. Спасибо Вам за это!
Возможно, оно очевидно. Но иногда, после прочтения некоторых упоротых комментов, нет-нет да и начнешь сомневаться. В таких случаях нужны подтверждения вроде вашего. Спасибо Вам за это!
Хоть текста и немного, но очень тяжело для восприятия. Сложилось впечатление, что это просто ваши мысли на момент написания топика. Для личного блога, который читают те, кто вас хорошо знает и понимает по контексту, о чем вы говорите, может, и сгодится, но на публику надо бы что-то более структурированное и лаконичное.
Всегда интересно узнать об опыте коллег по цеху, но в таком виде, извините, нечитабельно. Это только мое мнение, может, я ошибаюсь.
Всегда интересно узнать об опыте коллег по цеху, но в таком виде, извините, нечитабельно. Это только мое мнение, может, я ошибаюсь.
>В какой-то мере все это так. Но, как показывает практика, проблема нехватки процессорных ресурсов >стоит, как правило, на последнем месте, если речь идет о крупных web-проектах с огромной >посещаемостью, таких как, например, Facebook. В условиях, как это модно говорить, «High Load», >основные проблемы сводятся, банально, к количеству оборотов шпиндельного двигателя жесткого диска в >секунду, благодаря «шторму» запросов к базе данных, непрерывно поступающих от пользователей >«мировой паутины».
И нафига вот только эти недоумки из Facebook написали собственный PHP на 40% быстрее чем тот который у них есть. Наверное не знали что «проблема нехватки процессорных ресурсов стоит, как правило, на последнем месте».
И нафига вот только эти недоумки из Facebook написали собственный PHP на 40% быстрее чем тот который у них есть. Наверное не знали что «проблема нехватки процессорных ресурсов стоит, как правило, на последнем месте».
Интересно, что именно facebook девелоперы модифицировали в php, чтобы повысить производительность на 40%? Может быть они написали свой eAccelerator? Дайте ссылку на статью, плиз. В принципе, это не новость, что с ростом нагрузок некоторым гигантам it-индустрии приходится модифицировать под свои нужды СУБД и даже операционную систему. Google написали в итоге свою *NIX подобную операционку. Яндекс так модифицировал Оракл, что специалист компании-производителя этой СУБД был сражен наповал. Как я говорил и этому есть подтверждения в практиках нагрузочного тестирования, с применением горизонтального масштабирования и высоким ростом посещаемости нагрузка на процессор растет пропорционально меньше на порядок, чем нагрузка на ресурсы памяти, особенно дисковой. На сколько я понял из ваших публикаций вам тоже пришлось менять 2,5 строчки кода на C в библиотеке memcached. С помощью этой библиотеки кэширования вы снизили нагрузку к БД и частично процессор, при этом теперь нагрузка перешла на ресурсы оперативной памяти. Но не все запросы к базе можно кэшировать, а если у вас видеохостинг все в кэш не положишь. Только представьте и вы поймете, что не зря Яндекс модифицировал свою СУБД и ОС, которая изначально даже и не была рассчитана для работы с пентабайтами данных. И я не отказываюсь от роли процессоров в этих системах, а лишь хочу дать понять, что основной акцент надо делать на гибкости разработки, а оптимизация и масштабирование под высокие нагрузки так или иначе понадобится потом. Если вы не пишите Гугл, то БД сможете масштабировать, например, mysql proxy, использовать Ситрикс и т.д. и т.п.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Откровение разработчика