MiksIr
miksir@home:~$
Мне даже интересно стало, что это я написал
))) DiMA, я думаю тебе в отпуск нужно - на землю спуститься.-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
memcached и много одновременно одинаковых запросов к нему
- Автор темы BoRay
- Дата начала
))) DiMA, я думаю тебе в отпуск нужно - на землю спуститься.
Я понимаю, никому не нравится, когда их тыкают носом в их ошибки. Люди тут же уходят на уровень личных оскорблений... естественная реакция организма - отшутиться/спрятаться за улыбкой и обматерить в ответ. Но будь добр не троллить, если сказать по существу нечего.
Вынужден остаться на своей точки зрения и еще раз ее аргументировать.
Имеется задача: есть кеш, который нужно регулярно перестраивать, со всеми вытекающими проблемами, описанными на 1й страницы топика. Бред (типичный антипаттерн программиста-новичка) заключается в том, что идет совет решения (да, оно имеет право на жизнь, все про него знают, иногда применяют и т.д.) путем НЕПРИЕМЛЕМОГО СУЖЕНИЯ сферы применения. Описанная задача не имеет ни малейшего отношения к кеширующим веб-серверам, это всего лишь узкий частный случай, довольно редко используемый в веб 2.0 (так только статику можно кешировать, а не веб-страницы). Сообщаю тебе из практики, что в 95% случаев, когда мы кешируем какие-то объекты, этим занимается исключительно php просто потому, что к веб-страницам задача не имеет ни малейшего отношения (кешируется, в основном, данные с sql или даже с самого memcache!). К сожалению, эти мелкие объекты нельзя так просто кешировать, типа в каких-то хитрых ajax запросах, иначе бы действительно можно было бы массово использовать твое предложение.
Сам по себе модуль для nginx написан грамотно и хорошо, но, к сожалению, не применим. Если у нас какой-то мелкий сайт, типа выдачи полу-статичный статей - да, метод будет отлично пригоден и тут мы можем переложить ответственность за важное решение с программиста на дядю. Но нужно понимать, что модуль nginx, как и любые готовые инструменты масштабирования - это некий чужой черный ящик, которым невозможно управлять. Если в проекте хоть что-то меняется то может оказаться, что этот черный ящик уже не применим, т.е. подобными профанскими подходами к разработке мы роем сами себе яму. Зато экономим время и не занимаемся преждевременными оптимизациями.
Следующий момент. В больших проектах имеются целые кластеры серверов с мемкешами, которые хранят млрд-трлн объектов. Это критически важная функция. Не серьезно пытаться дать управлять этой памятью какому-то модулю nginx, написанному на С дядей, будь он трижды хорош. Сотни нюансов, собственных оптимизаций, необходимость быстрой разработки и т.д.
Вынужден остаться на своей точки зрения и еще раз ее аргументировать.
Имеется задача: есть кеш, который нужно регулярно перестраивать, со всеми вытекающими проблемами, описанными на 1й страницы топика. Бред (типичный антипаттерн программиста-новичка) заключается в том, что идет совет решения (да, оно имеет право на жизнь, все про него знают, иногда применяют и т.д.) путем НЕПРИЕМЛЕМОГО СУЖЕНИЯ сферы применения. Описанная задача не имеет ни малейшего отношения к кеширующим веб-серверам, это всего лишь узкий частный случай, довольно редко используемый в веб 2.0 (так только статику можно кешировать, а не веб-страницы). Сообщаю тебе из практики, что в 95% случаев, когда мы кешируем какие-то объекты, этим занимается исключительно php просто потому, что к веб-страницам задача не имеет ни малейшего отношения (кешируется, в основном, данные с sql или даже с самого memcache!). К сожалению, эти мелкие объекты нельзя так просто кешировать, типа в каких-то хитрых ajax запросах, иначе бы действительно можно было бы массово использовать твое предложение.
Сам по себе модуль для nginx написан грамотно и хорошо, но, к сожалению, не применим. Если у нас какой-то мелкий сайт, типа выдачи полу-статичный статей - да, метод будет отлично пригоден и тут мы можем переложить ответственность за важное решение с программиста на дядю. Но нужно понимать, что модуль nginx, как и любые готовые инструменты масштабирования - это некий чужой черный ящик, которым невозможно управлять. Если в проекте хоть что-то меняется то может оказаться, что этот черный ящик уже не применим, т.е. подобными профанскими подходами к разработке мы роем сами себе яму. Зато экономим время и не занимаемся преждевременными оптимизациями.
Следующий момент. В больших проектах имеются целые кластеры серверов с мемкешами, которые хранят млрд-трлн объектов. Это критически важная функция. Не серьезно пытаться дать управлять этой памятью какому-то модулю nginx, написанному на С дядей, будь он трижды хорош. Сотни нюансов, собственных оптимизаций, необходимость быстрой разработки и т.д.
Заодно предлагаю не доверять пхп, написаного на С дядями, будь они трижды хороши. Предлагаю писать на отце всех языков — на ассемблере.
DiMA, ты впадаешь в другую крайность. Проектов «с тысячами серверов» мемкеша — единицы. И делают их — единицы. И их как раз тоже глупо обсуждать, потому что это ГРАНИЧНЫЕ случаи.
DiMA, ты впадаешь в другую крайность. Проектов «с тысячами серверов» мемкеша — единицы. И делают их — единицы. И их как раз тоже глупо обсуждать, потому что это ГРАНИЧНЫЕ случаи.
MiksIr
miksir@home:~$
Мдя... у DiMA вторая стадия хайлоада - "думаю, что все знаю и готов всех учить".
Дима, иногда следует остановиться и задуматься - может тебя не "троллят", а намекают, что тебя несет? Но, вижу, что нет, не работает.
Ладно, по делу.
1. Я ничего не "писал", я дал ссылку. Можно было подумать - зачем. Но, не работает.
2. Ссылка была дана как классический алгоритм бизи-локов, реализация которого придумана хрен знает сколько лет назад. Это что бы не изобретать велосипед с умным видом.
3. Это модуль под апач, а не под nginx. Так, к слову... как показатель - как внимательно человек вникает.
А тот бред, что про черные ящики написан - это отдельная песня. При тех масштабах, о которых ты тут поешь - именно эти черные ящики, умение понять их архитектуру, использовать под себя и заточить под свою специфику - основа всего. А о том - где и что кешировать можно, а что нельзя - это отдельная песня Вам, оно, конечно виднее.
Дима, иногда следует остановиться и задуматься - может тебя не "троллят", а намекают, что тебя несет? Но, вижу, что нет, не работает.
Ладно, по делу.
1. Я ничего не "писал", я дал ссылку. Можно было подумать - зачем. Но, не работает.
2. Ссылка была дана как классический алгоритм бизи-локов, реализация которого придумана хрен знает сколько лет назад. Это что бы не изобретать велосипед с умным видом.
3. Это модуль под апач, а не под nginx. Так, к слову... как показатель - как внимательно человек вникает.
А тот бред, что про черные ящики написан - это отдельная песня. При тех масштабах, о которых ты тут поешь - именно эти черные ящики, умение понять их архитектуру, использовать под себя и заточить под свою специфику - основа всего. А о том - где и что кешировать можно, а что нельзя - это отдельная песня
Вам, оно, конечно виднее.
Я всегда с удовольствием читаю PHP и хайлоад - но PHP не для нагружаемых проектов. Все так увлеклись костылями,.забыв о традиционном программирование. PHP - вообще не для этих целей. Что есть на PHP реквист - это - каждый раз загрузить интерпритатор, далее подключить файлы, далее - скомпилировать, далее.... , далее загрузить из БД данные, обработать и в конце - умереть.. Не слишком ли жирно и не гуманно?
Имеем сервер - 32 ГБ ОЗУ два 4-х ядерного процессора, этого хватит, что бы обеспечить стабильную работу 25-40% динамических данных в каком-нибудь вконтактике. Есть fcgi софтина (именно правильная fcgi, fcgi в PHP нет, а то и собственная Baida) софтина, которая хранит в ОЗУ данные и работает постоянно, реквист обрабатывая за считанные наносекнды, изредка ложа новые данные из ОЗУ в бд для сохранности, кроме того, лезет в БД она тоже редко, если только не найдет нужных данных. СУБД - рассчитано для длительного хранения данных, а не для того, что бы сохранить и тут же выполнить селект по следующему реквисту.
У нас fcgi ПО, задача которой - обрабатывать реквисты, выдавая HTML код с ее минимальной обработкой (и вправду, вот есть мессаги вконтактике между двумя юзерами - задача - вытащить кто, кому отправил по индексам, работая с ОЗУ, а если юзера не было давно - взять старые данные из бд), при этом по технологиям типа SSI идет баланс нагрузок бекэндов на фронэндах, так вот - пришла мессага, положил в ОЗУ, там и оставил, юзер ушел (нет активности n-времени) - слил его новые мессаги в БД и очистил кучу в ОЗУ давая место другим. Вся проблема подобного хайлоада - это применение не тех технологий.
Я еще ни разу не видел чего-та очень нужного, работающего на bash
Я не вкоем не хочу кого-то здесь обидеть, но 100 серверов, это примерно 200-300 Ггц вычислительных мощностей (количество ядер не учитвывал), от 800 (и выше) гигабайт высокопроизводительной ОЗУ, сотни терабайт дисковых пространств. 200 тыс. запросов к бд в скунду
, а также - 50 кВт в час + охлаждение + сетевое оборудование + поддержка 100 серверов, охрана, упсы и т.п.
Имеем сервер - 32 ГБ ОЗУ два 4-х ядерного процессора, этого хватит, что бы обеспечить стабильную работу 25-40% динамических данных в каком-нибудь вконтактике. Есть fcgi софтина (именно правильная fcgi, fcgi в PHP нет, а то и собственная Baida) софтина, которая хранит в ОЗУ данные и работает постоянно, реквист обрабатывая за считанные наносекнды, изредка ложа новые данные из ОЗУ в бд для сохранности, кроме того, лезет в БД она тоже редко, если только не найдет нужных данных. СУБД - рассчитано для длительного хранения данных, а не для того, что бы сохранить и тут же выполнить селект по следующему реквисту.
У нас fcgi ПО, задача которой - обрабатывать реквисты, выдавая HTML код с ее минимальной обработкой (и вправду, вот есть мессаги вконтактике между двумя юзерами - задача - вытащить кто, кому отправил по индексам, работая с ОЗУ, а если юзера не было давно - взять старые данные из бд), при этом по технологиям типа SSI идет баланс нагрузок бекэндов на фронэндах, так вот - пришла мессага, положил в ОЗУ, там и оставил, юзер ушел (нет активности n-времени) - слил его новые мессаги в БД и очистил кучу в ОЗУ давая место другим. Вся проблема подобного хайлоада - это применение не тех технологий.
Я еще ни разу не видел чего-та очень нужного, работающего на bash
Я не вкоем не хочу кого-то здесь обидеть, но 100 серверов, это примерно 200-300 Ггц вычислительных мощностей (количество ядер не учитвывал), от 800 (и выше) гигабайт высокопроизводительной ОЗУ, сотни терабайт дисковых пространств. 200 тыс. запросов к бд в скунду
, а также - 50 кВт в час + охлаждение + сетевое оборудование + поддержка 100 серверов, охрана, упсы и т.п.MiksIr
miksir@home:~$
У "правильных" софтин есть один огромный минус - сложность (читай - дороговизна) разработки и поддержки. По-этому и получается сборная солянка - используется "правильный" готовый софт, который может где-то допиливается, но очень вдумчиво, ибо потерять возможность апгрейда этого софта - очень дорого. А PHP или иной интерпретируемый язык задает как бы логику "склеивания" всего этого.
Активист, никто эту байку не придумывал. Как только натыкаешься на более-менее сложную инфраструктуру, понимаешь, что готовых решений там не бывает,и на пхп «склейка» обходится очень рентабельно, просто потому что его легко поддерживать и расширять. (про то, что можно испортить что угодно, не будем говорить, это вполне очевидно)
Хотя еще есть подход того же SAP, например, это когда к вам на предприятие приезжает бригада специалистов SAP-а, и перестраивает ваши производственные процессы, что бы они вписались в логику их софта.
Хотя еще есть подход того же SAP, например, это когда к вам на предприятие приезжает бригада специалистов SAP-а, и перестраивает ваши производственные процессы, что бы они вписались в логику их софта.
HraKK
Я об этом докладывал на мастер-классе, как раз на примере, как грамотно закешировать главную страницу, применяя классы MemcacheLock + Cache (они позволяют снизить число строк кода до мизера), на что получил упрек: "зачем такие советы, я лучше воспользуюсь nginx модулем"
Потом в конце уже был более расширенный пример, включая проблемы А, Б, В, Г (минут на 40). Статьи писать боюсь - набегут чайники, затроллят до смерти. Я еще из этой темы не ушел - уже пипец наступил .-)
флоппик
> ты впадаешь в другую крайность
Стараюсь не впадать. Ты думаешь, я не понимаю, что не у всех есть миллионы юзеров в сутки? 80% информации, что я рассказал, касаются новых паттернов оперирования данными, которые НУЖНО применять даже в мелких проектах. Ты читал, что я писал выше? Типичному программисту, который сделал "наикрутейшую оптимизацию" в пункте А, в голову не придет, что тем самым он наплодил себе БАГОВ. Либо не делайте вообще кеширования - будет медленно, но без багов, либо делайте - но с умом и с минимумом кода. Ну, причем тут размер проекта? Да, в мелком проекте эти баги будут редкими (смотря, что за объект и частота использования). Но это все равно что писать/читать данные из файла, не блокируя его, что ты и советуешь делать. Да, в 99,99% хитах все будет окей. Но раз в неделю будут происходить загадочные зависания или потеря данных. В крупном проекте этот баг вылезет мгновенно и проект рухнет за 2 минуты
MiksIr
> иногда следует остановиться и задуматься - может тебя не "троллят", а намекают, что тебя несет?
1. К сожалению, троллят только профаны. Профессионалов в теме знаю только человек 10, к чьему мнению я бы прислушался. Ну, расскажи же, что ты интересного сделал, чем ты можешь поделиться с народом и т.д.
2. Я не пытаюсь никого учить. Это типичное хамство от профанов (некоторые еще в велосипедосроении обвиняют), которые ничего не умеют, но хотели бы заявить. В данной теме я указал на недопустимость поверхностного подхода к этой задаче. Если бы ты промолчал, я бы не пошел к тебе с советами. Написал глупость - вот и ответ. В чем проблема?
3. Нравится профанам или не нравится, но других публичных решений нет. Я просто излагаю то, что:
а) уже реально работает лично у меня
б) как устроены другие КРУПНЫЕ проекты, в 50 раз больше (сведений, что там что-то по другому, ни у кого нет, вернее, у большинства вообще никаких сведений нет).
4. Хоть ты тресни, но ничего не сделаешь против этих моих железных аргументов. Если кто-то из создателей крупных проектов публично обрисует другую картину, то я
а) узнаю для себя ценнейшую информацию и скорректирую свою точку зрения
б) смогу новые компоненты своего проекта реализовать по новому.
Жаль только, что этого не будет.
5. Тема начата про узкий момент - как закешировать что-то, снизив нагрузку. Может пора прекратить троллинг по всевозможно широким темам?
О да, про апач я страшнейше облажался! =) Просто апач - это ругательное слово, не ждал, что его кто-то будет употреблять.
Про черный ящик. Ты хочешь это обсудить? Я часто слышу, что многие собираются делать масштабирование за счет готового хранилища, а не собственной головы. Считаю это большой глупостью.
Активист
1. Наши сервера не имеют 32 гигов. Только 6.
2. Наши сервера имеют дебильно медленные жесткие диски. Обычные юзерские sata винчи, которые еще и сыпятся регулярно. Про рейд даже не заикайтесь .-)
3. Если взять фейсбук или контакт, то их 1 сервер держит примерно 10.000 уников в сутки. У нас 1 сервер держит 12.500 юзеров.
4. Нашему проекту менее полугода. Еще не успели оптимизировать или устаканить все, в отличии от старых проектов.
Короче, сервера - полное говно. Зато они нам обходятся бесплатно и в почти любом нужном количестве. На некотором этапе роста придется переезжать на приличные сервера, за свои деньги.
> Что есть на PHP реквист - это - каждый раз загрузить интерпритатор, далее подключить файлы, далее - скомпилировать,
> далее.... , далее загрузить из БД данные, обработать и в конце - умереть.. Не слишком ли жирно и не гуманно?
Под nginx есть замечательные модули. Например nginx может сам, без пхп:
1) принять постом от юзера некие данные и кинуть в очередь на обработку
2) выдать json ответом некий ключ из мемекеша, где заранее заботливо сложен юзерский объект (к вопросу о кешировании, кстати).
С помощью этого паттерна можно сделать уйму веб-функционала без пхп.
Можно еще демонов на пхп писать... только не кидайтесь рвотными пакетиками за такие костыли У нас демонов пока нет, хотя подумываем. Наши псевдодемоны - это кластер крон-серверов, в реалтайме обрабатывающий 70% нагрузки.
Я об этом докладывал на мастер-классе, как раз на примере, как грамотно закешировать главную страницу, применяя классы MemcacheLock + Cache (они позволяют снизить число строк кода до мизера), на что получил упрек: "зачем такие советы, я лучше воспользуюсь nginx модулем"
Потом в конце уже был более расширенный пример, включая проблемы А, Б, В, Г (минут на 40). Статьи писать боюсь - набегут чайники, затроллят до смерти. Я еще из этой темы не ушел - уже пипец наступил .-)флоппик
> ты впадаешь в другую крайность
Стараюсь не впадать. Ты думаешь, я не понимаю, что не у всех есть миллионы юзеров в сутки? 80% информации, что я рассказал, касаются новых паттернов оперирования данными, которые НУЖНО применять даже в мелких проектах. Ты читал, что я писал выше? Типичному программисту, который сделал "наикрутейшую оптимизацию" в пункте А, в голову не придет, что тем самым он наплодил себе БАГОВ. Либо не делайте вообще кеширования - будет медленно, но без багов, либо делайте - но с умом и с минимумом кода. Ну, причем тут размер проекта? Да, в мелком проекте эти баги будут редкими (смотря, что за объект и частота использования). Но это все равно что писать/читать данные из файла, не блокируя его, что ты и советуешь делать. Да, в 99,99% хитах все будет окей. Но раз в неделю будут происходить загадочные зависания или потеря данных. В крупном проекте этот баг вылезет мгновенно и проект рухнет за 2 минуты
MiksIr
> иногда следует остановиться и задуматься - может тебя не "троллят", а намекают, что тебя несет?
1. К сожалению, троллят только профаны. Профессионалов в теме знаю только человек 10, к чьему мнению я бы прислушался. Ну, расскажи же, что ты интересного сделал, чем ты можешь поделиться с народом и т.д.
2. Я не пытаюсь никого учить. Это типичное хамство от профанов (некоторые еще в велосипедосроении обвиняют), которые ничего не умеют, но хотели бы заявить. В данной теме я указал на недопустимость поверхностного подхода к этой задаче. Если бы ты промолчал, я бы не пошел к тебе с советами. Написал глупость - вот и ответ. В чем проблема?
3. Нравится профанам или не нравится, но других публичных решений нет. Я просто излагаю то, что:
а) уже реально работает лично у меня
б) как устроены другие КРУПНЫЕ проекты, в 50 раз больше (сведений, что там что-то по другому, ни у кого нет, вернее, у большинства вообще никаких сведений нет).
4. Хоть ты тресни, но ничего не сделаешь против этих моих железных аргументов. Если кто-то из создателей крупных проектов публично обрисует другую картину, то я
а) узнаю для себя ценнейшую информацию и скорректирую свою точку зрения
б) смогу новые компоненты своего проекта реализовать по новому.
Жаль только, что этого не будет.
5. Тема начата про узкий момент - как закешировать что-то, снизив нагрузку. Может пора прекратить троллинг по всевозможно широким темам?
О да, про апач я страшнейше облажался! =) Просто апач - это ругательное слово, не ждал, что его кто-то будет употреблять.
Про черный ящик. Ты хочешь это обсудить? Я часто слышу, что многие собираются делать масштабирование за счет готового хранилища, а не собственной головы. Считаю это большой глупостью.
Активист
1. Наши сервера не имеют 32 гигов. Только 6.
2. Наши сервера имеют дебильно медленные жесткие диски. Обычные юзерские sata винчи, которые еще и сыпятся регулярно. Про рейд даже не заикайтесь .-)
3. Если взять фейсбук или контакт, то их 1 сервер держит примерно 10.000 уников в сутки. У нас 1 сервер держит 12.500 юзеров.
4. Нашему проекту менее полугода. Еще не успели оптимизировать или устаканить все, в отличии от старых проектов.
Короче, сервера - полное говно. Зато они нам обходятся бесплатно и в почти любом нужном количестве. На некотором этапе роста придется переезжать на приличные сервера, за свои деньги.
> Что есть на PHP реквист - это - каждый раз загрузить интерпритатор, далее подключить файлы, далее - скомпилировать,
> далее.... , далее загрузить из БД данные, обработать и в конце - умереть.. Не слишком ли жирно и не гуманно?
Под nginx есть замечательные модули. Например nginx может сам, без пхп:
1) принять постом от юзера некие данные и кинуть в очередь на обработку
2) выдать json ответом некий ключ из мемекеша, где заранее заботливо сложен юзерский объект (к вопросу о кешировании, кстати).
С помощью этого паттерна можно сделать уйму веб-функционала без пхп.
Можно еще демонов на пхп писать... только не кидайтесь рвотными пакетиками за такие костыли
У нас демонов пока нет, хотя подумываем. Наши псевдодемоны - это кластер крон-серверов, в реалтайме обрабатывающий 70% нагрузки.
Если ты внимательно читал, я вообще в дискуссии с технической стороны не принимал участия, т.к. не считаю себя компетентным в вопросах веб-хайлоада.
Я писал. Не хайлоад, конечно, но php + либевент, написанный за неделю на коленке, просто для proof of concept, обслуживающий в 4 потока около сотни датчиков, посылающих около килобайта данных раза два в минуту кушал суммарно около 10 мегабайт памяти (там конечно зашаренную память нужно учесть, но не знаю в какую сторону ее считать) кушая меньше 3% проца от обычного двухядерного десктопного ДуалКора (даже не коре2дуо) и висел месяцами. — основной проблемой было то, что иногда из-за странного поведения датчиков дохли обслуживающие процессы, но это вполне решаемо, наверно. В итоге, насколько я знаю, он так и был оставлен для работы, т.к. потреблял около 10% изначально планируемых мощностей )Можно еще демонов на пхп писать... только не кидайтесь рвотными пакетиками за такие костыли
флоппик
Я сам пишу на PHP уже пять лет.
1. Хорошо писать потому что там не нужно думать - там есть все - прочитай мануал и все.
2. Не нужно долго учиться - значит с кадрами проще (Евгений Попов пошел дальше).
3. Простота - написал строчку - F5 и все.
Но так же:
1. В PHP крайне низкое количество отличных кадров (все из-за того ,что есть люди типа Евгения Попова).
2. После нескольких лет только PHP - программист превращается в зомби, ибо он вообще забывает про ОЗУ, процессор и алгоритмы.
3. Человек, который начал программировать с PHP - никогда не станет тру программистом (все из-за например этого"1" == 1), нужны обратно.
4. PHP программист пугается при виде "1 << 2" или "2 & 1", а при виде шеснадцатиричных строк типа "0xEA" у PHP программиста начинается судорога, бинарное хранение данных - это вообще что-то страшное )))
Вот и сводится работа ПХП программера - ложить в БД, забирать из БД, валидировать, etc. Написать что-то простейшее (например пятнашки) - не возможно, а все потому что матан не учили.
Как только программист в силу экономической выгоды и личного профита начинает писать на PHP он не только не развивается как программист, а деградирует в СЕО, менеджеры, в лучшем случае в начальника отдела, тим лидера, а если повезет - начинает бизнес в другой сферы, ибо профита хочется (сужу по себе).
> Как только натыкаешься на более-менее сложную инфраструктуру
Правильнее так - "Как только натыкаешься на более-менее сложную инфраструктуру - понимаешь, нех..я я не программист, а кодер - расти и расти еще)))
А DiMA молодец, написать что-то сложное и работающее в кластерах на PHP - крайне сложно и заслуживает уважения.
ЗЫ - Спам в виде "Вас оценили на миллион" - достал.
Я сам пишу на PHP уже пять лет.
1. Хорошо писать потому что там не нужно думать - там есть все - прочитай мануал и все.
2. Не нужно долго учиться - значит с кадрами проще (Евгений Попов пошел дальше).
3. Простота - написал строчку - F5 и все.
Но так же:
1. В PHP крайне низкое количество отличных кадров (все из-за того ,что есть люди типа Евгения Попова).
2. После нескольких лет только PHP - программист превращается в зомби, ибо он вообще забывает про ОЗУ, процессор и алгоритмы.
3. Человек, который начал программировать с PHP - никогда не станет тру программистом (все из-за например этого"1" == 1), нужны обратно.
4. PHP программист пугается при виде "1 << 2" или "2 & 1", а при виде шеснадцатиричных строк типа "0xEA" у PHP программиста начинается судорога, бинарное хранение данных - это вообще что-то страшное )))
Вот и сводится работа ПХП программера - ложить в БД, забирать из БД, валидировать, etc. Написать что-то простейшее (например пятнашки) - не возможно, а все потому что матан не учили.
Как только программист в силу экономической выгоды и личного профита начинает писать на PHP он не только не развивается как программист, а деградирует в СЕО, менеджеры, в лучшем случае в начальника отдела, тим лидера, а если повезет - начинает бизнес в другой сферы, ибо профита хочется (сужу по себе).
> Как только натыкаешься на более-менее сложную инфраструктуру
Правильнее так - "Как только натыкаешься на более-менее сложную инфраструктуру - понимаешь, нех..я я не программист, а кодер - расти и расти еще
)))А DiMA молодец, написать что-то сложное и работающее в кластерах на PHP - крайне сложно и заслуживает уважения.
ЗЫ - Спам в виде "Вас оценили на миллион" - достал.
MiksIr
miksir@home:~$
> Если бы ты промолчал, я бы не пошел к тебе с советами. Написал глупость - вот и ответ.
Дурак дураком. Нет, я не перехожу на оскорбления, я просто говорю что думаю
Да, извини, было глупостью показать алгоритм, который придумали много лет назад такому местному гению. Я, правда, так и не понял, где я сказал глупость, а ты тщательно это скрываешь. Это так похвально с твоей стороны!
Говорливый какой, а... сразу вспомнил, почему перестал ходить на всякие "хайлоад" конференции и мастер-классы - там тоже строят как можно более сложные словесные конструкции дабы сказать очевидное
> Я часто слышу, что многие собираются делать масштабирование за счет готового хранилища, а не собственной головы. Считаю это большой глупостью.
Ага, это специфика русского хайлоада. Денег мало, рабочей силы много, вот и придумывают всякие "системы распределения", тогда как вполне хватило полки разведенной по фиберу
Я слышал, в СУПе даже свою файловую систему написали =)
Дурак дураком. Нет, я не перехожу на оскорбления, я просто говорю что думаю
Да, извини, было глупостью показать алгоритм, который придумали много лет назад такому местному гению. Я, правда, так и не понял, где я сказал глупость, а ты тщательно это скрываешь. Это так похвально с твоей стороны!
Говорливый какой, а... сразу вспомнил, почему перестал ходить на всякие "хайлоад" конференции и мастер-классы - там тоже строят как можно более сложные словесные конструкции дабы сказать очевидное
> Я часто слышу, что многие собираются делать масштабирование за счет готового хранилища, а не собственной головы. Считаю это большой глупостью.
Ага, это специфика русского хайлоада. Денег мало, рабочей силы много, вот и придумывают всякие "системы распределения", тогда как вполне хватило полки разведенной по фиберу
Я слышал, в СУПе даже свою файловую систему написали =)
оффтоп, конечно, но:
за это и люблю европейцев, которые пишут о том, что знают или узнали, без оглядки на толпу идиотов с тухлыми помидорами. Считаю, что мнение полутора человек, которым материал принесет пользу после их часовых блужданий по гуглу, дороже толпы имбецилов.
MiksIr
miksir@home:~$
> Тема начата про узкий момент - как закешировать что-то, снизив нагрузку.
Тема, кстати, начата была совсем про другое. И человеку там было достаточно простого ответа было. И совсем не нужно рассказывать как корабли бороздят просторы хайлоада =)
А то, что ты решил поумничать и сделать из мухи - слона - это никто не виноват =)
Тема, кстати, начата была совсем про другое. И человеку там было достаточно простого ответа было. И совсем не нужно рассказывать как корабли бороздят просторы хайлоада =)
А то, что ты решил поумничать и сделать из мухи - слона - это никто не виноват =)
... А Вы Можете Познать Эту Науку Всего За 22 Часа И 33 Минуты?
MiksIr
miksir@home:~$
> Если кто-то из создателей крупных проектов публично обрисует другую картину
Они, вообще, стараются как раз кешировать конечную статику. Ибо кеш между фронт и бек дает во много больше профита, чем кеш между бек и базой. Ибо бек прожорлив.
Но у вас 95%... куда нам, у которых линейка короткая
Они, вообще, стараются как раз кешировать конечную статику. Ибо кеш между фронт и бек дает во много больше профита, чем кеш между бек и базой. Ибо бек прожорлив.
Но у вас 95%... куда нам, у которых линейка короткая
zerkms
Я как-то слушал чуваков с фейсбука (что-то там про компилятор для PHP), они долго говорили - мол, изначально сделали на PHP, т.к. (тут слова флоппика и MiksIr' про дорогих и диких сишников), но поняли - что сцуко ступили, но жопа оказалась в том, что масштабировать проект они могли лишь только добавлением оборудования - а значит - трафик рос, киловаты тоже, вот и получилась так, что дешевле было переписать PHP и впилить туда компилятор в си ))))
Я как-то слушал чуваков с фейсбука (что-то там про компилятор для PHP), они долго говорили - мол, изначально сделали на PHP, т.к. (тут слова флоппика и MiksIr' про дорогих и диких сишников), но поняли - что сцуко ступили, но жопа оказалась в том, что масштабировать проект они могли лишь только добавлением оборудования - а значит - трафик рос, киловаты тоже, вот и получилась так, что дешевле было переписать PHP и впилить туда компилятор в си ))))