Re: Increased memory consumption due to url encoding
Thanks Chris, I've created a pull request on github: https://github.com/apache/tomcat85/pull/3 > and then look at the diffs manually It's an almost complete rewrite and has very little in common with the old encoder Svetlin 2016-08-30 20:56 GMT+03:00 Christopher Schultz: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Svetlin, > > On 8/28/16 12:57 PM, Svetlin Zarev wrote: > > Hi, > > > > Today I had some free time, so I implemented a more (memory and > > performance wise) efficient URLEncoder [1] and I'd like to > > contribute it if there is interest for improvement in that area. My > > encoder has close to zero allocation rate (unless there is very > > high concurrency for the encode() operations, but still will be > > much more memory efficient than the current encoder) and encodes > > 2-4 times faster than the current implementation. It is available @ > > [1]. I'm open for reviews, critiques, questions, suggestions, etc. > > > > [1] https://github.com/SvetlinZarev/UrlEncoder > > Can you post this as a pull request, patch, or similar? Nobody really > wants to download this code, replace their own local code, and then > look at the diffs manually. I suspect that's why nobody has looked at > it, yet. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJXxcjVAAoJEBzwKT+lPKRYsCMQAKy/pVLDeSWvcbbHMYwOLwa5 > xhBc3R0ev51qt9rMbkBTQhOZM/beM5u9AcOevFNaQlqr6knxui0R2v7fcM7LKxzU > w8iRxe+8w1GxA/nPVmUAXU5geL7Z7gnyIf+GBhOlxn8R4cXfkvRBCOP0shZpIXPr > fF4buxBLGOii3ApiYELdxxM6andEXc8SHd+CoCm9fc3GPMVyR4eFDEg7nNc1Y44t > FWRBOXNCf0nJRHUDswEqK2ZTlTvd1GFTInLAy9m30uJRzkGDa3ytgfikaBE/c/Je > ctCtz/g9xUk715YFhm23ZAmGvzi3bWBj9PZ3yTixf646Oa8WPsWWm7vALjRNZcfG > j8Cy0ugEo1kT9wr1anIdPtr4q22E3k4Gu8SAhEObcO65dFtdZ2kvQ+tJxTceOmjn > vyplST7kVORuhtWf+rj+L+VgHZsRR54+5C8a9Hf1/TSaI1ztWJbFIYuJr+YgnGw5 > Z264C/rWPr4fd1BRNCwJz9iHoC24IuTJAiNNcVQHrs7xKn16sW4Sq/hM5AE7oJ/5 > RhvpLtZPQmxpqVjvxPallYT0/lMN3CJ26m7A5rf0242MMf9zIsxsnnNUznhh2zNR > gyJsTHJZ2o4tuwEclimzxrwIbO5RxgIeoTdxTbhsE4775oSQ3VHvE07yDPLlqRAh > My3/WOXu8myi0WeLoRzE > =5SJi > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Increased memory consumption due to url encoding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Svetlin, On 8/28/16 12:57 PM, Svetlin Zarev wrote: > Hi, > > Today I had some free time, so I implemented a more (memory and > performance wise) efficient URLEncoder [1] and I'd like to > contribute it if there is interest for improvement in that area. My > encoder has close to zero allocation rate (unless there is very > high concurrency for the encode() operations, but still will be > much more memory efficient than the current encoder) and encodes > 2-4 times faster than the current implementation. It is available @ > [1]. I'm open for reviews, critiques, questions, suggestions, etc. > > [1] https://github.com/SvetlinZarev/UrlEncoder Can you post this as a pull request, patch, or similar? Nobody really wants to download this code, replace their own local code, and then look at the diffs manually. I suspect that's why nobody has looked at it, yet. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXxcjVAAoJEBzwKT+lPKRYsCMQAKy/pVLDeSWvcbbHMYwOLwa5 xhBc3R0ev51qt9rMbkBTQhOZM/beM5u9AcOevFNaQlqr6knxui0R2v7fcM7LKxzU w8iRxe+8w1GxA/nPVmUAXU5geL7Z7gnyIf+GBhOlxn8R4cXfkvRBCOP0shZpIXPr fF4buxBLGOii3ApiYELdxxM6andEXc8SHd+CoCm9fc3GPMVyR4eFDEg7nNc1Y44t FWRBOXNCf0nJRHUDswEqK2ZTlTvd1GFTInLAy9m30uJRzkGDa3ytgfikaBE/c/Je ctCtz/g9xUk715YFhm23ZAmGvzi3bWBj9PZ3yTixf646Oa8WPsWWm7vALjRNZcfG j8Cy0ugEo1kT9wr1anIdPtr4q22E3k4Gu8SAhEObcO65dFtdZ2kvQ+tJxTceOmjn vyplST7kVORuhtWf+rj+L+VgHZsRR54+5C8a9Hf1/TSaI1ztWJbFIYuJr+YgnGw5 Z264C/rWPr4fd1BRNCwJz9iHoC24IuTJAiNNcVQHrs7xKn16sW4Sq/hM5AE7oJ/5 RhvpLtZPQmxpqVjvxPallYT0/lMN3CJ26m7A5rf0242MMf9zIsxsnnNUznhh2zNR gyJsTHJZ2o4tuwEclimzxrwIbO5RxgIeoTdxTbhsE4775oSQ3VHvE07yDPLlqRAh My3/WOXu8myi0WeLoRzE =5SJi -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Increased memory consumption due to url encoding
Hi, Today I had some free time, so I implemented a more (memory and performance wise) efficient URLEncoder [1] and I'd like to contribute it if there is interest for improvement in that area. My encoder has close to zero allocation rate (unless there is very high concurrency for the encode() operations, but still will be much more memory efficient than the current encoder) and encodes 2-4 times faster than the current implementation. It is available @ [1]. I'm open for reviews, critiques, questions, suggestions, etc. [1] https://github.com/SvetlinZarev/UrlEncoder Svetlin
Re: Increased memory consumption due to url encoding
Am 11.08.2016 um 21:16 schrieb Jose María Zaragoza: 2016-08-10 14:29 GMT+02:00 Lazar Kirchev: Hello Christopher, I tried with 32 MB and even 24 MB heap and the CPU usage and response time remained the almost the same (the difference is negligible) as with 1 GB heap. The cumulative allocated memory for the HeapByteBuffer remains about 400 MB, but of course the frequency of GCs is increased. A newbie question: if you tried with 32 MB ( I guess -Xmx size ) , why is not raised an OOM error ? are those 400MB allocated outside heap ? Allocation size is not the same as size of objects in memory. An allocation of 400 MB during some test means the sum of the sizes of all objects that were created was 400 MB. The life time of those objects could be very short. So it is possible that only few of them were in memory at the same time. An extreme example: suppose you create 1000 objects per second (or one per millisecond) each of size 10 KB. That means you have an allocation rate of 10 MB/s or after one minute 600 MB. Assume further that each object only lives 5 milliseconds, because it maybe is created and used only inside a method that runs very short. Then at each point in time about 5 of those objects exist which makes up only 50 KB of memory. For many java programs the popular slogan "most objects die young" is correct, which means you can have high allocation rates with relatively small memory. Allocation is relatively cheap in Java. As always details go far beyond such simplistic slogans. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Increased memory consumption due to url encoding
2016-08-10 14:29 GMT+02:00 Lazar Kirchev: > Hello Christopher, > > I tried with 32 MB and even 24 MB heap and the CPU usage and response time > remained the almost the same (the difference is negligible) as with 1 GB > heap. The cumulative allocated memory for the HeapByteBuffer remains about > 400 MB, but of course the frequency of GCs is increased. A newbie question: if you tried with 32 MB ( I guess -Xmx size ) , why is not raised an OOM error ? are those 400MB allocated outside heap ? Thanks > > Regards, > Lazar > > On Tue, Aug 9, 2016 at 7:27 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> Lazar, >> >> On 8/9/16 8:40 AM, Lazar Kirchev wrote: >> > Hello! When handling requests which make use of request dispatcher, >> > Tomcat 7.0.70 allocates more memory in comparison to 7.0.69. This >> > seems to come from the encoding of the path introduced with this >> > change http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/ >> > apache/catalina/core/ApplicationContext.java?r1=1741024=1741023 >> hrev= >> > >> > >> 1741024 >> > 5 requests to a very simple servlet which only gets a request >> > dispatcher for some path lead to allocation of about 400 MB. >> > However, after a GC they are freed and this actually does not >> > influence CPU or response time. Has anybody noticed this effect and >> > what do you think about it? >> >> What happens if you set the heap size very low (e.g. 32MiB) and run >> the same test? Does the memory usage grow to 400MiB, or does the >> request performance start to degrade? >> >> I'm curious if you are just seeing the effect of the GC doing its job >> correctly. >> >> - -chris >> -BEGIN PGP SIGNATURE- >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBCAAGBQJXqgSPAAoJEBzwKT+lPKRY6+8P/2vzkhQJkPKjYAFln5wkbPp7 >> lbIVDvcH5546ch4nTQsrMPiUT/m71wwDytn6qOMzP9dIbAXjC3tBJI+nqDthkZyQ >> ScmIi2A93JQl0aOHrMzCuS3cFk0sNdwK3n2sk8ZcFd5/KZ5cwxkyeUqwiRVbU5bA >> MjJsEiq+r7Vgo6V3mAxMwaKS7mwLc1hcgJMrhJA8gjfeHzxhzeG0mcrIGrg5cGvl >> mTHLovt9x1ts4KNApdt4DUSg+Yt3Fx/Gj1aoL1x1KbPM9VIJSb52IG/03WPMxIkq >> fSM71fbZHpjZy19uV+e50sHzM0fg96RsrlQ7m5Uvjgqkz6zxNYlsX3tC0z1E7oEr >> wq1Qi0C3dCbRe6vqnN3znYg+DyrlZ/R+qO8+35GD3ljiiDuJLpevYFNVjNceFn1Y >> Qno6W8/2Dp1eHTxaAAVY4hhbdZyzLgxD+lOu+THkOnoZwx8Bw8TXStHIdbwtMfSz >> 9jGuZU4W/t9uTgW6ZnauS16v2EKUbicFY9L5FB3vrRUi1qm+pYVMUdQoZtVl2yL6 >> ZoDTEZTGzvpNUoJLGDzWjp9QkXkVGIrgM7+uYXIDcMUn7QrmLLab7oGJO1pLuAlz >> 9BJiLpjqja5eAHp/Bz1ud5ZZhBaNECJIqhkjma/+LAC1Meullf3ct4FRmL8aGfUz >> m0ntWlqyXwr6EbmRjbFE >> =FTq+ >> -END PGP SIGNATURE- >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Increased memory consumption due to url encoding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Lazar, On 8/10/16 8:29 AM, Lazar Kirchev wrote: > I tried with 32 MB and even 24 MB heap and the CPU usage and > response time remained the almost the same (the difference is > negligible) as with 1 GB heap. The cumulative allocated memory for > the HeapByteBuffer remains about 400 MB, but of course the > frequency of GCs is increased. Sounds like Tomcat generates a bunch of temporary garbage with that byte buffer change, but because the objects are so short-lived, they have no impact on the GC performance, and thus no impact on the response time. Remember that GC performance depends upon the number of /live/ objects moving between generations, not the number of total objects or memory "used" by garbage. Actual garbage is basically ignored during a GC run. - -chris > On Tue, Aug 9, 2016 at 7:27 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Lazar, > > On 8/9/16 8:40 AM, Lazar Kirchev wrote: Hello! When handling requests which make use of request dispatcher, Tomcat 7.0.70 allocates more memory in comparison to 7.0.69. This seems to come from the encoding of the path introduced with this change http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/ apache/catalina/core/ApplicationContext.java?r1=1741024=1741023& pat > hrev= > 1741024 5 requests to a very simple servlet which only gets a request dispatcher for some path lead to allocation of about 400 MB. However, after a GC they are freed and this actually does not influence CPU or response time. Has anybody noticed this effect and what do you think about it? > > What happens if you set the heap size very low (e.g. 32MiB) and > run the same test? Does the memory usage grow to 400MiB, or does > the request performance start to degrade? > > I'm curious if you are just seeing the effect of the GC doing its > job correctly. > > -chris >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXq0gVAAoJEBzwKT+lPKRYanIP/1fZ436QaLhfN/8ea3foT5gX 0fv9wK+sacg4ZTNyxVLwJa03GfS0SDNXBz9WKLa3FBxqi7WopRNqEtnH28nmCNnp 34toy+k5+IWOATn4xyboUmp6CXHTQieTO3OGmQBEg8CMOipSluOPtkq0qfPqaqKz s//gKq0o2y3LG+7SrbHeHzf8GJiZQnIASkXBJxZ5dncJx5tHAXKbA0ji6NFlhqat Y3E/16griZSoqhm/mVRHVZfEdvsebMDmC7cDxxakJpcxr6MjZL8aw9Tdop01aA7c 0U5ndG6jT7vJ8V1iYKblZkM0xgPuBZQln8MHuwuRVXcPgkVHhf2AOiXKrcLWtXCh vnc0zRRn+Qat3FXrqUIv39r51+OtCO+c860Rny/t3gUXV0VSGsBLW8nAvCe8dLPf spc4yJPEICOVsUcOk04P4ktwXQYXR6DzcV09tpHdbIeQ23YHoYAvW4O93wp4AhJ3 /rI3t4dCCFWpxutsVxBmrVpgbLJg78kpZTauu35Q0oJBHPYGxjn+mOdqZMSXnn3X 3afrr9nmneyW/YUEj0sUclr5HtbqHojStphf7SYczMlnDpOg5DVGGnSJLK2gvJVQ Plu1qsA0uJ1NUEFRLkQ0FwyxSZl8EtfSQHqZnh/pgulto38dRa7kSRgUylHWnpI3 9uV9gLnKuBWlqg+y16UV =tW0i -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Increased memory consumption due to url encoding
Hello Christopher, I tried with 32 MB and even 24 MB heap and the CPU usage and response time remained the almost the same (the difference is negligible) as with 1 GB heap. The cumulative allocated memory for the HeapByteBuffer remains about 400 MB, but of course the frequency of GCs is increased. Regards, Lazar On Tue, Aug 9, 2016 at 7:27 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Lazar, > > On 8/9/16 8:40 AM, Lazar Kirchev wrote: > > Hello! When handling requests which make use of request dispatcher, > > Tomcat 7.0.70 allocates more memory in comparison to 7.0.69. This > > seems to come from the encoding of the path introduced with this > > change http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/ > > apache/catalina/core/ApplicationContext.java?r1=1741024=1741023 > hrev= > > > > > 1741024 > > 5 requests to a very simple servlet which only gets a request > > dispatcher for some path lead to allocation of about 400 MB. > > However, after a GC they are freed and this actually does not > > influence CPU or response time. Has anybody noticed this effect and > > what do you think about it? > > What happens if you set the heap size very low (e.g. 32MiB) and run > the same test? Does the memory usage grow to 400MiB, or does the > request performance start to degrade? > > I'm curious if you are just seeing the effect of the GC doing its job > correctly. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJXqgSPAAoJEBzwKT+lPKRY6+8P/2vzkhQJkPKjYAFln5wkbPp7 > lbIVDvcH5546ch4nTQsrMPiUT/m71wwDytn6qOMzP9dIbAXjC3tBJI+nqDthkZyQ > ScmIi2A93JQl0aOHrMzCuS3cFk0sNdwK3n2sk8ZcFd5/KZ5cwxkyeUqwiRVbU5bA > MjJsEiq+r7Vgo6V3mAxMwaKS7mwLc1hcgJMrhJA8gjfeHzxhzeG0mcrIGrg5cGvl > mTHLovt9x1ts4KNApdt4DUSg+Yt3Fx/Gj1aoL1x1KbPM9VIJSb52IG/03WPMxIkq > fSM71fbZHpjZy19uV+e50sHzM0fg96RsrlQ7m5Uvjgqkz6zxNYlsX3tC0z1E7oEr > wq1Qi0C3dCbRe6vqnN3znYg+DyrlZ/R+qO8+35GD3ljiiDuJLpevYFNVjNceFn1Y > Qno6W8/2Dp1eHTxaAAVY4hhbdZyzLgxD+lOu+THkOnoZwx8Bw8TXStHIdbwtMfSz > 9jGuZU4W/t9uTgW6ZnauS16v2EKUbicFY9L5FB3vrRUi1qm+pYVMUdQoZtVl2yL6 > ZoDTEZTGzvpNUoJLGDzWjp9QkXkVGIrgM7+uYXIDcMUn7QrmLLab7oGJO1pLuAlz > 9BJiLpjqja5eAHp/Bz1ud5ZZhBaNECJIqhkjma/+LAC1Meullf3ct4FRmL8aGfUz > m0ntWlqyXwr6EbmRjbFE > =FTq+ > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Increased memory consumption due to url encoding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Lazar, On 8/9/16 8:40 AM, Lazar Kirchev wrote: > Hello! When handling requests which make use of request dispatcher, > Tomcat 7.0.70 allocates more memory in comparison to 7.0.69. This > seems to come from the encoding of the path introduced with this > change http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/ > apache/catalina/core/ApplicationContext.java?r1=1741024=1741023 hrev= > > 1741024 > 5 requests to a very simple servlet which only gets a request > dispatcher for some path lead to allocation of about 400 MB. > However, after a GC they are freed and this actually does not > influence CPU or response time. Has anybody noticed this effect and > what do you think about it? What happens if you set the heap size very low (e.g. 32MiB) and run the same test? Does the memory usage grow to 400MiB, or does the request performance start to degrade? I'm curious if you are just seeing the effect of the GC doing its job correctly. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXqgSPAAoJEBzwKT+lPKRY6+8P/2vzkhQJkPKjYAFln5wkbPp7 lbIVDvcH5546ch4nTQsrMPiUT/m71wwDytn6qOMzP9dIbAXjC3tBJI+nqDthkZyQ ScmIi2A93JQl0aOHrMzCuS3cFk0sNdwK3n2sk8ZcFd5/KZ5cwxkyeUqwiRVbU5bA MjJsEiq+r7Vgo6V3mAxMwaKS7mwLc1hcgJMrhJA8gjfeHzxhzeG0mcrIGrg5cGvl mTHLovt9x1ts4KNApdt4DUSg+Yt3Fx/Gj1aoL1x1KbPM9VIJSb52IG/03WPMxIkq fSM71fbZHpjZy19uV+e50sHzM0fg96RsrlQ7m5Uvjgqkz6zxNYlsX3tC0z1E7oEr wq1Qi0C3dCbRe6vqnN3znYg+DyrlZ/R+qO8+35GD3ljiiDuJLpevYFNVjNceFn1Y Qno6W8/2Dp1eHTxaAAVY4hhbdZyzLgxD+lOu+THkOnoZwx8Bw8TXStHIdbwtMfSz 9jGuZU4W/t9uTgW6ZnauS16v2EKUbicFY9L5FB3vrRUi1qm+pYVMUdQoZtVl2yL6 ZoDTEZTGzvpNUoJLGDzWjp9QkXkVGIrgM7+uYXIDcMUn7QrmLLab7oGJO1pLuAlz 9BJiLpjqja5eAHp/Bz1ud5ZZhBaNECJIqhkjma/+LAC1Meullf3ct4FRmL8aGfUz m0ntWlqyXwr6EbmRjbFE =FTq+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Increased memory consumption due to url encoding
Hello! When handling requests which make use of request dispatcher, Tomcat 7.0.70 allocates more memory in comparison to 7.0.69. This seems to come from the encoding of the path introduced with this change http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/ apache/catalina/core/ApplicationContext.java?r1=1741024=1741023= 1741024 5 requests to a very simple servlet which only gets a request dispatcher for some path lead to allocation of about 400 MB. However, after a GC they are freed and this actually does not influence CPU or response time. Has anybody noticed this effect and what do you think about it? Kind regards, Lazar