Comments 29
Вы меня извините, но что первая часть, что вторая - какая-то дичь
у всех пэхэпэшников так искусно и аргументировано получается выражать свое мнение?
Пхпшники опасные люди. У меня был сайт на друпале(пхп) 100 лет назад, так вот там 1000+ запросов к бд для генерации 1 странички было нормой, никаких оптимизаций не требовалось.
Так что когда я увидел в статье что всего 300 человек могут нагнуть гигантский современный сервер просто делая по 300 запросов к бд я немного не понял а как.
Ну смотря что за запросы. Если все эти 300 запросов написаны с помощью 1 места то тут и на пхп все так же легло бы. Но про современный веб поддерживаю чуть больше чем полностью. Это мягко говоря....
Так что когда я увидел в статье что всего 300 человек могут нагнуть гигантский современный сервер просто делая по 300 запросов к бд я немного не понял а как.
Очень просто, пишем что-то в виде select * from very_big_table_1 right join very_big_table_2 .... right join very_big_table_N и потом в соей софтине в цикле ищем единственную нужную нам строчку. Profit.
Меня зовут Женя, сейчас я работаю разработчиком в Google.
Во-первых, никогда не делать findOne в цикле по данным, количество которых может динамически расти. Это классическая ошибка, которую мы просто проморгали.
Судя по тексту вы проморгали все классические ошибки, интересно только одно как вы собес в гугл проходили.
Судя по тексту вы проморгали все классические ошибки, интересно только одно как вы собес в гугл проходили.
Так да, это очевидно. Я ещё к первой его статье написал что он обманывает про опыт, про 9 лет в разработке, про Google то понятное дело 10000% враньё, ну может 1 год джуном отработал в реале и это первый проект с нуля.
Не все, на самом деле :) В статье я поделился самыми крупными факапами, кому-то это точно будет полезно.
Все эти факапы мы очень быстро решили за несколько дней и первый запуск прошел для нас с большим успехом.
Проект большой, его писало много людей на протяжении многих месяцев, я не мог физически уследить за всем. Прошу понять)
Ожидаемо, что когда делишься факапами — это обязательно привлечёт критику. Ну что ж, я знал на что иду)
Если у вас нигде никогда не бывает факапов, даже самых элементарных, то я вам завидую белой завистью!
так в гугле знают что вы у них работаете то @markelov69@tot0ro
Факапы бывают но не в элементарных вещах, вроде мы ждали большой трафик купив рекламу но банально забыли кэш добавить, и написали запросы к бд в цикле. Так могут сделать джуны или мидлы но поверить что так можно сделать будучи разработчиком с 9 лет опыта
Интересно что же вы там тестировали тогда.
Все эти факапы мы очень быстро решили за несколько дней и первый запуск прошел для нас с большим успехом.
Проект большой, его писало много людей на протяжении многих месяцев
Всё прекрасно в этих высказываниях... Много людей, много месяцев чего-то по ctrl-c/ctrl-v делали, но выяснилось, что они делали что-то не так в момент запуска в прод.
Статические ресурсы не кэшировались. Примерно половина всех запросов приходилась на статику, и Next.js каждый раз заново оптимизировал одни и те же изображения для каждого пользователя — опять же, серьёзная нагрузка на процессор. Более подробно про кэширование статики я писал выше.
Ну ёшкин кот. Базовые факапы. Если делают обработку/генерацию новой статики из референсной, то сразу же делают кеширование и механизмы обновления.
"Защита от DDOS" - вкратце как делали? А то как-то мимоходом, обыденно написано.
Слушай, статью про мини‑приложения реально интересно читать, но ты её так завалил жаргоном, что народ будет ломать голову над каждым термином. Объясни N+1 проблему как то, что на каждую связанную запись уходит отдельный запрос и всё начинает тормозить. Вместо «увеличили RPS в 10 раз» скажи, что разбили базу на шарды, подняли кластеры и RPS вырос с 500 до 5000 запросов в секунду. Мониторинг через Grafana представь как панель приборов в машине, где видишь температуру сервера и обороты запросов и сразу понимаешь, когда нужно вмешаться. Разбей статью на разделы масштабирования, мониторинга и интеграций, в каждом упомяни инструменты и ключевые метрики, чтобы не пришлось скроллить в поисках сути. И не забывай, кому ты пишешь: новичку нужны подробные объяснения, профи ждут короткие шпаргалки без лишних англицизмов. Тогда текст станет понятнее и реально поможет читателю разобраться.
Так а чем и как вы делали нагрузочное тестирование, если реально у вас под нагрузкой всё так посыпалось?
Что вы использовали для привличения стольких юзеров одномоментно?
Под работой в гугле автор подразумевает вбивание поисковых запросов для получения решения? То, что мини приложение в телеграме не стоит писать на нексте, поймет даже джун из конторы в златоусте
Как же рад читать такие тексты, когда молодняк ведётся на маркетинг от Некста,Неста,Монго и прочей хипстоты. А потом мне как консультанту с рейтом 1К EUR/day всю эту пародию на проекты приходится оживлять. Продолжайте, не останавливайтесь. А по теме - за getById в цикле мне хватило одного леща от коллеги на ревью 20 лет назад, на втором или третьем месяце работы. А тут "7 лет" :-)
Docker compose и production просто без комментариев 😂😂😂😂😂
Как джуны прод сломали.
Ваше приложение- это тотализатор типа ставок на футбол онлайн?
как много "злых" комментов.
Это печально.
Все совершают ошибки, такие статьи помогают их избегать.
Статья интересная, спасибо за неё!
Спасибо большое за поддержку!
Я понимаю такую реакцию, многие ошибки действительно элементарные, и у людей подгорает когда они видят, что я работаю в Гугле, у них эти две вещи совмещаются и начинаются сомнения в моей компетенции))
У проекта широкий контекст, который в статье сложно раскрыть: его делало много людей, много месяцев, там много функционала, и я не писал лично все эти вещи, и даже не я в основном их ревьювил, я был в роли Fractional CTO на этом проекте и делал так, чтобы выпуск случился, и чтобы всё работало.
Но, опять же, прекрасно понимаю всю критику, люди думают, что я рассказал про проект, который сам написал от начала до конца и что все вопросы надо предъявлять мне, потому что кому ещё? Тут же нет контактов тех разрабов, кто конкретно написал findOne в цикле)) Это в целом логично.
Так же в статье самые крупные факапы, тут нет самых крупных крутых решений, которых было много на самом деле, но какой смысл про них рассказывать. Как по мне, ошибки гораздо ценнее. Если мы их сделали, то и другие тоже могут сделать и скорее всего сделают. Ведь ошибки эти часто типовые.
В любом случае, многим это точно будет полезно и многие смогут избежать таких же ошибок. Видно, что такой контент людям интересен. Эту статью уже больше 40 человек добавили в закладки, прошлую - больше 50.
Я работаю в НТ и часто встречаю "простые" ошибки даже у крутых разработчиков.
Отсутствие кэширования, запрос в цикле..
Что уж говорить про мои собственные ошибки :)
=============
Простые ошибки хороши тем, что ты их делаешь только один раз, и напоровшись единожды больше их не повторяешь.
Но то, что комментатор в интернете про эту ошибку уже хорошо знает (напоровшись сам или прочитав яркую статью - типа вашей, кстати) - так вот, это не значит, что он сам никогда не совершал ДРУГУЮ простую ошибку.
PS А может и не совершал. Бывают крутые супервнимательные люди. Честь им и хвала!
Жаль, что я не такой.
Будете ещё НТ делать - приходите к нам, в @QA_Load - тусовка НТшников в телеге. Если понадобится - поможем с анализом.
У нас тепло, ошибки помогают найти а не ищут в них повода повыпендриваться осуждением
проф.деформация - мы видим только код с ошибками, а значит не видим в нём ничего "необычно-плохого".
Так сказать, "ошибка невыжившего", ахаха :)
как много "злых" комментов
Все совершают ошибки, такие статьи помогают их избегать.
Да, вы абсолютно правы. Но есть одно но, вот оно:
Меня зовут Женя, сейчас я работаю разработчиком в Google. В стартапах был в роли CTO более 4 лет, а всего в IT — уже больше 9 лет, преимущественно в крупных компаниях и в области веб-разработки.
Если бы в статье вот этого бы не было, а всё ограничилось бы, чем-то типо "Меня зовут Женя, я разработчик, и хочу поделиться с вами моим опытом", то не бы "злых" комментов.
100K юзеров за 3 дня — что сломалось после релиза