Другое дело время компиляции - оно выше сильно.

Другое дело некая бажность. Его задачей было отдавать js файл, скомпиленный вебпаком.

Он отдавал заголовки заставляющие браузер кешировать. При этом иногда отдавал пустой файл.

В ряде случаев просто не отдает контент, пока f5 не нажмешь раз 10

ты явно написал крайнюю дичь.

Причем датой изменения ставит левую дату. Что мешает отладке.

Он отдавал заголовки заставляющие браузер кешировать. При этом иногда отдавал пустой файл.

ты что, в инспекторе смотрел, что ли?

В инспекторе заголовок даты изменения, да. Обычный заголовок, любой http сервер его отдвет

Через stx.response.header.set можно поставить pragma: no csche

Но дата будет скакать, неизменная

Т.е. не поставить допустим далекое прошлое чтобы запретить кеширование

Смотрел я на fasthttp, такая шляпа

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

другой вопрос — покажи конкретно код, который ты написал и используемый коммит fasthttp, как и git status в нем.

Мне как бы все равно у кого что на прод работает

Я заменил на net/http и кейс ctrl + s, alt + tab, f5 стал работать в 100% случаев, а не 95.

Я заменил на net/http и кейс ctrl + s, alt + tab, f5 стал работать в 100% случаев, а не 95.

ну так покажи код.

Но так как такая движуха, я подниму старую версию, и сделаю воспроизведение того, про что говорю

Суть простая там сервинг одного статического файла, яваскрипт скомпиленный вебпаком

Мы же говорим про https://github.com/valyala/fasthttp ?

Мы же говорим про https://github.com/valyala/fasthttp ?

да.

В ряде случаев просто не отдает контент, пока f5 не нажмешь раз 10

А на хрена ж вы fasthttp для страничек используете? Он для API, а не для полновесных страниц.

А на хрена ж вы fasthttp для страничек используете? Он для API, а не для полновесных страниц.

у меня там и полновесные страницы

у меня там и полновесные страницы

Я могу быть не прав, т.к. опыта не имею с fasthttp. Я ориентируюсь на его же высказывания в README: net/http handles more HTTP corner cases. И, если у тебя полновесная страница с кучей бизнес-логики и десятком походов в базу, нафига экономить на спичках? А вот если легковесное api, которое делает одну-две простых операций, то там имеет смысл каждый такт экономить.

Повторюсь: я могу быть не прав.

Все уже видели? http://www.tapirgames.com/blog/golang-syntax-sugars-and-exceptions

Я могу быть не прав, т.к. опыта не имею с fasthttp. Я ориентируюсь на его же высказывания в README: net/http handles more HTTP corner cases. И, если у тебя полновесная страница с кучей бизнес-логики и десятком походов в базу, нафига экономить на спичках? А вот если легковесное api, которое делает одну-две простых операций, то там имеет смысл каждый такт экономить.

отличие слишком значительное. поэтому пилю свой фреймворк на fasthttp и пилю на нем всё подряд. но, опять же, публичная версия отстает от моей.

Я могу быть не прав, т.к. опыта не имею с fasthttp. Я ориентируюсь на его же высказывания в README: net/http handles more HTTP corner cases. И, если у тебя полновесная страница с кучей бизнес-логики и десятком походов в базу, нафига экономить на спичках? А вот если легковесное api, которое делает одну-две простых операций, то там имеет смысл каждый такт экономить.

разделяю твое мнение частично. для api стоит использовать в случаях высокой нагрузки ради экономии ресурсов, времени и то без фанатизма, чтобы не заниматься преждевременной оптимизацией. в остальных случаях смысла не вижу брать это. Отдавать статику, странички и прочее лучше через штатный http - там хоть http2 есть, кроме этого много сторонних библиотек и фреймворков используют штатный. Лично я брать это буду в крайнем случае, когда приспичит и не смогу ни горизонтально отмаштабироваться и ничего другого, когда трата времени на использование этой штуки и всех рисков с этим связанных будет оправдана. А так когда работы мало, а времени много можно брать и это, писать свои фреймворки поверх и пилить на нем все подряд, замеряя наносекунды и радуясь как все быстро, только как правило задержки на сети, на базе и тд на практике съедают больше времени чем реализация http и разницы там использовать http или fasthttp особо то и никакой.

разделяю твое мнение частично. для api стоит использовать в случаях высокой нагрузки ради экономии ресурсов, времени и то без фанатизма, чтобы не заниматься преждевременной оптимизацией. в остальных случаях смысла не вижу брать это. Отдавать статику, странички и прочее лучше через штатный http - там хоть http2 есть, кроме этого много сторонних библиотек и фреймворков используют штатный. Лично я брать это буду в крайнем случае, когда приспичит и не смогу ни горизонтально отмаштабироваться и ничего другого, когда трата времени на использование этой штуки и всех рисков с этим связанных будет оправдана. А так когда работы мало, а времени много можно брать и это, писать свои фреймворки поверх и пилить на нем все подряд, замеряя наносекунды и радуясь как все быстро, только как правило задержки на сети, на базе и тд на практике съедают больше времени чем реализация http и разницы там использовать http или fasthttp особо то и никакой.

в целом соглашусь, но мне проще так — я так могу код спокойно переиспользовать между проектами и не париться о переносе

Доброе утро) Как поведут себя тысячи спящих горутин? Я создаю горутину, ложу её в сон на NN минут. Через NN минут горутина должна удалить объект, если он не удален ранее. Или какой есть еще способ отслеживания жизнь кучи объектов поминутно?

Другой способ - для кучи создать доп. поле с датой "когда удалить". Далее таймером перебирать допустим, каждые 5 сек, все объекты и смотреть дату.

Даже если поставить перебор каждую минуту - неужели будет ефективней перебор тысячи объектов, чем запускать горутины, которые должны будут удалять через НН минут объект?

Я просто предложил другой способ, об эффективности не знаю...

Даже если поставить перебор каждую минуту - неужели будет ефективней перебор тысячи объектов, чем запускать горутины, которые должны будут удалять через НН минут объект?

перебор эффективней. но, чтобы не делать перебор я делал несколько иначе в похожей задачке

Даже если поставить перебор каждую минуту - неужели будет ефективней перебор тысячи объектов, чем запускать горутины, которые должны будут удалять через НН минут объект?

если интересно - расскажу как

конечно интересно

А почему не добавлять элемент в список (слайс) со временем удаления? Как я понимаю, время удаления будет монотонно расти. Тогда одной горутиной можно спокойно этот список обрабатывать. Также можно тупо использовать time.AfterFunc .

Но таймер - это на случай, если время удаления растет не монотонно. В монотонном случае список лучше.

конечно интересно

для своей задачи, хоть она и отличается несколько от твоей я делал следующее: взял обычную реялизацию сбалансированного дерева, описал функцию сортировки дерева (дерево хранится всегда в отсортированном виде) в которой у меня было несколько полей еще кроме времени - фактически ключ индекса был составной. так вот тк дерево отсортировано встаем в начало дерева и берем первый элемент - если время пришло то удаляем его из дерева, если не пришло то дальше и не бежим по дереву а спим какое-то время. можно прибить эту горутину которая это делает к системному треду с помощью LockOSThread чтобы не думать что где-то что-то затупило и горутинка не проснулась во время после сна, но и плюсом я делал очень просто: бежал по дереву до тех пор пока время «протухания» было истинным, но это нужно если время сна например 5сек а обьекты могут протухать с частотой в 1 сек.

из минусов мы имеем более долгие операции вставки, удаления и тд с деревом если сравнивать с слайсом, но если нужена конкурентная вставка и большого кол-ва а-ля сотни-миллионы, то это работает

А зачем дерево? Heap!

Угадай, как таймеры в Go работают? Используют heap.

Но это нужно, если время удаления не строго "текущее время + константная дельта", т.е. если может быть произвольным. В противном случае, лучше просто список.

Угадай, как таймеры в Go работают? Используют heap.

зачем угадывать? я прекрасно читаю Go-код, вся реализация как они работают есть на гитхабе в рантайме Go. при чем тут куча в оперативе я так и не понял, может имелось ввиду что структуры таймера в куче хранятся? ну это и так поняно, что не на стеке.

А зачем дерево? Heap!

дерево, чтобы не создавать миллион таймеров. почему? - смотри реализацию таймеров в Go, планировщиков в Go и тд. Также дерево, чтобы конкурентно вставлять и удалять из дерева данные, также оно отсортировано.

зачем угадывать? я прекрасно читаю Go-код, вся реализация как они работают есть на гитхабе в рантайме Go. при чем тут куча в оперативе я так и не понял, может имелось ввиду что структуры таймера в куче хранятся? ну это и так поняно, что не на стеке.

Видимо, читаешь как в поговорке: "смотрю в книгу, вижу фигу". Вот тебе для расширения кругозора https://en.m.wikipedia.org/wiki/Heap_(data_structure) А вот что использовано для таймеров (смотри implementation): https://en.m.wikipedia.org/wiki/Binary_heap

Хинт: у меня маленький коммитик в гошные таймеры. Не то, чем стоит гордиться, просто к тому, что я в теме.

Видимо, читаешь как в поговорке: "смотрю в книгу, вижу фигу". Вот тебе для расширения кругозора https://en.m.wikipedia.org/wiki/Heap_(data_structure) А вот что использовано для таймеров (смотри implementation): https://en.m.wikipedia.org/wiki/Binary_heap

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

Я тебе дал ссылки. Если ты путаешь heap - структуру данных и heap - организацию памяти, это много говорит о твоем знании "теории". Почитай по ссылкам. BTW экскурс в историю: динамическая память стала называться heap, т.к. в перых реализациях широко использовалась структура данных heap. В общем, иди читай википедию.

Забавно, что ты поигнорировал мое сообщение о моем коммите в реализацию гошных таймеров. Т.е. с высоты твоего невежества, ты даже не хочешь читать, что тебе пишет оппонент.

Угадай, как таймеры в Go работают? Используют heap.

ну давай ссылочки тогда не на википею, коммитер, а на сурсы Go - где там используется heap как структура данных и каким макаром это поможет задаче

https://github.com/golang/go/blob/master/src/runtime/time.go // Add a timer to the heap // Delete timer t from the heap. // Heap maintenance algorithms.

молодец, нашел

А теперь покажи, где там сортированное дерево. А потом пойди и почитай таки ссылки на википедию: для чего придумана структура данных HEAP? Почему binary heap так часто для таймеров используют? Расширяй кругозор.

А теперь покажи, где там сортированное дерево. А потом пойди и почитай таки ссылки на википедию: для чего придумана структура данных HEAP? Почему binary heap так часто для таймеров используют? Расширяй кругозор.

а теперь читай там строчку 91, потом читай что я писал зачем сбалансированное дерево и думай

Я с телефона, гитхаб номера строк в телефоне не выводит. Что в строке 91?

Я с телефона, гитхаб номера строк в телефоне не выводит. Что в строке 91?

лок на слайс при добавлении нового таймера.

Чтобы не создавать миллион таймеров? Для этого и куча сойдёт, а она в реализации проще дерева. А написать конкурентное сбалансированное дерево - еще то упражнение. Если ты такие пишешь, снимаю перед тобою шляпу. А лок на слайс - это правда. Потому я уже раза два писал свои таймеры поверх встроенных. Только проблема решается просто: заводишь много слайсов с локом на каждый, и вставляешь в разные. Собственно valyala так и предлагает починить таймеры в 1.9, и 99% вероятностью его патч будет принят.

Чтобы не создавать миллион таймеров? Для этого и куча сойдёт, а она в реализации проще дерева. А написать конкурентное сбалансированное дерево - еще то упражнение. Если ты такие пишешь, снимаю перед тобою шляпу. А лок на слайс - это правда. Потому я уже раза два писал свои таймеры поверх встроенных. Только проблема решается просто: заводишь много слайсов с локом на каждый, и вставляешь в разные. Собственно valyala так и предлагает починить таймеры в 1.9, и 99% вероятностью его патч будет принят.

не только, чтобы не создавать миллион. если в кратце задача у меня была сделать некий планировщик. в нем расписание может менятся до момента выстреливания задачи. так вот не только создавать нужно миллион скажем так, но и переодически отменять запланированное время.

Т.е. сейчас, зная, что его патч будет принят, я сто раз подумаю, прежде чем свои таймеры писать. А учитывая, что в оригинале Станислав предлагал по горутине на элемент, очевидно у него десятки миллионов элементов не предвидятся.

не только, чтобы не создавать миллион. если в кратце задача у меня была сделать некий планировщик. в нем расписание может менятся до момента выстреливания задачи. так вот не только создавать нужно миллион скажем так, но и переодически отменять запланированное время.

time.Timer.Reset() heap поддерживает изменение "времени", и делает это эффективнее, чем сортированное сбалансированное дерево.

Да, ты не ответил: ты писал сбалансированное дерево, поддерживающее конкурентную вставку/удаление? Я бы хотел поучиться. Да и статья на хабре, думаю, много бы набрала плюсов.

Прости, вероятно для своей задачи ты писал.

Да, ты не ответил: ты писал сбалансированное дерево, поддерживающее конкурентную вставку/удаление? Я бы хотел поучиться. Да и статья на хабре, думаю, много бы набрала плюсов.

отвечаю: lock-free не писал, хотя алгоритмы реализации я видел. но писал для своей задачи

Твоя реализация - коммерческая тайна? Очень хочется посмотреть. (Я искренне, без издевки).

Просто, я более-меннее в однопоточных алгоритмах подкован, но когда до параллельности доходит, ничего лучше чем "пошардить и по локу на шард" выдать не могу.

К чести признать, чаще всего шардирование решает задачу.

я могу дать пейпер где я немного идей спер

я как раз нашел в закладках

http://www.cs.technion.ac.il/~erez/Papers/lfbtree-full.pdf

Ок, спасибо :-)

в сео понимает кто-нибудь?

и в htaccess

не в тот чат ты пришел, мне кажется

ты чатик перепутал

Просто нужно перекрыть траф с яндекса

думал разберётесь

а то сервер разрывается уже

не

это не к нам

По миллиону уников в день заходит

беда какая

как ты с этим живешь?

дать контакты сеошника?

???

маркетинг

80лвл

чувак

ну каммон

шутка шутка

свали отсюда

просто проверить решил

ни каких ссылок

ага

По миллиону уников в день заходит

robots.txt. параметр crawl-delay

Более правильный способ отдавать заголовки last change или етокен