Ой. Это так смешно, про "условия сделки" :)
по условиям сделки разработчики скайпа оставались самостоятельной единицей
по условиям сделки разработчики вотсапа оставались самостоятельной единицей
список можно продолжать бесконечно
Другое дело, что СО — довольно кривой и бессмысленный сайт, с дебильными целями и модерацией. Так что испортить его ещё больше будет проблематично.
Каждые 14 секунд на Stack Overflow пользователи задают новый вопрос, а разработчики, посещающие платформу, получали помощь более 50 миллиардов раз с момента ее создания.
Устраивается на работу секретарша, её спрашивают:
— Скорость машинописи какая?
— 9000 знаков в минуту!
— Неужели можно с такой скоростью печатать?
— Конечно можно! Правда такая фигня получается...
Вот это про стаковерфлой, с его ордами индусов, которые друг другу на вопросы отвечают.
Дело в том что я стал в последнее время более-менее регулярно почитывать хабр. И обратил внимание, что качество контента ниже плинтуса. Неважно, переводного или оригинального.
И вот на этом фоне данная статья, хоть сама по себе и не представляет из себя ничего выдающегося, но хотя бы не обычный для этого ресурса адЪ. Вот именно этот факт я и захотел отметить. Как раз чтобы немного разбавить репутацию любителя набросить :) Хотя я не любитель. Просто я как тот мальчик из анекдота, пишу только когда суп пересолен.
А если говорить о переводах, то тут просто добавляется ещё один фактор риска — кроме исходно некачественного контента добавляется еще и никакое качество перевода. Но так-то, в самом по себе факте перевода никакого криминала нет.
Ну с одной стороны вы правы. Сейчас посмотрел — где-то 8-10 секунд до начала рендера на 1700 комментариев. Слава богу что улучшаторы пока не забрали у нас десктопную версию.
С другой — все-таки, 8 секунд — не 80.
С третьей — хабр в каком-то роде монополист, и люди терпят. Но будь у него более шустрые конкуренты, как это наблюдается в екомммерсе, то такие цифры очень быстро стали бы критическими.
Я извиняюсь, но задам нескромный вопрос. Какой объем информации в БД и какая посещаемость на этом сайте? Я так понимаю, что вопрос, в сущности, риторический.
А проблема битрикса в том, что с нагрузкой на динамические сайты он справляется примерно никак. Ключевое слово — динамические. Хорошо когда у тебя сказка про Хрюшу, которую можно закэшировать по самые помидоры. А когда у тебя склад и скидки по 20 критериям и ты должен продать клиенту товар ровно по той цене, которая ему обещана, и не продать тот, который уже закончился — вот тут в такой ситуации покажи мне сайт на битриксе — поговорим.
Связка "nginx+apache" действительно является пожарным решением, которое нивелирует основную проблему mod_php — висящий в памяти процесс Апача, пока медленный клиент забирает свой ответ. Энжинкс же быстренько забирает ответ в свой буфер, и спокойно отдаёт клиенту, сколько надо. Я и сам так делал в своё время, когда надо было сервер спасать, а хтаксессы чистить было некогда. Но при первой же возможности избавился от лишнего звена. Рекомендую. хтаксесс на самом деле не такой важный файл, как кажется :)
А я не могу понять, что здесь непонятного :)
Картинка — это набор байт. Или, по-другому, "данные". что нам мешает взять и записать данные в базу данных?
Ну понятно, что у поля не должна быть текстовая кодировка, но в остальном-то какие проблемы прочитать содержимое файла в переменную и отправить эту переменную в БД, как любую другую? :)
Очень жаль, что в статье почти нет фактуры. Вот не хочется ругаться, скорее всего тут действительно искреннее желание поделиться, но по факту статья выглядит совсем по-другому. На реддите часто постят спам индусские бодишопы, методом "сеошник спускает копирайтеру топик, тот пишет набор слов на заданную тему". И читая эту статью, я не могу избавиться от ощущения что она написана тем же способом. От некоторых цифр глаза на лоб лезут
80 секунд на наиболее посещаемых страницах? Это что вообще? Для того, чтобы это заметить, надо проводить специальное исследование? И с такими цифрами мы говорим о живом бизнесе, серьёзно? На этот сайт кто-то ещё ходил? Но тогда при чем здесь слово "highload"? Может быть 80 — это все-таки опечатка, и речь о 8 секундах?
3-8 секунд на страницу после оптимизации преподносится как достижение. Нет, ну я могу понять, что унутре там адов битрикс, для которого это действительно значительное достижение, на пределе возможностей. Но по современным меркам это труп, который даже не дышит. Что говорит PageSpeed про такие "достижения"?
Но ок, перейдем к самим шагам.
Шаг 1. Настройка баз данных. Ээээ. А где про саму настройку-то? что именно настроили? Этот пункт — ну реально мемасик про "profit!!!". Зачем его вообще было писать?
Шаг 2. myisam? В каком смысле myisam? Innodb — это движок по умолчанию уже не меньше 10 лет. Откуда здесь вообще взялась БД на myisam? Хотя наверное снова можно найти универсальное объяснение — битрикс. Ну ок.
Innodb. В принципе правильная рекомендация, но объяснение… "Дело в том, что пока запрос не будет выполнен, никакие другие обращения к таблице/строке будут невозможны". Вот из этой фразы за километр торчат уши копирайтера, который пишет как дорогой Леонид Ильич, по бумажке. Ну неправда же. Если бы так было, то любая БД была бы принципиально однопоточной. SELECT лочит данные в SHARED моде, то есть другие потоки вполне могут читать те же самые данные. А вот с обновлением все верно — myisam не сможет обновить таблицу, из которой идет чтение, пусть даже совсем другой строки.
"Также была произведена оптимизация работы самой базы данных InnoDB. Например, были оптимизированы параметры:" читатель уж потирает руки и ждет рифмы "розы". "Вот оно, добрались до сути" — думает он. "Сейчас будут практические рекомендации, какая конкретно настройка какой конкретно дала буст к производительности...". Ага, разбежался, наивный. Это промо-статья. Для продвижения компании на хабре. А не для тебя, читатель. Взять самую важную настройку, innodb_buffer_pool_size. По дефолту, ускоряет работу её увеличение. Но из контекста статьи можно предположить (именно что предположить, поскольку никакой конкретики в ней нет), что во-первых, основные проблемы были с памятью, а во-вторых — наш "хайлоад" проект весь лежит на одном серваке. То есть, возможно, буфер наоборот — подрезали, тем более что БД микрушечная, сотня тыщ строк. Но почему об этом не сказано, как именно была изменена настройка?
Промежуточные результаты. Не слишком впечатляют. Чтобы увидеть разницу на первых двух графиках надо очень сильно приглядываться.
Апач. Тоже в принципе правильный ход, но мотивация… "Например, Apache приходится каждый раз считывать несколько конфигурационных файлов на сервере". А кто заставляет эти файлы писать-то? И вообще включать AllowOverride? Опять же, основная проблема Апача — это mod_php, устаревший режим сопряжения с РНР. Но если запускать Апач в threaded режиме вместо prefork, и цеплять пых через тот же php-fpm, то разница практиески нивелируется. Но если фронтом стоит Энжинкс, то в Апаче действительно надобность отпадает. И очень хотелось бы всё это прочитать в статье.
Nginx. Опять это фирменное "в совокупности с перенастройкой Nginx". Какой перенастройкой-то?
Заключение. И снова графики, на которых надо с лупой что-то разбирать. Ну хоть бы красной линией отметили, где там "до" и "после". Вроде бы, БД "оптимизировали" 27 марта. Но на конечном графике там самый махровый оверлоад. Причем какой-то пик, по краям которого в целом одинаковые крылья. 24 марта на сайт начали лить трафик что ли, из-за которого сайт начал падать? А где об этом сказано? Где цифры посещаемости до и после? Или мы вот реально должны поверить, что спад нагрузки 31-го — это результат "оптимизаций", а не тупо дёрнули рубильник в адсенсе?
Если вам интересно мнение рядового читателя, то я бы рекомендовал статью переделать. Кейс действительно может быть очень интересным и полезным. Если дать фактуру, объяснения брать не с потолка, и как-то более явно отметить достижения.
Не, ну этому автору слить карму не так просто. У него много хороших публикаций.
Здесь я предположу, что он либо взялся не за свое дело, либо еще банальнее — аутсорс.
Вообще я бы не сказал что весь перевод прям совсем отвратный — тут бывало и хуже. Есть/было несколько совсем крупных ляпов, но в целом текст не выбивается из хабровского стандарта на переводы, увы, довольно низкого.
he's making it up as he goes — выдумывает на ходу.
девопс — это не "разработчик"
"хулиган" в русском не несет положительной коннотации. классический вариант будет "этим сукиным детям", ср. "Ай да Пушкин, ай да хулиган!"
whiteboarding — это "пинки под зад", серьёзно?
"Хорошими рекрутерами обычно становятся крупные компании."
Ну неужели так трудно почитать глазами свой текст и просто посмотреть, а есть ли в нём смысл? Да, у автора там опечатка, are вместо for. Но там хотя бы вся остальная грамматика на месте, и из неё можно понять, что имелось в виду. А в "переводе" уже остается просто бессмысленный висяк, вообще без всякой связи с предыдущей мыслью.
Это отсутствие смысла — бич любительских переводов. Ну почему вы никогда не читаете текст, который пишете?
Как сказал один очень умный человек, "то что одному — логичная и последовательная структура, то другому — оверинжиниринг". Все зависит от опыта.
Здесь я рекомендую смотреть на Симфони, как на проект, который пытается форсить правильные подходы, не заигрывая при этом с пользователем, как веселая Лариска, но при этом сохраняя мозг пользователя почти без необратимых повреждений.
Вообще, очень полезно прочитывать свою статью перед публикацией.
В частности, на предмет соответствия текста заявленной цели.
Я сейчас кратко изложу содержание
Начало — говнокод на инклюдах
Продолжение — попробовал битрикс (сам по себе говнокод), немножечко писал на Йии (тоже не лучший пример), своя поделка — все тот же говнокод
Прозрение — половина раздела посвящена переименованию папочки. Из "правильной архитектуры" упомянуто три слова, Twig и CRUD и тесты. При том что crud — понятие растяжимое, а покрытие тестами, как я понимаю, процентов 5. при том что внедрение тестов на говнокод действительно могло бы быть интересным кейсом для рассказать.
Решение — освоил композер и стал использовать пару готовых модулей.
В сухом остатке, если отбросить многословные экскурсы про сисадминскую вольницу, остается Твиг и композер. На статью никак не тянет.
Единственное, что можно действительно вынести из статьи — это неумение учиться на собственных ошибках. Потому что после
появление ООП в PHP, хотя последнее я просто не воспринял: зачем, когда у тебя в inc/
прямо бросается в глаза утверждение-близнец:
например DI контейнер в такой простой задаче будет перебором
С одной стороны я согласен, что сам по себе контейнер, как самоцель, будет скорее антипаттерном. Но вот нормальная архитектура, построенная на автоматическом создании объектов-сервисов и пробрасывания их в конечные объекты-потребители с помощью контейнера, как раз и решила бы проблему "связности в моей ЦМС", которая в итоге перестала бы напоминать Йии1-2 с его фреймворком, который весь лежит в одном объекте.
Ой. Это так смешно, про "условия сделки" :)
по условиям сделки разработчики скайпа оставались самостоятельной единицей
по условиям сделки разработчики вотсапа оставались самостоятельной единицей
список можно продолжать бесконечно
Другое дело, что СО — довольно кривой и бессмысленный сайт, с дебильными целями и модерацией. Так что испортить его ещё больше будет проблематично.
Устраивается на работу секретарша, её спрашивают:
— Скорость машинописи какая?
— 9000 знаков в минуту!
— Неужели можно с такой скоростью печатать?
— Конечно можно! Правда такая фигня получается...
Вот это про стаковерфлой, с его ордами индусов, которые друг другу на вопросы отвечают.
Дело в том что я стал в последнее время более-менее регулярно почитывать хабр. И обратил внимание, что качество контента ниже плинтуса. Неважно, переводного или оригинального.
И вот на этом фоне данная статья, хоть сама по себе и не представляет из себя ничего выдающегося, но хотя бы не обычный для этого ресурса адЪ. Вот именно этот факт я и захотел отметить. Как раз чтобы немного разбавить репутацию любителя набросить :) Хотя я не любитель. Просто я как тот мальчик из анекдота, пишу только когда суп пересолен.
А если говорить о переводах, то тут просто добавляется ещё один фактор риска — кроме исходно некачественного контента добавляется еще и никакое качество перевода. Но так-то, в самом по себе факте перевода никакого криминала нет.
Ну с одной стороны вы правы. Сейчас посмотрел — где-то 8-10 секунд до начала рендера на 1700 комментариев. Слава богу что улучшаторы пока не забрали у нас десктопную версию.
С другой — все-таки, 8 секунд — не 80.
С третьей — хабр в каком-то роде монополист, и люди терпят. Но будь у него более шустрые конкуренты, как это наблюдается в екомммерсе, то такие цифры очень быстро стали бы критическими.
А разве перевод — это заведомо что-то плохое?
Я извиняюсь, но задам нескромный вопрос. Какой объем информации в БД и какая посещаемость на этом сайте? Я так понимаю, что вопрос, в сущности, риторический.
А проблема битрикса в том, что с нагрузкой на динамические сайты он справляется примерно никак. Ключевое слово — динамические. Хорошо когда у тебя сказка про Хрюшу, которую можно закэшировать по самые помидоры. А когда у тебя склад и скидки по 20 критериям и ты должен продать клиенту товар ровно по той цене, которая ему обещана, и не продать тот, который уже закончился — вот тут в такой ситуации покажи мне сайт на битриксе — поговорим.
Связка "nginx+apache" действительно является пожарным решением, которое нивелирует основную проблему mod_php — висящий в памяти процесс Апача, пока медленный клиент забирает свой ответ. Энжинкс же быстренько забирает ответ в свой буфер, и спокойно отдаёт клиенту, сколько надо. Я и сам так делал в своё время, когда надо было сервер спасать, а хтаксессы чистить было некогда. Но при первой же возможности избавился от лишнего звена. Рекомендую. хтаксесс на самом деле не такой важный файл, как кажется :)
А я не могу понять, что здесь непонятного :)
Картинка — это набор байт. Или, по-другому, "данные". что нам мешает взять и записать данные в базу данных?
Ну понятно, что у поля не должна быть текстовая кодировка, но в остальном-то какие проблемы прочитать содержимое файла в переменную и отправить эту переменную в БД, как любую другую? :)
В смысле — как? Обычно, как любые другие данные. Зачем тут base64?
Удивительно мерзотная кляуза.
Типичная для автора графомания.
Зачем вообще он публикует свои художественные тексты на Хабре — загадка. Есть же proza.ru.
Очень жаль, что в статье почти нет фактуры. Вот не хочется ругаться, скорее всего тут действительно искреннее желание поделиться, но по факту статья выглядит совсем по-другому. На реддите часто постят спам индусские бодишопы, методом "сеошник спускает копирайтеру топик, тот пишет набор слов на заданную тему". И читая эту статью, я не могу избавиться от ощущения что она написана тем же способом. От некоторых цифр глаза на лоб лезут
Но ок, перейдем к самим шагам.
innodb_buffer_pool_size. По дефолту, ускоряет работу её увеличение. Но из контекста статьи можно предположить (именно что предположить, поскольку никакой конкретики в ней нет), что во-первых, основные проблемы были с памятью, а во-вторых — наш "хайлоад" проект весь лежит на одном серваке. То есть, возможно, буфер наоборот — подрезали, тем более что БД микрушечная, сотня тыщ строк. Но почему об этом не сказано, как именно была изменена настройка?AllowOverride? Опять же, основная проблема Апача — это mod_php, устаревший режим сопряжения с РНР. Но если запускать Апач в threaded режиме вместо prefork, и цеплять пых через тот же php-fpm, то разница практиески нивелируется. Но если фронтом стоит Энжинкс, то в Апаче действительно надобность отпадает. И очень хотелось бы всё это прочитать в статье.Если вам интересно мнение рядового читателя, то я бы рекомендовал статью переделать. Кейс действительно может быть очень интересным и полезным. Если дать фактуру, объяснения брать не с потолка, и как-то более явно отметить достижения.
Не, ну этому автору слить карму не так просто. У него много хороших публикаций.
Здесь я предположу, что он либо взялся не за свое дело, либо еще банальнее — аутсорс.
Вообще я бы не сказал что весь перевод прям совсем отвратный — тут бывало и хуже. Есть/было несколько совсем крупных ляпов, но в целом текст не выбивается из хабровского стандарта на переводы, увы, довольно низкого.
Ну вот да, идеальный чеклист.
Только боюсь я, тем кто зарабатывает копеечку на жизнь публикациями на Хабре, не до таких тонкостей.
Приятная статья, спасибо.
Другим промоблогам надо учиться у мейл.ру.
Реддит это не блог, а форум.
Тогда уж Лина
he's making it up as he goes — выдумывает на ходу.
девопс — это не "разработчик"
"хулиган" в русском не несет положительной коннотации. классический вариант будет "этим сукиным детям", ср. "Ай да Пушкин, ай да хулиган!"
whiteboarding — это "пинки под зад", серьёзно?
"Хорошими рекрутерами обычно становятся крупные компании."
Ну неужели так трудно почитать глазами свой текст и просто посмотреть, а есть ли в нём смысл? Да, у автора там опечатка, are вместо for. Но там хотя бы вся остальная грамматика на месте, и из неё можно понять, что имелось в виду. А в "переводе" уже остается просто бессмысленный висяк, вообще без всякой связи с предыдущей мыслью.
Это отсутствие смысла — бич любительских переводов. Ну почему вы никогда не читаете текст, который пишете?
Мутант-не мутант, но оно есть, и несет вполне определенный смысл. Который автор статьи не донес
Как сказал один очень умный человек, "то что одному — логичная и последовательная структура, то другому — оверинжиниринг". Все зависит от опыта.
Здесь я рекомендую смотреть на Симфони, как на проект, который пытается форсить правильные подходы, не заигрывая при этом с пользователем, как веселая Лариска, но при этом сохраняя мозг пользователя почти без необратимых повреждений.
Кода в статье нет.
Вообще, очень полезно прочитывать свою статью перед публикацией.
В частности, на предмет соответствия текста заявленной цели.
Я сейчас кратко изложу содержание
В сухом остатке, если отбросить многословные экскурсы про сисадминскую вольницу, остается Твиг и композер. На статью никак не тянет.
Единственное, что можно действительно вынести из статьи — это неумение учиться на собственных ошибках. Потому что после
прямо бросается в глаза утверждение-близнец:
С одной стороны я согласен, что сам по себе контейнер, как самоцель, будет скорее антипаттерном. Но вот нормальная архитектура, построенная на автоматическом создании объектов-сервисов и пробрасывания их в конечные объекты-потребители с помощью контейнера, как раз и решила бы проблему "связности в моей ЦМС", которая в итоге перестала бы напоминать Йии1-2 с его фреймворком, который весь лежит в одном объекте.
Хотелось бы больше фактуры. сейчас статья выглядит, как мемасик:
Говнокод
Говнокод
???
PROFIT!!!