Результаты поиска по запросу «

фронтэнд бэкэнд

»

Запрос:
Создатель поста:
Теги (через запятую):



пидоры помогите программирование geek web 

Здравствуйте, пидоры! Ищу себе в напарники начинающего фронт-эндера

Сам я -- начинающая бэкэнд (Java, если интересно. Прямиком сервлеты) макака. У которой нет желания даже трогать хтмл и CSS. А проекты делать надо.

Предлагаю тебе, этакое дружеское соглашение: Я -- тебе, ты -- мне. поможешь сделать мне простенький фронт -- я сделаю тебе бакенд по твоему дизайну. Это поможет нам обоим сделать хоть какой-то проект для портфолио и подстегнёт мою ленивую задницу таки делать что-то, ибо одному пиздец лениво.

Если интересно -- пиши в коментах, надеюсь, сработаемся.

пидоры помогите,реактор помоги,программирование,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,web
Развернуть

Отличный комментарий!

Могу поработать вашим менеджером. Я вам назначаю нереальные сроки и задания, а вы мне готовый проект.

it-юмор geek смешные картинки it юмор Прикольные картинки 

The 4 types of IT guys,it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,смешные картинки,фото приколы,it humor,geek,funny pictures,it юмор,Прикольные картинки
Развернуть

Отличный комментарий!

Вот они, слева направо, бэкэнд, фронтэнд, сисадмин, девопс
SUPRIMEkairSUPRIMEkair12.09.202416:30ссылка
+58.6

it-юмор geek 

frout-end DEVELOPER,it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор

Развернуть

админские истории story 

Расскажу о вчерашних моих изысканиях.

Предыстория: На мудакторе есть один фронтэнд и куча бэкэндов. Все запросы идут на фронтэнд (где стоит nginx), там на сервере большой кэш картинок. То, что нет в кэше картинок и хтмл-страницы отправляются на один из бэкэндов.
Симптомы: время от времени весь nginx подвисает на 1-3 секунды.
Проблема: nginx читает с жёсткого диска данные и из-за сильной пиковой нагрузки на диск его блокирует на время чтения. Вот пример strace:
20:38:49.834933 open("/mnt/ssd/joyreactor/d4/9c/c2a4cb245d73e4c6b348ad8f73769cd4", O_RDONLY|O_NONBLOCK) = 2351
...snip...
20:38:51.883163 pread(2351, "E\244\232\241"..., 32768, 4194650) = 32768
20:39:05.764386 --- SIGALRM (Alarm clock) @ 0 (0) ---

Можно видеть,что файл открывается с флагом O_NONBLOCK - то есть, чтение должно быть не блокирующее. И при запуске этого неблокирующего чтения, тред блокируется на 15 секунд - с 20:38:51 до 20:39:05

Лезу в поиск. Нахожу, что "не блокирующий" в терминах линукса вполне может быть заблокирован на любое количество времени. Он не блокируется от всяких локов. А от сильной нагрузки на хард - вполне себе блокируется. Но есть асинхронное i/o (AIO). Это ахуенно продвинутая вещь и была реализована в линуксе пару лет назад! Позволяет делать запросы к диску полностью без блокировок. Но при этом не используются никакие дисковые кэши. То есть, надо в программе реализовывать всю дисковую подсистему, если хочешь работать с этим AIO. Заебись! Но нахуй такое нужно? Всё просто - эту систему реализовывали прогеры из IBM и Oracle. Они её делали для СУБД. А в СУБД итак дисковая подсистема своя написана и они на хард пишут напрямую.

А теперь самое интересное - во FreeBSD эта фича была реализована по-нормальному с кэшами в версии 4.3. Эта версия была выпущена 20 Апреля 2001 года... и нафиг я 7 лет назад с бзди пересаживался на линукс?!
Развернуть

админские истории story 

Буду писать тут интересные случае из работы.

Для начала - почему вчера весь день тормозил реактор. Уже давно основной фронтэнд сдыхал. На нём же обрабатывались картинок и он не справлялся с отдачей картинок на скорости 2Гбит и обработкой их. Поэтому я начал потихоньку обработку картинок переносить в другое место.

И вдруг произошло что-то. Симптомы:
1) на сата дисках чтение 5Mb/s
2) на ссд диске запись только 0.5Mb/s. Хотя должна быть те же 5Mb/s, ибо всё что читается с сата потом сразу кладётся в кэш ссд.
3) запросы время от времени подвисают на 5-10-15 секунд. Причём в них нет никакого криминала - обычная отдача малоиспользующейся картинки размеров в 500Кб.

Начал грешить на nginx - что он почему-то не записывает в кэш то, что отдаёт бэкэнд. Долго мучался - ничего не смог выяснить. Решил раньше времени переносить на новый сервер бэкэнд - должно хотя бы распределить нагрузку.

Во время rsync понял в чём проблема была - все картинки у меня складываются в одну директорию. И теперь она выглядит так:
drwxrwxrwx 2 root root 59M Jan 30 19:58 pics
Можно заметить, что размер директории - 59Мб. Похоже из-за возросшей нагрузки она вытеснялась из файлового кэша и очередной запрос на 500Кб хотел открыть эту директорию, что заставляло его читать все 59Мб и тормозить всю систему.
Развернуть

тигр проект 

, Проект, на который хватило бюджета,тигр,проект
Развернуть

it-юмор geek 

it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор
Развернуть

админские истории 

Давненько я не писал сюда... так всё хорошо было...

Всё началось 31 октября. Хостер, у которого находится основной фронтэнд, сказал что у него проблемы с провайдерами и будет технические работы. Некоторое время он просто лежал. Потом отрубился ipv6 (а по нему у меня общается фронтэнд и бэкэнд). Заметил я это похоже только через несколько часов. Как заметил - переключил их на ipv4 и реактор, наконец, заработал. Но по вечерам загрузка картинок реально тормозила. Хостер сказал, что починит всё "очень быстро" - за пару недель.

8го октября мы решили "Хватит это терпеть!". И я пошёл искать где бы ещё арендовать сервер в европе, тянущий 10Гбит и прокачивающий 0.5Пб трафика в месяц за копейки. Нашлось только 2 предложения:
- одно от достаточно хорошей компании Swiftway, но в 2 раза дороже и жёсткое ограничение по трафику - превышение 0.5Пб было дорогим. Хотя можно было подоговариваться по поводу превышения трафика.
- второе от британской redstation. Там предлагался безлимитный 1.5Гбит по цене моего сервера. У меня в среднем трафик 1.8Гбит и 95% burstable - 2.5 Гбит. Поэтому два сервера должны были вполне уместиться по трафику и иметь запас. Но дальше я начал расспрашивать их как они считают трафик и оказалось, что они жёстко шейпят на 1.5Гбит. А у реактора бывают кратковременные (и не очень) всплески сильно выше среднего. Поэтому тоже не очень
- третье предложение было от нашего же хостера. У него датацентров много. Проблемы только в одном. Почему бы не попробовать другие? Это и было принято за рабочее решение.

Оказалось, что в двух нормальных ДЦ - Вене и Праге - у него мест нет. Есть только в Злине - деревушке на востоке Чехии. Ну делать нечего - попробуем его. Оплатил. Всё поставили. Ipv6, как всегда, заработал с 3ьего раза у них. Попинговал разные места - по одному из маршрутов был небольшой пакетлост. Написал им - ответ мы скажем своему провайдеру, чтобы они увеличили канал в том месте, но когда они это сделают не знаем. Ладно, наверное что-то немного лагающее будет лучше чем сильно лагающее. Переключил реактор на сервер в Злине и начался пиздец. По вечерам пакетлост по всем направлениям, ещё хуже чем в лагающем Амстердаме.

А тут ещё и подходит время оплаты амстердамского сервера (который по прошестии 12 дней всё ещё тормозил). Пишу хостеру письмо, что нах вас всех, возвращайте деньги. После долгих бесед и валерьянки в форме коньяка, они мне подарили неделю амстердамсого сервера бесплатно, заверили что в течении этой недели всё починится, Злинский сервер отменили и вернули полностью деньги на внутренний счёт.

После такой недели у меня была только одна мысль - "Придётся это терпеть".

Протрезвев через пару дней ко мне пришла ещё одна мысль. Бэкэнды у реактора стоят у другого хостера. Там с каналами всё достаточно плохо, зато сервера дешёвые. И недавно они обновили линейку своих серверов. И теперь за 50 евро можно взять лучший сервер, чем у меня стоят за 60 евро. Только надо установочный платёж в размере 50евро заплатить. Вот я и решил - через 5 месяцев этот апгрейд всё равно окупится. Давай сделаю сейчас, на некоторое время старые всё ещё будут работать, а новые настрою на отдачу картинок. Тогда хотя бы немного разгружу амстердам и часть картинок будет отдаваться быстро. За неделю я не успею выбраться за лимиты трафика.

Сказано - сделано. Сделал всё это. Пару дней оно проработало в этом режиме и потом Амстердам починили, наконец. Вернее, основные лаги там пропали, но остались ещё небольшие по ipv4 и полностью не рабочий ipv6. Но это решаемо (сейчас вот решаю потихоньку).

И тут наступает другая проблема - перенос старых серверов на новые. Перенос я делал в попыхах (чтобы меньше платить за старые сервера) и в результате не все данные в свифте перенеслись. Заметили это только когда сервера уже забрали. В результате потерялись порядка 1-2% картинок. Из хороших новостей, что у меня одна и та же картинка хранится в куче разных вариантов - увеличенная, уменьшенная, с вотермарками и т.д. Сейчас восстанавливаю что возможно.

Вторую проблему вчера решал. Новые сервера нещадно жрали проц. Это при том, что он там на 2 поколения лучше, чем на старых. До полуночи дебажил всё это. Оказалось, что в libmemcached в последней версии сломали ipv6. Причём там был такой код:

#if 0
hints.ai_family= AF_INET;
#endif

Он никогда не работал. Но какой-то умный человек решил, что это наверное ошибка и удалил If/endif. Из-за этого строчка начала работать, а она запрещает использование ipv6. Ну сегодня нашёл предыдущую версию, накатил её на все серера, нагрузка сразу спала. Уф, хоть одна хорошая новость.

Надеюсь в следующей части я расскажу как сделал CDN, ибо уже давно жду, когда мне поставят 2ой фронтэнд в Нью-Йорке.
Развернуть

it юмор программирование geek смешные картинки 

frontend dev doing backend backend dev doing frontend,it юмор,программирование,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,смешные картинки,фото приколы
Развернуть

commitstrip Комиксы 

Meanwhile in a parallel universe...
CommitStrip.com,commitstrip,Смешные комиксы,веб-комиксы с юмором и их переводы
Развернуть
В этом разделе мы собираем самые смешные приколы (комиксы и картинки) по теме фронтэнд бэкэнд (+202 картинки)