Thanks Marcel. I am really (mean, really) surprised to see that memcpy() call was a bottleneck. Are we sure that valgrind instrumentation doesn't interfere here?
Could you elaborate more on you environment please - OS, C library, compiler, etc? If you build with full optimization on, do you see the same CPU load? On Thu, Sep 25, 2014 at 8:09 AM, Marcel Wirtz <[email protected]> wrote: > Thanks Sergey, > > the patch works great so far. I tested the file example with your patch > applied and, as predicted, the CPU instruction count went down by about > 60%. CPU load as shown by top also decreased by about the same factor and > download speed has increased, especially with multiple parallel downloads. > 2 parallel downloads have the same total transfer rate as a single > download, without the patch it decreased rapidly, limited by the CPU usage. > > An analysis with callgrind now shows FD_* macros as the biggest impact on > CPU load, and i don't think, there's a way to save anything there. > > > Am Freitag, 19. September 2014 23:57:17 UTC+2 schrieb Sergey Lyubka: >> >> Thanks Macel. >> Could you try on attached patch please? >> >> >> >> On Thu, Sep 18, 2014 at 12:19 PM, Marcel Wirtz <[email protected]> wrote: >> >>> The problem is definetly not IO related (And no other software I know >>> has such a high CPU load transferring data from a file to a socket). >>> >>> A short analysis of the problem: >>> >>> in transfer_file_data() read is called to read data from the file to a >>> buffer (0.29% of the total CPU instructions). Then ns_send() is called. >>> Here the buffer is copied to another buffer (59.27% CPU instructions in >>> memcpy). send() is called by ns_write_to_socket() and uses 0.49% of the CPU >>> instructions. So the real problem is not reading from the file or writing >>> to the socket, but the internal copy of the buffer in ns_send(). If there >>> would be a way not to copy every byte of the file internaly before sending, >>> the CPU load should be smaller (about 60%, which would be better by far). >>> >>> Am Mittwoch, 17. September 2014 09:54:11 UTC+2 schrieb Sergey Lyubka: >>>> >>>> Well if that is memcpy, then I don't find it surprising. >>>> Server is mostly doing data copying, reading from file and copying to >>>> the socket. >>>> >>>> >>>> >>>> On Sat, Sep 13, 2014 at 12:11 PM, Marcel Wirtz <[email protected]> >>>> wrote: >>>> >>>>> Yes >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "mongoose-users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at http://groups.google.com/group/mongoose-users. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "mongoose-users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/mongoose-users. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "mongoose-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/mongoose-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "mongoose-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/mongoose-users. For more options, visit https://groups.google.com/d/optout.
