Re: [go-nuts] cache for *os.File

It depends a lot on what your application does, but I’d try the trace tool, which should give you execution times of your request and you see its interactions with the garbage collector. For reasonable allocation rates you may find that the gc can collect in the background and not introduce

Re: [go-nuts] cache for *os.File

2017-12-14 9:28 GMT+03:00 Dave Cheney : > Does your profiling suggest these allocations are causing latency? > Hmm this is missing part =). How can i understand what causing latency if i use http prof? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- You received this

Re: [go-nuts] cache for *os.File

Does your profiling suggest these allocations are causing latency? On Thu, Dec 14, 2017 at 5:11 PM, Vasiliy Tolstov wrote: > 2017-12-13 22:31 GMT+03:00 Dave Cheney : >> What does profiling say? Does your program spend the majority of its time >> stating

Re: [go-nuts] cache for *os.File

2017-12-13 22:31 GMT+03:00 Dave Cheney : > What does profiling say? Does your program spend the majority of its time > stating files? Do stats add a significant amount of latency to your > request/response cycle? > In my case profiling says only about memory allocations when

[go-nuts] cache for *os.File

What does profiling say? Does your program spend the majority of its time stating files? Do stats add a significant amount of latency to your request/response cycle? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this

[go-nuts] cache for *os.File

Hi! I'm not test my question, but may be somebody already knows. Nginx for example have fd cache mostly i think for sendfile syscall , so nginx already knows that file exists and it size that needed for sendfile. If i write server what accept requests from clients and read/write to many files on