Евгений Мамонов, пытаюсь распутать зависимости, там черт ногу сломит. но в целом только такой подход поможет. еще для повтора тестов изучаю возможность перезапуска тестов вручную через TestMain
А как у вас не случается циклической зависимости? repo/mongodb импортурует repo, а repo/repo_test.go будет обратно тащить repo/mongodb. это приводит к ошибке. Или у вас адаптеры repo/mongodb не зависят от repo?
mongodb+srv подразумевает что информация о кластере/реплике хранится в TXT записях домена. И судя по ошибке есть какая-то проблема с чтением записей домена. Тут либо временная проблема у монговских днс, либо домен еще не создался. Лучше копнуть через dig домен.
Ясно, аргументации у Вас нет. Оно и понятно — Вы об этом ничего не знаете. Этих данных в интернете не найдёте, так как это из личного опыта, отчего и предупреждаю. Рекомендую Вам всё-таки идти в энтерпрайзы или в продуктовые компании, на галерах/фрилансах многому не научитесь.
Пф, session_cache_limiter() отключит Cache-Control и варнинги. Ищется в лёгкую. Думал что хотя бы до этого сами додумаетесь. Кажется, переоценил вас.
Может всё-таки расскажете в чем плохого самим управлять сессиоными куками? Да и сессией в целом? А заодно опровергните проблемы сессий, которые я перечислил, на которые вы так активно возбудились? О неси знания всем, "дедуля"!
Полагаю это не весь код? Проверь все include() выше, возможно затисался пробел перед <? или после ?>. А так же проверьте, если у вас кодировка UTF8, что она без BOM.
FanatPHP, не умеете вы анализировать ответы? Включите голову. Автоотправку заголовков (кук) можно выключить, но самим ставить куку сессии когда это удобнее для вас. То что вы не знаете минусов нативных сессий - это ваш недостаток как разработчика. Я не стал рассказывать про проблемы так как это офтоп - так как тема про другое. Спросили бы - рассказал. Но так как у Вас уже пригорело, то отвечу более развернуто, специально для Вас.
Суть совета: отключить отправку заголовков при session_start() и самим ставить куку c ID сессии там где это удобно.
Проблемы сессий:
1) Что будет с сессией если одновременно N вкладок браузера начнут загрузку страницы с одной сессией (допустим браузер перезагрузили)? Какая "вкладка" будет работать с сессией? А какие "вкладки" будут ждать пока другая "вкладка" перестанет работать с сессией? Что произойдёт с fpm/apache когда из-за ожидающих "вкладок" кончатся воркеры? Кто будет отвечать за залипший сервер?
2) Нативные сессии не масштабируются (так как хранятся локально), если сразу не учесть масштабирование то потом Ваш "чудо" проект проще будет отправить в помойку. Сессии можно писать в редис, например. В редисе, используя хеш-структуры можно менять значения по ключам, а не всей сессии, как сейчас. Собственно из-за чего лочится сессия при при работе с ней.
3) Сессия вмешивается в заголовки кеширования, вставляя свои значения в Cache-Control и Expires
Ну как-то так. Я тут похоливарить прихожу, что уж ¯\_(ツ)_/¯. А вообще у товарища, походу, проблема скорее всего в другом. Отпишусь отдельно
Mikkkch, а Вы используете HTTP2? Почему спрашивают, скоро уже будет HTTP3 (типо HTTP2 по UDP) который даст хорошую производительность таким приложениям как, например, онлайн игры. В net/http уже идёт работа по HTTP3. Сейчас, да, fasthttp то что вам надо, но если смотреть дальше, то тут не всё так однозначно.
Если коротко: в вашем случае (если не используете HTTP2) то сразу брал бы fasthttp, но код писал так что бы было можно легко метнуться к net/http в случае чего.
lamer350, про то что ноут новый действительно не заметил, подумал что макбук про 16 это про год выпуска, мой косяк.
искретка включается только тогда когда мощностей встройки не хватает, растр, вектор или видеофайл - значения вообще не имеет!
ну приехали, дискретка вообще в коде по флагу включается. как по вашему нейронки гоняют на маках, не на CPU же. И большинство, включая фотошоп, софта с графикой/видео/аудио включают GPU просто потому что могут (для отслеживания можно смотреть в "Мониторе", нажав там ⌘4 либо поставить, уже устаревший, gfxCardStatus). Даже почта иногда накой-то ляд включает GPU (как-то следил какого черта у меня GPU в ожидании прыгает)
Корпус 110 градусов - это ожог 2ой степени. И пластик снизу уже не помогает ибо метал всё-равно есть - прощайте ноги.
Так же GPU врубает просто подключенный второй экран, причем прогружается GPU не слабо, что даёт не плохую температуру.
Евгений Самсонов, только на idle которые как раз и должны быть положены в pool так как не используются. Рассмотрим штатный keep-alive на http/1.1+: запрос завершился, коннект жив и убивать его не надо еще 1 минуту (idle timeout). Коннект кладётся в пул как не нужный, но сам коннект еще живой. При приходе очередного http запроса по коннекту он изымается из пула.
И вот когда надо прикончить сервер, бежишь по пулу idle (не нужных) и "отстреливаешь" коннекты, всё просто.
Это с пулом. А без пула появляются они - баги и попаболь. Так как idle коннекта на руках нету и дотянутся до него нет возможности то при shutdown закрыть его нет возможности - коннекты живы, здравствуют и, что паршиво, принимают запросы. НО клиенты/браузеры не в курсе что у тебя shutdown - они шлют запрос в keep-alive idle коннект.
И тут выходит что у нас вроде как shutdown, но по коннектам прилетают запросы.
Тут 2 пути и оба стрёмные: обрабатывать и оттягивать время shutdown сервера еще сильнее, либо забить на них и ответит в стиле 500 или тупо порвать соединение (при событии на коннекте срабатывает коллбек у net/http или fasthttp в котором можно их "прибить").
