Re: Pausing all thread but one.
OK tks for the X-Y explanation. I need to reload a few caches and when theese caches are reloaded nobody can access them. This is my problem. Tks Dott. Tullio Bettinazzi Responsabile R & D Axioma - Tel. +39 039 22511 www.axioma.it Trattamento dei dati personali conforme ai sensi del Regolamento Europeo 2016/679 - Messaggio Originale - Da: "Christopher Schultz" <ch...@christopherschultz.net> A: users@tomcat.apache.org Inviato: 28/10/2020 20:13 Oggetto: Re: Pausing all thread but one. Tullio, On 10/28/20 06:27, Tullio Bettinazzi wrote: > I need to perform some maintenance operations pausing all user thread > for a small but meaningfull time (say 30 secs). Ugh. Why? What do you need to do that can't be handled with "proper" synchronization? > Is it possible to pause all user threads ? Maybe. It's very dangerous, though. https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.oracle.com%2Fjavase%2F8%2Fdocs%2Ftechnotes%2Fguides%2Fconcurrency%2FthreadPrimitiveDeprecation.html&e=af66902b&h=887af54c&f=y&p=n > How ? I'll leave that as an exercise for the reader at this point. > Any suggestion ? Yes: think if a better way to do what you are trying to do. This sounds like an X-Y problem[1]. You are trying to do X and you have decided that you need to do Y in order to accomplish X. So you are asking about Y. Why not just ask about X instead? -chris [1] https://urlsand.esvalabs.com/?u=http%3A%2F%2Fxyproblem.info%2F&e=af66902b&h=9b6e4fa6&f=y&p=n - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- This message has been checked by Libraesva ESG and is found to be clean. Follow this link to mark it as spam: https://gw1.idrnet.it/action/B465842741.A19C7/learn-spam - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Pausing all thread but one.
I need to perform some maintenance operations pausing all user thread for a small but meaningfull time (say 30 secs). Is it possible to pause all user threads ? How ? Any suggestion ? Tks Dott. Tullio Bettinazzi Responsabile R & D Axioma - Tel. +39 039 22511 www.axioma.it Trattamento dei dati personali conforme ai sensi del Regolamento Europeo 2016/679 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange wait time in my application - Tomcat 7.0.67
I'm sure is noty a Db issue, the delay is not only concentrated in db functions. The same DB operations seems to take from 4millsec to 4 sec with same data and parameters. Tks Da: Christopher Schultz Inviato: venerdì 21 ottobre 2016 23.07 A: Tomcat Users List Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tullio, On 10/17/16 12:24 PM, Tullio Bettinazzi wrote: > I monitored it using Yourkit profiler and I didn't see any extreme > GC. > > I noticed anotehr thing : looking for 4 users which had the > problem they seems to have the problem "in sequence". > > The first user "stops" for 4 seconds then another one "stops" and > so on : they don't seem to stop at the sam time (as it would be > expected in case of GC) but in sequence. My first reaction is that this has to be a database issue. Are you using a traditional RDBMS under the hood? Can you look for long-running queries on the db? Maybe you have a table that is being locked during a transaction which is holding-up users. Maybe you have a database connection pool without enough connections in it. During times of heavy traffic, when you have users "stalling", what does a thread dump show you? - -chris > Da: André Warnier (tomcat) > Inviato: lunedì 17 ottobre 2016 18.01 A: > users@tomcat.apache.org Oggetto: Re: Strange wait time in my > application - Tomcat 7.0.67 > > On 17.10.2016 17:52, Tullio Bettinazzi wrote: >> I didn't find any solution to my problem. >> >> Could someone provide suggestions or a strategy to find the >> solution ? >> > > "I don't see relevant garbage collection : heap size and permgen > have correct dimentions." > > Define "correct". Are you really *logging* the JVM Garbage > Collection, and do you *know* that this is not the issue ? > > (Note that 4 seconds seems an awfully long time for a GC; but one > would want to eliminate this with certainty, before looking any > further). > > >> >> >> ____ Da: Martijn Bos >> Inviato: lunedì 3 ottobre 2016 21.05 A: Tomcat >> Users List Oggetto: Re: Strange wait time in my application - >> Tomcat 7.0.67 >> >> On 2016-10-03 07:56:34, Tullio Bettinazzi wrote: >>> I've an application under tomcat. When only a one or two users >>> works on it everithing is ok. When the number of users grows >>> the application slows down. Is not a memory nor a cpu problem : >>> using top I see the system resources quite free. I don't see >>> relevant garbage collection : heap size and permgen have >>> correct dimentions. No other applications are running on the >>> system. I log more or less every relevant operation in my >>> system (db query and so on) and I see that every slowdown is >>> concentered in a single operation. I mean all operations take >>> "normal" time but one or two of them take 4 seconds more. The >>> "slowing" operations are not the same in different executions, >>> and theydo not have a specific type (not only DB query, not >>> only DB stored procedures, not only.). It seems like if the >>> thread is frozen for a fixed amount fo time (4 seconds more or >>> less) and then it restarts. I don't think it's a "queue" >>> problem because otherwise the wait time would be unperdictable >>> and not a "fixed" 4 seconds time. I don't know any parameter >>> impacting on that behaviour. I use Tomcat 7.0.32 with JVM >>> 1.7.0.67 on a Linux server. Could someone suggest a solution >>> for my problem or, at least, an investigation strategy. Tks >>> >>> Tullio >>> >> >> >> The few examples that you mention are all database related >> (query/stored procedure). Can it be that your connection pool (if >> used) combined with not closing connections is part of the >> problem. >> >> I can imagine : 1) Maybe you run out of conenctions, because >> connections are not properly closed. And also the connection pool >> teminates connections when they are not used for 4 seconds. After >> 4 seconds the pool can recreate connections again. >> >> or 2) Maybe your connection pool has very limited connections. >> With one or two users this limited number of connections in the >> pool will suffice. If there are more users, the max. number of >> connections isn't enough. The pool then has to wait for >> connections to become
Re: Strange wait time in my application - Tomcat 7.0.67
No further help ? Tks Da: André Warnier (tomcat) Inviato: lunedì 17 ottobre 2016 18.01 A: users@tomcat.apache.org Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67 On 17.10.2016 17:52, Tullio Bettinazzi wrote: > I didn't find any solution to my problem. > > Could someone provide suggestions or a strategy to find the solution ? > "I don't see relevant garbage collection : heap size and permgen have correct dimentions." Define "correct". Are you really *logging* the JVM Garbage Collection, and do you *know* that this is not the issue ? (Note that 4 seconds seems an awfully long time for a GC; but one would want to eliminate this with certainty, before looking any further). > > > > Da: Martijn Bos > Inviato: lunedì 3 ottobre 2016 21.05 > A: Tomcat Users List > Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67 > > On 2016-10-03 07:56:34, Tullio Bettinazzi wrote: >> I've an application under tomcat. >> When only a one or two users works on it everithing is ok. >> When the number of users grows the application slows down. >> Is not a memory nor a cpu problem : using top I see the system resources >> quite free. >> I don't see relevant garbage collection : heap size and permgen have correct >> dimentions. >> No other applications are running on the system. >> I log more or less every relevant operation in my system (db query and so >> on) and I see that every slowdown is concentered in a single operation. >> I mean all operations take "normal" time but one or two of them take 4 >> seconds more. >> The "slowing" operations are not the same in different executions, and >> theydo not have a specific type (not only DB query, not only DB stored >> procedures, not only.). >> It seems like if the thread is frozen for a fixed amount fo time (4 seconds >> more or less) and then it restarts. >> I don't think it's a "queue" problem because otherwise the wait time would >> be unperdictable and not a "fixed" 4 seconds time. >> I don't know any parameter impacting on that behaviour. >> I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server. >> Could someone suggest a solution for my problem or, at least, an >> investigation strategy. >> Tks >> >> Tullio >> > > > The few examples that you mention are all database related (query/stored > procedure). > Can it be that your connection pool (if used) combined with not closing > connections is part of the problem. > > I can imagine : > 1) > Maybe you run out of conenctions, because connections are not properly closed. > And also the connection pool teminates connections when they are not used for > 4 seconds. > After 4 seconds the pool can recreate connections again. > > or 2) > Maybe your connection pool has very limited connections. > With one or two users this limited number of connections in the pool will > suffice. > If there are more users, the max. number of connections isn't enough. > The pool then has to wait for connections to become fee again. > > > (uhhI'm not an expert at all, but the above came immediately to my mind) > > -- > Met vriendelijke groet, > > Martijn Bos > +31 6 39477001 > > (Public pgp-key : http://maboc.nl/pubkey.maboc.asc) maboc.nl<http://maboc.nl/pubkey.maboc.asc> maboc.nl -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ... > maboc.nl<http://maboc.nl/pubkey.maboc.asc> > maboc.nl > -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 > mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk > sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ... > > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange wait time in my application - Tomcat 7.0.67
I monitored it using Yourkit profiler and I didn't see any extreme GC. I noticed anotehr thing : looking for 4 users which had the problem they seems to have the problem "in sequence". The first user "stops" for 4 seconds then another one "stops" and so on : they don't seem to stop at the sam time (as it would be expected in case of GC) but in sequence. Tks Da: André Warnier (tomcat) Inviato: lunedì 17 ottobre 2016 18.01 A: users@tomcat.apache.org Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67 On 17.10.2016 17:52, Tullio Bettinazzi wrote: > I didn't find any solution to my problem. > > Could someone provide suggestions or a strategy to find the solution ? > "I don't see relevant garbage collection : heap size and permgen have correct dimentions." Define "correct". Are you really *logging* the JVM Garbage Collection, and do you *know* that this is not the issue ? (Note that 4 seconds seems an awfully long time for a GC; but one would want to eliminate this with certainty, before looking any further). > > > > Da: Martijn Bos > Inviato: lunedì 3 ottobre 2016 21.05 > A: Tomcat Users List > Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67 > > On 2016-10-03 07:56:34, Tullio Bettinazzi wrote: >> I've an application under tomcat. >> When only a one or two users works on it everithing is ok. >> When the number of users grows the application slows down. >> Is not a memory nor a cpu problem : using top I see the system resources >> quite free. >> I don't see relevant garbage collection : heap size and permgen have correct >> dimentions. >> No other applications are running on the system. >> I log more or less every relevant operation in my system (db query and so >> on) and I see that every slowdown is concentered in a single operation. >> I mean all operations take "normal" time but one or two of them take 4 >> seconds more. >> The "slowing" operations are not the same in different executions, and >> theydo not have a specific type (not only DB query, not only DB stored >> procedures, not only.). >> It seems like if the thread is frozen for a fixed amount fo time (4 seconds >> more or less) and then it restarts. >> I don't think it's a "queue" problem because otherwise the wait time would >> be unperdictable and not a "fixed" 4 seconds time. >> I don't know any parameter impacting on that behaviour. >> I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server. >> Could someone suggest a solution for my problem or, at least, an >> investigation strategy. >> Tks >> >> Tullio >> > > > The few examples that you mention are all database related (query/stored > procedure). > Can it be that your connection pool (if used) combined with not closing > connections is part of the problem. > > I can imagine : > 1) > Maybe you run out of conenctions, because connections are not properly closed. > And also the connection pool teminates connections when they are not used for > 4 seconds. > After 4 seconds the pool can recreate connections again. > > or 2) > Maybe your connection pool has very limited connections. > With one or two users this limited number of connections in the pool will > suffice. > If there are more users, the max. number of connections isn't enough. > The pool then has to wait for connections to become fee again. > > > (uhhI'm not an expert at all, but the above came immediately to my mind) > > -- > Met vriendelijke groet, > > Martijn Bos > +31 6 39477001 > > (Public pgp-key : http://maboc.nl/pubkey.maboc.asc) maboc.nl<http://maboc.nl/pubkey.maboc.asc> maboc.nl -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ... > maboc.nl<http://maboc.nl/pubkey.maboc.asc> maboc.nl<http://maboc.nl/pubkey.maboc.asc> maboc.nl -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ... > maboc.nl > -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 > mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk > sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ... > > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange wait time in my application - Tomcat 7.0.67
I didn't find any solution to my problem. Could someone provide suggestions or a strategy to find the solution ? Tks Da: Martijn Bos Inviato: lunedì 3 ottobre 2016 21.05 A: Tomcat Users List Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67 On 2016-10-03 07:56:34, Tullio Bettinazzi wrote: > I've an application under tomcat. > When only a one or two users works on it everithing is ok. > When the number of users grows the application slows down. > Is not a memory nor a cpu problem : using top I see the system resources > quite free. > I don't see relevant garbage collection : heap size and permgen have correct > dimentions. > No other applications are running on the system. > I log more or less every relevant operation in my system (db query and so on) > and I see that every slowdown is concentered in a single operation. > I mean all operations take "normal" time but one or two of them take 4 > seconds more. > The "slowing" operations are not the same in different executions, and theydo > not have a specific type (not only DB query, not only DB stored procedures, > not only.). > It seems like if the thread is frozen for a fixed amount fo time (4 seconds > more or less) and then it restarts. > I don't think it's a "queue" problem because otherwise the wait time would be > unperdictable and not a "fixed" 4 seconds time. > I don't know any parameter impacting on that behaviour. > I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server. > Could someone suggest a solution for my problem or, at least, an > investigation strategy. > Tks > > Tullio > The few examples that you mention are all database related (query/stored procedure). Can it be that your connection pool (if used) combined with not closing connections is part of the problem. I can imagine : 1) Maybe you run out of conenctions, because connections are not properly closed. And also the connection pool teminates connections when they are not used for 4 seconds. After 4 seconds the pool can recreate connections again. or 2) Maybe your connection pool has very limited connections. With one or two users this limited number of connections in the pool will suffice. If there are more users, the max. number of connections isn't enough. The pool then has to wait for connections to become fee again. (uhhI'm not an expert at all, but the above came immediately to my mind) -- Met vriendelijke groet, Martijn Bos +31 6 39477001 (Public pgp-key : http://maboc.nl/pubkey.maboc.asc) maboc.nl<http://maboc.nl/pubkey.maboc.asc> maboc.nl -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ...
Re: Strange wait time in my application - Tomcat 7.0.67
Tks for Your help but : . problems comes out mainly in Db activities because are the longest one but I saw the same problem also in different operations like xsl parsing . I don't use a connection pool but only private connections one for each user Any further suggestion ? Tkls Da: Martijn Bos Inviato: lunedì 3 ottobre 2016 21.05 A: Tomcat Users List Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67 On 2016-10-03 07:56:34, Tullio Bettinazzi wrote: > I've an application under tomcat. > When only a one or two users works on it everithing is ok. > When the number of users grows the application slows down. > Is not a memory nor a cpu problem : using top I see the system resources > quite free. > I don't see relevant garbage collection : heap size and permgen have correct > dimentions. > No other applications are running on the system. > I log more or less every relevant operation in my system (db query and so on) > and I see that every slowdown is concentered in a single operation. > I mean all operations take "normal" time but one or two of them take 4 > seconds more. > The "slowing" operations are not the same in different executions, and theydo > not have a specific type (not only DB query, not only DB stored procedures, > not only.). > It seems like if the thread is frozen for a fixed amount fo time (4 seconds > more or less) and then it restarts. > I don't think it's a "queue" problem because otherwise the wait time would be > unperdictable and not a "fixed" 4 seconds time. > I don't know any parameter impacting on that behaviour. > I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server. > Could someone suggest a solution for my problem or, at least, an > investigation strategy. > Tks > > Tullio > The few examples that you mention are all database related (query/stored procedure). Can it be that your connection pool (if used) combined with not closing connections is part of the problem. I can imagine : 1) Maybe you run out of conenctions, because connections are not properly closed. And also the connection pool teminates connections when they are not used for 4 seconds. After 4 seconds the pool can recreate connections again. or 2) Maybe your connection pool has very limited connections. With one or two users this limited number of connections in the pool will suffice. If there are more users, the max. number of connections isn't enough. The pool then has to wait for connections to become fee again. (uhhI'm not an expert at all, but the above came immediately to my mind) -- Met vriendelijke groet, Martijn Bos +31 6 39477001 (Public pgp-key : http://maboc.nl/pubkey.maboc.asc) maboc.nl<http://maboc.nl/pubkey.maboc.asc> maboc.nl -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ...
Re: Strange wait time in my application - Tomcat 7.0.67
Please help me to understand diffrences beween Moskito and standard profilers. Tks Tullio Da: Leon Rosenberg Inviato: lunedì 3 ottobre 2016 14.29 A: Tomcat Users List Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67 Hi Tullio, you could download and integrate MoSKito -> http://www.moskito.org. After Health and Performance Monitoring for Java Applications | MoSKito<http://www.moskito.org/> www.moskito.org MoSKito: Health and Performance Monitoring for Java applications. Complete ecosystem for DevOps. Free and open source integration as described here blog.anotheria.net/msk/the-complete-moskito-integration-guide-step-1/ or here: http://www.moskito.org/integration.html you can start your Integration for MoSKito, the Open Source Health and Performance Monitoring System for Java Applications<http://www.moskito.org/integration.html> www.moskito.org MoSKito Integration application and setup a tracer. A tracer, explained here: http://blog.anotheria.net/msk/newest-hottest-tracers/, can be used to automatically trace all requests passing a specific point and compare the execution times. It will keep the longest requests along with the execution time in each monitored component. So if there is some part of code you have, that lasts longer from time to time, the tracer will find it. regards Leon On Mon, Oct 3, 2016 at 2:12 PM, Mark Thomas wrote: > On 03/10/2016 11:19, Tullio Bettinazzi wrote: > > I already use Yourkit but it doesn't seems a load problem. > > > > The delay is not spread over all operaions but concentred in only one or > two and allways takes 4 secs more than the normal operation time. > > > > Could You suggest how to use Yourkit in this schenario ? > > I'd look at GC activity and detailed CPU profiling. > > Mark > > > > > Tks > > > > Tullio > > > > > > > > Da: Mark Thomas > > Inviato: lunedì 3 ottobre 2016 10.39 > > A: Tomcat Users List > > Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67 > > > > On 03/10/2016 08:56, Tullio Bettinazzi wrote: > >> I've an application under tomcat. > >> When only a one or two users works on it everithing is ok. > >> When the number of users grows the application slows down. > >> Is not a memory nor a cpu problem : using top I see the system > resources quite free. > >> I don't see relevant garbage collection : heap size and permgen have > correct dimentions. > >> No other applications are running on the system. > >> I log more or less every relevant operation in my system (db query and > so on) and I see that every slowdown is concentered in a single operation. > >> I mean all operations take "normal" time but one or two of them take 4 > seconds more. > >> The "slowing" operations are not the same in different executions, and > theydo not have a specific type (not only DB query, not only DB stored > procedures, not only.). > >> It seems like if the thread is frozen for a fixed amount fo time (4 > seconds more or less) and then it restarts. > >> I don't think it's a "queue" problem because otherwise the wait time > would be unperdictable and not a "fixed" 4 seconds time. > >> I don't know any parameter impacting on that behaviour. > >> I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server. > >> Could someone suggest a solution for my problem or, at least, an > investigation strategy. > > > > https://www.yourkit.com/java/profiler/features/ > > Performance and Memory Java Profiler - YourKit Java Profiler< > https://www.yourkit.com/java/profiler/features/> > > www.yourkit.com<http://www.yourkit.com> > > Easy to use performance and memory profiler for .NET framework. Supports > ASP.NET, Silverlight, .NET Windows services and more. > > > > > > > > > > Mark > > > > > > - > > 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: Strange wait time in my application - Tomcat 7.0.67
I already use Yourkit but it doesn't seems a load problem. The delay is not spread over all operaions but concentred in only one or two and allways takes 4 secs more than the normal operation time. Could You suggest how to use Yourkit in this schenario ? Tks Tullio Da: Mark Thomas Inviato: lunedì 3 ottobre 2016 10.39 A: Tomcat Users List Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67 On 03/10/2016 08:56, Tullio Bettinazzi wrote: > I've an application under tomcat. > When only a one or two users works on it everithing is ok. > When the number of users grows the application slows down. > Is not a memory nor a cpu problem : using top I see the system resources > quite free. > I don't see relevant garbage collection : heap size and permgen have correct > dimentions. > No other applications are running on the system. > I log more or less every relevant operation in my system (db query and so on) > and I see that every slowdown is concentered in a single operation. > I mean all operations take "normal" time but one or two of them take 4 > seconds more. > The "slowing" operations are not the same in different executions, and theydo > not have a specific type (not only DB query, not only DB stored procedures, > not only.). > It seems like if the thread is frozen for a fixed amount fo time (4 seconds > more or less) and then it restarts. > I don't think it's a "queue" problem because otherwise the wait time would be > unperdictable and not a "fixed" 4 seconds time. > I don't know any parameter impacting on that behaviour. > I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server. > Could someone suggest a solution for my problem or, at least, an > investigation strategy. https://www.yourkit.com/java/profiler/features/ Performance and Memory Java Profiler - YourKit Java Profiler<https://www.yourkit.com/java/profiler/features/> www.yourkit.com Easy to use performance and memory profiler for .NET framework. Supports ASP.NET, Silverlight, .NET Windows services and more. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Strange wait time in my application - Tomcat 7.0.67
I've an application under tomcat. When only a one or two users works on it everithing is ok. When the number of users grows the application slows down. Is not a memory nor a cpu problem : using top I see the system resources quite free. I don't see relevant garbage collection : heap size and permgen have correct dimentions. No other applications are running on the system. I log more or less every relevant operation in my system (db query and so on) and I see that every slowdown is concentered in a single operation. I mean all operations take "normal" time but one or two of them take 4 seconds more. The "slowing" operations are not the same in different executions, and theydo not have a specific type (not only DB query, not only DB stored procedures, not only.). It seems like if the thread is frozen for a fixed amount fo time (4 seconds more or less) and then it restarts. I don't think it's a "queue" problem because otherwise the wait time would be unperdictable and not a "fixed" 4 seconds time. I don't know any parameter impacting on that behaviour. I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server. Could someone suggest a solution for my problem or, at least, an investigation strategy. Tks Tullio
RE: Performance regression from 7 to 8
I tested with http11.Http11Protocol, http11.Http11NioProtocol and http11.Http11Nio2Protocol and the problem reproduces only with http11.Http11NioProtocol. It seems to be a bug of the Nio protocol. It's better to use Nio2 or standard ? What's the difference ? Tks Tullio > Date: Mon, 7 Mar 2016 16:26:24 +0100 > Subject: Re: Performance regression from 7 to 8 > From: aterrest...@gmail.com > To: users@tomcat.apache.org > > Tullio, > > as suggested before by Felix, maybe you should try different connector > configurations (defaults for HTTP connector are different between T7 > (blocking) and T8 (non-blocking)) and see if this changes anything. > > For example in the server.xml file : > > protocol="org.apache.coyote.http11.Http11Protocol" address="YOURSERVER" >connectionTimeout="2" >disableUploadTimeout="false" >connectionUploadTimeout="360" >redirectPort="8843" /> > > and > > protocol="org.apache.coyote.http11.Http11NioProtocol" address="YOURSERVER" >connectionTimeout="2" >disableUploadTimeout="false" >connectionUploadTimeout="360" >redirectPort="8843" /> > > > Your code is simple, only buffering and writing to an OutputStream. Don't > know how, but I believe that only the buffering can introduce some delay. > > best regards > > > > > > > 2016-03-07 15:43 GMT+01:00 Tullio Bettinazzi : > > > As I already explained is not a reproductable problem. > > I tested the testcase in my environment and I reproduced the problem on > > some clients but not on all clients : the same clients where I noticed the > > problem in the real application. > > I'm not able to understand what's the relevant difference among them (not > > OS version, not network, not browser). > > The problem disappears using tomcat 7. > > Tks > > Tullio > > > > > Subject: Re: Performance regression from 7 to 8 > > > To: users@tomcat.apache.org > > > From: ma...@apache.org > > > Date: Mon, 7 Mar 2016 11:52:40 + > > > > > > On 06/03/2016 08:45, Tullio Bettinazzi wrote: > > > > I tested with 8.20 and 8.32 > > > > With nothing changed I meant simply that results didn't change. > > > > > > I can't repeat the problem you are describing with your provided test > > case. > > > > > > I ran: > > > - ab -k -n 1000 -c 1 localhost:8080/user002/Test > > > - latest 8.0.x code > > > - your test case with and without setting the content length (as an > > > HTTP/1.0 client ab needs the content length to use keep-alive with > > > large response bodies > > > > > > I saw average response times of 6ms with a maximum of 9ms. > > > The content length header made no difference (apart from keep-alive > > > being used as expected). > > > > > > If the problem you are describing was widespread I'd expect to see other > > > users reporting this on the mailing list. > > > > > > Given that: > > > - I can't repeat this > > > - Other users aren't reporting it > > > - Only you are seeing the issue > > > > > > this looks like an issue with your environment rather than with Tomcat. > > > I'd recommend using tools like Wireshark and YourKit to find out exactly > > > what is going on. > > > > > > Mark > > > > > > > > > > Tks > > > > Tullio > > > > > > > >> Subject: Re: Performance regression from 7 to 8 > > > >> To: users@tomcat.apache.org > > > >> From: ma...@apache.org > > > >> Date: Sat, 5 Mar 2016 18:40:36 + > > > >> > > > >> On 04/03/2016 13:19, Tullio Bettinazzi wrote: > > > >>> Done and nothing changed. > > > >> > > > >> What has changed is that you have now provided a test case that > > someone > > > >> else can run easily and confirm, or not, your findings. > > > >> > > > >>> Any suggestion ? > > > >> > > > >> Before anyone spends time looking at this the other question I don't > > see > > > >> answered in this thread is "Exactly which Tomcat 8 version were you > > > >> testing?". If it isn't the
RE: Performance regression from 7 to 8
As I already explained is not a reproductable problem.
I tested the testcase in my environment and I reproduced the problem on some
clients but not on all clients : the same clients where I noticed the problem
in the real application.
I'm not able to understand what's the relevant difference among them (not OS
version, not network, not browser).
The problem disappears using tomcat 7.
Tks
Tullio
> Subject: Re: Performance regression from 7 to 8
> To: users@tomcat.apache.org
> From: ma...@apache.org
> Date: Mon, 7 Mar 2016 11:52:40 +
>
> On 06/03/2016 08:45, Tullio Bettinazzi wrote:
> > I tested with 8.20 and 8.32
> > With nothing changed I meant simply that results didn't change.
>
> I can't repeat the problem you are describing with your provided test case.
>
> I ran:
> - ab -k -n 1000 -c 1 localhost:8080/user002/Test
> - latest 8.0.x code
> - your test case with and without setting the content length (as an
> HTTP/1.0 client ab needs the content length to use keep-alive with
> large response bodies
>
> I saw average response times of 6ms with a maximum of 9ms.
> The content length header made no difference (apart from keep-alive
> being used as expected).
>
> If the problem you are describing was widespread I'd expect to see other
> users reporting this on the mailing list.
>
> Given that:
> - I can't repeat this
> - Other users aren't reporting it
> - Only you are seeing the issue
>
> this looks like an issue with your environment rather than with Tomcat.
> I'd recommend using tools like Wireshark and YourKit to find out exactly
> what is going on.
>
> Mark
>
>
> > Tks
> > Tullio
> >
> >> Subject: Re: Performance regression from 7 to 8
> >> To: users@tomcat.apache.org
> >> From: ma...@apache.org
> >> Date: Sat, 5 Mar 2016 18:40:36 +
> >>
> >> On 04/03/2016 13:19, Tullio Bettinazzi wrote:
> >>> Done and nothing changed.
> >>
> >> What has changed is that you have now provided a test case that someone
> >> else can run easily and confirm, or not, your findings.
> >>
> >>> Any suggestion ?
> >>
> >> Before anyone spends time looking at this the other question I don't see
> >> answered in this thread is "Exactly which Tomcat 8 version were you
> >> testing?". If it isn't the the latest then you'll need to retest to
> >> confirm the issue hasn't already been fixed.
> >>
> >> Mark
> >>
> >>> Here the code.
> >>>
> >>> package axioma.rubik.engine.web.servlet;
> >>>
> >>> import java.io.*;
> >>> import javax.servlet.ServletException;
> >>> import javax.servlet.annotation.WebServlet;
> >>> import javax.servlet.http.*;
> >>>
> >>> @WebServlet(name="Test8", description="Direct update of data",
> >>> urlPatterns={"/Test8"})
> >>> public class Test8Servlet extends HttpServlet {
> >>>
> >>> private static final long serialVersionUID = 1L;
> >>>
> >>> @Override
> >>> protected void doGet(HttpServletRequest request, HttpServletResponse
> >>> response) throws ServletException, IOException {
> >>> try {
> >>> fai(response);
> >>> } catch (Exception ex) {
> >>> ex.printStackTrace();
> >>> }
> >>> }
> >>>
> >>> public void fai(HttpServletResponse response) throws IOException {
> >>> ByteArrayOutputStream bbs = new ByteArrayOutputStream();
> >>> BufferedOutputStream bos = new BufferedOutputStream(bbs);
> >>> for(int i = 0; i < 40; i++) {
> >>> bos.write(96);
> >>> }
> >>> bos.flush();
> >>> bbs.writeTo(response.getOutputStream());
> >>> }
> >>> }
> >>
> >>
> >> -
> >> 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: Performance regression from 7 to 8
What do you mean with :
Have you tried switching the connectors on the tomcat side?
???
Tks
> Subject: Re: Performance regression from 7 to 8
> To: users@tomcat.apache.org
> From: felix.schumac...@internetallee.de
> Date: Sat, 5 Mar 2016 14:00:11 +0100
>
> Am 05.03.2016 um 12:34 schrieb Tullio Bettinazzi:
> > This is not a memory problem because, otherwise, I'll have the same problem
> > on all client systems.
> > It's a communication related problem between server and clients but not
> > strictly a network problem because, otherwise, two clients, connected to
> > the same cable would perform in the same way.
> If it is stable slow on one client, then you could take threaddumps on
> the tomcat side and look what it is doing. On the network side, you
> could look at a tcpdump.
>
> Have you tried switching the connectors on the tomcat side?
>
> Felix
> > Tks
> > Tullio
> >
> >> Subject: Re: Performance regression from 7 to 8
> >> To: users@tomcat.apache.org
> >> From: felix.schumac...@internetallee.de
> >> Date: Sat, 5 Mar 2016 11:13:58 +0100
> >>
> >> Am 04.03.2016 um 14:19 schrieb Tullio Bettinazzi:
> >>> Done and nothing changed.
> >>> Any suggestion ?
> >> It could be related to memory usage.
> >>
> >> Tomcat 8 can use more memory than tomcat 7 (See
> >> https://mail-archives.apache.org/mod_mbox/tomcat-users/201602.mbox/%3ccacbju2wmw7mntevb6hwjqdfzsjpmfiuw6k_dn1u0ufh0haj...@mail.gmail.com%3E)
> >>
> >> So try to look at your memory consumption and adjust the limits for the
> >> jvm accordingly. For monitoring, you can enable gc logging, or use
> >> something like jstat, jconsole, jvisualvm, jmc or any other monitoring
> >> tool.
> >>
> >> Mark has worked on the memory issue and lowered consumption for newer
> >> versions. I think they will be in the next release.
> >>
> >> Regards,
> >>Felix
> >>> Here the code.
> >>>
> >>> package axioma.rubik.engine.web.servlet;
> >>>
> >>> import java.io.*;
> >>> import javax.servlet.ServletException;
> >>> import javax.servlet.annotation.WebServlet;
> >>> import javax.servlet.http.*;
> >>>
> >>> @WebServlet(name="Test8", description="Direct update of data",
> >>> urlPatterns={"/Test8"})
> >>> public class Test8Servlet extends HttpServlet {
> >>>
> >>> private static final long serialVersionUID = 1L;
> >>>
> >>> @Override
> >>> protected void doGet(HttpServletRequest request,
> >>> HttpServletResponse response) throws ServletException, IOException {
> >>> try {
> >>> fai(response);
> >>> } catch (Exception ex) {
> >>> ex.printStackTrace();
> >>> }
> >>> }
> >>>
> >>> public void fai(HttpServletResponse response) throws IOException {
> >>> ByteArrayOutputStream bbs = new ByteArrayOutputStream();
> >>> BufferedOutputStream bos = new BufferedOutputStream(bbs);
> >>> for(int i = 0; i < 40; i++) {
> >>> bos.write(96);
> >>> }
> >>> bos.flush();
> >>> bbs.writeTo(response.getOutputStream());
> >>> }
> >>> }
> >>>
> >>>> Date: Fri, 4 Mar 2016 12:58:02 +0100
> >>>> Subject: Re: Performance regression from 7 to 8
> >>>> From: r...@apache.org
> >>>> To: users@tomcat.apache.org
> >>>>
> >>>> 2016-03-04 12:42 GMT+01:00 Mark Thomas :
> >>>>
> >>>>> On 04/03/2016 11:17, Tullio Bettinazzi wrote:
> >>>>>> This servlet reproduces the problem perfectly.
> >>>>> Getting better but still some room for improvement.
> >>>>> - You don't need to implement doPost()
> >>>>> - You don't need to call System.gc() (or if you do look there for
> >>>>> the problem)
> >>>>>
> >>>> Yes, it's on every get and will cause a major concurrency issue.
> >>>>
> >>>>
> >>>>> - You do need to remove the use of the ComunicationChannelHttp and
> >>>>> Cronometro classes (and if that fixes the problem look there
RE: Performance regression from 7 to 8
I tested with 8.20 and 8.32
With nothing changed I meant simply that results didn't change.
Tks
Tullio
> Subject: Re: Performance regression from 7 to 8
> To: users@tomcat.apache.org
> From: ma...@apache.org
> Date: Sat, 5 Mar 2016 18:40:36 +
>
> On 04/03/2016 13:19, Tullio Bettinazzi wrote:
> > Done and nothing changed.
>
> What has changed is that you have now provided a test case that someone
> else can run easily and confirm, or not, your findings.
>
> > Any suggestion ?
>
> Before anyone spends time looking at this the other question I don't see
> answered in this thread is "Exactly which Tomcat 8 version were you
> testing?". If it isn't the the latest then you'll need to retest to
> confirm the issue hasn't already been fixed.
>
> Mark
>
> > Here the code.
> >
> > package axioma.rubik.engine.web.servlet;
> >
> > import java.io.*;
> > import javax.servlet.ServletException;
> > import javax.servlet.annotation.WebServlet;
> > import javax.servlet.http.*;
> >
> > @WebServlet(name="Test8", description="Direct update of data",
> > urlPatterns={"/Test8"})
> > public class Test8Servlet extends HttpServlet {
> >
> > private static final long serialVersionUID = 1L;
> >
> > @Override
> > protected void doGet(HttpServletRequest request, HttpServletResponse
> > response) throws ServletException, IOException {
> > try {
> > fai(response);
> > } catch (Exception ex) {
> > ex.printStackTrace();
> > }
> > }
> >
> > public void fai(HttpServletResponse response) throws IOException {
> > ByteArrayOutputStream bbs = new ByteArrayOutputStream();
> > BufferedOutputStream bos = new BufferedOutputStream(bbs);
> > for(int i = 0; i < 40; i++) {
> > bos.write(96);
> > }
> > bos.flush();
> > bbs.writeTo(response.getOutputStream());
> > }
> > }
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
RE: Performance regression from 7 to 8
This is not a memory problem because, otherwise, I'll have the same problem on
all client systems.
It's a communication related problem between server and clients but not
strictly a network problem because, otherwise, two clients, connected to the
same cable would perform in the same way.
Tks
Tullio
> Subject: Re: Performance regression from 7 to 8
> To: users@tomcat.apache.org
> From: felix.schumac...@internetallee.de
> Date: Sat, 5 Mar 2016 11:13:58 +0100
>
> Am 04.03.2016 um 14:19 schrieb Tullio Bettinazzi:
> > Done and nothing changed.
> > Any suggestion ?
> It could be related to memory usage.
>
> Tomcat 8 can use more memory than tomcat 7 (See
> https://mail-archives.apache.org/mod_mbox/tomcat-users/201602.mbox/%3ccacbju2wmw7mntevb6hwjqdfzsjpmfiuw6k_dn1u0ufh0haj...@mail.gmail.com%3E)
>
> So try to look at your memory consumption and adjust the limits for the
> jvm accordingly. For monitoring, you can enable gc logging, or use
> something like jstat, jconsole, jvisualvm, jmc or any other monitoring tool.
>
> Mark has worked on the memory issue and lowered consumption for newer
> versions. I think they will be in the next release.
>
> Regards,
> Felix
> > Here the code.
> >
> > package axioma.rubik.engine.web.servlet;
> >
> > import java.io.*;
> > import javax.servlet.ServletException;
> > import javax.servlet.annotation.WebServlet;
> > import javax.servlet.http.*;
> >
> > @WebServlet(name="Test8", description="Direct update of data",
> > urlPatterns={"/Test8"})
> > public class Test8Servlet extends HttpServlet {
> >
> > private static final long serialVersionUID = 1L;
> >
> > @Override
> > protected void doGet(HttpServletRequest request, HttpServletResponse
> > response) throws ServletException, IOException {
> > try {
> > fai(response);
> > } catch (Exception ex) {
> > ex.printStackTrace();
> > }
> > }
> >
> > public void fai(HttpServletResponse response) throws IOException {
> > ByteArrayOutputStream bbs = new ByteArrayOutputStream();
> > BufferedOutputStream bos = new BufferedOutputStream(bbs);
> > for(int i = 0; i < 40; i++) {
> > bos.write(96);
> > }
> > bos.flush();
> > bbs.writeTo(response.getOutputStream());
> > }
> > }
> >
> >> Date: Fri, 4 Mar 2016 12:58:02 +0100
> >> Subject: Re: Performance regression from 7 to 8
> >> From: r...@apache.org
> >> To: users@tomcat.apache.org
> >>
> >> 2016-03-04 12:42 GMT+01:00 Mark Thomas :
> >>
> >>> On 04/03/2016 11:17, Tullio Bettinazzi wrote:
> >>>> This servlet reproduces the problem perfectly.
> >>> Getting better but still some room for improvement.
> >>> - You don't need to implement doPost()
> >>> - You don't need to call System.gc() (or if you do look there for
> >>>the problem)
> >>>
> >> Yes, it's on every get and will cause a major concurrency issue.
> >>
> >>
> >>> - You do need to remove the use of the ComunicationChannelHttp and
> >>>Cronometro classes (and if that fixes the problem look there
> >>>for the root cause)
> >>> - The try/catch in doGet() should not be necessary either
> >>>
> >> Also writing individual bytes is more costly even if there's some
> >> buffering.
> >>
> >> Rémy
> >>
> >>> Mark
> >>>
> >>>> package axioma.rubik.engine.web.servlet;
> >>>>
> >>>> import java.io.*;
> >>>> import javax.servlet.ServletException;
> >>>> import javax.servlet.annotation.WebServlet;
> >>>> import javax.servlet.http.*;
> >>>> import axioma.rubik.engine.web.ComunicationChannelHttp;
> >>>> import it.axioma.rubik.engine.Cronometro;
> >>>>
> >>>> @WebServlet(name="Test8", description="Direct update of data",
> >>> urlPatterns={"/Test8"})
> >>>> public class Test8Servlet extends HttpServlet {
> >>>>
> >>>> private static final long serialVersionUID = 1L;
> >>>>
> >>>> @Override
> >>>> protected void doPost(HttpServletRequest request,
> >>> HttpServletResponse response) throws ServletEx
RE: Performance regression from 7 to 8
Done and nothing changed.
Any suggestion ?
Here the code.
package axioma.rubik.engine.web.servlet;
import java.io.*;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.*;
@WebServlet(name="Test8", description="Direct update of data",
urlPatterns={"/Test8"})
public class Test8Servlet extends HttpServlet {
private static final long serialVersionUID = 1L;
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
try {
fai(response);
} catch (Exception ex) {
ex.printStackTrace();
}
}
public void fai(HttpServletResponse response) throws IOException {
ByteArrayOutputStream bbs = new ByteArrayOutputStream();
BufferedOutputStream bos = new BufferedOutputStream(bbs);
for(int i = 0; i < 40; i++) {
bos.write(96);
}
bos.flush();
bbs.writeTo(response.getOutputStream());
}
}
> Date: Fri, 4 Mar 2016 12:58:02 +0100
> Subject: Re: Performance regression from 7 to 8
> From: r...@apache.org
> To: users@tomcat.apache.org
>
> 2016-03-04 12:42 GMT+01:00 Mark Thomas :
>
> > On 04/03/2016 11:17, Tullio Bettinazzi wrote:
> > > This servlet reproduces the problem perfectly.
> >
> > Getting better but still some room for improvement.
> > - You don't need to implement doPost()
> > - You don't need to call System.gc() (or if you do look there for
> > the problem)
> >
>
> Yes, it's on every get and will cause a major concurrency issue.
>
>
> > - You do need to remove the use of the ComunicationChannelHttp and
> > Cronometro classes (and if that fixes the problem look there
> > for the root cause)
> > - The try/catch in doGet() should not be necessary either
> >
>
> Also writing individual bytes is more costly even if there's some buffering.
>
> Rémy
>
> >
> > Mark
> >
> > > package axioma.rubik.engine.web.servlet;
> > >
> > > import java.io.*;
> > > import javax.servlet.ServletException;
> > > import javax.servlet.annotation.WebServlet;
> > > import javax.servlet.http.*;
> > > import axioma.rubik.engine.web.ComunicationChannelHttp;
> > > import it.axioma.rubik.engine.Cronometro;
> > >
> > > @WebServlet(name="Test8", description="Direct update of data",
> > urlPatterns={"/Test8"})
> > > public class Test8Servlet extends HttpServlet {
> > >
> > > private static final long serialVersionUID = 1L;
> > >
> > > @Override
> > > protected void doPost(HttpServletRequest request,
> > HttpServletResponse response) throws ServletException, IOException {
> > > this.doGet(request,response);
> > > }
> > >
> > > @Override
> > > protected void doGet(HttpServletRequest request, HttpServletResponse
> > response) throws ServletException, IOException {
> > > try {
> > > fai(response);
> > > System.gc();
> > > } catch (Exception ex) {
> > > ex.printStackTrace();
> > > }
> > > ComunicationChannelHttp.CONTEXT_MANAGER.clean();
> > > }
> > >
> > > public void fai(HttpServletResponse response) {
> > > Cronometro crono = new Cronometro();
> > > ByteArrayOutputStream bbs = new ByteArrayOutputStream();
> > > BufferedOutputStream bos = new BufferedOutputStream(bbs);
> > > try {
> > > for(int i = 0; i < 40; i++) {
> > > bos.write(96);
> > > }
> > > bos.flush();
> > > System.out.println("Step 1 : "+crono.elapsed());
> > > bbs.writeTo(response.getOutputStream());
> > > System.out.println("Step 1 : "+crono.elapsed());
> > > } catch (IOException ex) {
> > > ex.printStackTrace();
> > > }
> > > }
> > >
> > > }
> > >
> > >
> > >> Subject: Re: Performance regression from 7 to 8
> > >> To: users@tomcat.apache.org
> > >> From: ma...@apache.org
> > >> Date: Fri, 4 Mar 2016 10:38:30 +
> > >>
> > >> On 04/03/2016 10:24, Tullio Bettinazzi wrote:
> > >>> The problem is all in this small piece of code
> > >>> ByteArr
RE: Performance regression from 7 to 8
This servlet reproduces the problem perfectly.
package axioma.rubik.engine.web.servlet;
import java.io.*;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.*;
import axioma.rubik.engine.web.ComunicationChannelHttp;
import it.axioma.rubik.engine.Cronometro;
@WebServlet(name="Test8", description="Direct update of data",
urlPatterns={"/Test8"})
public class Test8Servlet extends HttpServlet {
private static final long serialVersionUID = 1L;
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
this.doGet(request,response);
}
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
try {
fai(response);
System.gc();
} catch (Exception ex) {
ex.printStackTrace();
}
ComunicationChannelHttp.CONTEXT_MANAGER.clean();
}
public void fai(HttpServletResponse response) {
Cronometro crono = new Cronometro();
ByteArrayOutputStream bbs = new ByteArrayOutputStream();
BufferedOutputStream bos = new BufferedOutputStream(bbs);
try {
for(int i = 0; i < 40; i++) {
bos.write(96);
}
bos.flush();
System.out.println("Step 1 : "+crono.elapsed());
bbs.writeTo(response.getOutputStream());
System.out.println("Step 1 : "+crono.elapsed());
} catch (IOException ex) {
ex.printStackTrace();
}
}
}
> Subject: Re: Performance regression from 7 to 8
> To: users@tomcat.apache.org
> From: ma...@apache.org
> Date: Fri, 4 Mar 2016 10:38:30 +
>
> On 04/03/2016 10:24, Tullio Bettinazzi wrote:
> > The problem is all in this small piece of code
> > ByteArrayOutputStream bbs = new ByteArrayOutputStream();
> > BufferedOutputStream bos = new BufferedOutputStream(bbs);
> > trans.eseguiTrasformazioneOut(bos);
> > try {
> > bos.flush();
> > initReponse(xpFileTypeOut.getMimeType(), xpFilename);
> > bbs.writeTo(getOutputStream());
> > } catch (IOException ex) {
> > Messaggi.getErrori().getLogger().error("Errore in emettiFile ",
> > ex);
> > }
> > The yellow instruction take 100 ms in Tomcat7, quite stable on all clients,
> > in Tomcat8 it takes from 50 ms to 4500 ms stable on a single client PC but
> > very different from client to client.
> > Tks
> > Tullio
>
> I'll repeat what I said previously:
>
> Try creating the *simplest possible* web application that demonstrates the
> problem.
>
> Mark
>
> >
> >> Subject: Re: Performance regression from 7 to 8
> >> To: users@tomcat.apache.org
> >> From: ma...@apache.org
> >> Date: Fri, 4 Mar 2016 09:42:22 +
> >>
> >> On 04/03/2016 09:39, Tullio Bettinazzi wrote:
> >>> I applied tour suggestion and analyzed, with firebug, the composition of
> >>> the time.
> >>> The difference between 7 and 8 is the "receiving" time which is more or
> >>> less zero in 7 and 2sec. in 8.
> >>> How can I understand such difference ?
> >>
> >> Try creating the simplest possible web application that demonstrates the
> >> problem.
> >>
> >> Mark
> >>
> >>
> >>> Tks
> >>> Tullio
> >>>
> >>>
> >>> P.S. : same server, same client, same network, same code both 7 and 8
> >>> installed from scratch
> >>>
> >>>> Subject: Re: Performance regression from 7 to 8
> >>>> To: users@tomcat.apache.org
> >>>> From: geor...@mhsoftware.com
> >>>> Date: Thu, 3 Mar 2016 09:30:33 -0700
> >>>>
> >>>>
> >>>>
> >>>> On 3/3/2016 4:06 AM, Tullio Bettinazzi wrote:
> >>>>> I've an application in which I write a page from a Buffered Stream
> >>>>> directly to the Servlet output stream (more or less 300kb).
> >>>>>
> >>>>> In 7 it works perfectly (100ms).
> >>>>>
> >>>>> In 8 , depending from the network connection and mainly from the
> >>>>> http client itself (the browser in the PC) the same operation takes from
> >>>>> 50ms to 4500 ms.
> >>>>
> >>>> One of the things I would look at is the browse
RE: Performance regression from 7 to 8
The problem is all in this small piece of code
ByteArrayOutputStream bbs = new ByteArrayOutputStream();
BufferedOutputStream bos = new BufferedOutputStream(bbs);
trans.eseguiTrasformazioneOut(bos);
try {
bos.flush();
initReponse(xpFileTypeOut.getMimeType(), xpFilename);
bbs.writeTo(getOutputStream());
} catch (IOException ex) {
Messaggi.getErrori().getLogger().error("Errore in emettiFile ", ex);
}
The yellow instruction take 100 ms in Tomcat7, quite stable on all clients, in
Tomcat8 it takes from 50 ms to 4500 ms stable on a single client PC but very
different from client to client.
Tks
Tullio
> Subject: Re: Performance regression from 7 to 8
> To: users@tomcat.apache.org
> From: ma...@apache.org
> Date: Fri, 4 Mar 2016 09:42:22 +
>
> On 04/03/2016 09:39, Tullio Bettinazzi wrote:
> > I applied tour suggestion and analyzed, with firebug, the composition of
> > the time.
> > The difference between 7 and 8 is the "receiving" time which is more or
> > less zero in 7 and 2sec. in 8.
> > How can I understand such difference ?
>
> Try creating the simplest possible web application that demonstrates the
> problem.
>
> Mark
>
>
> > Tks
> > Tullio
> >
> >
> > P.S. : same server, same client, same network, same code both 7 and 8
> > installed from scratch
> >
> >> Subject: Re: Performance regression from 7 to 8
> >> To: users@tomcat.apache.org
> >> From: geor...@mhsoftware.com
> >> Date: Thu, 3 Mar 2016 09:30:33 -0700
> >>
> >>
> >>
> >> On 3/3/2016 4:06 AM, Tullio Bettinazzi wrote:
> >>> I've an application in which I write a page from a Buffered Stream
> >>> directly to the Servlet output stream (more or less 300kb).
> >>>
> >>> In 7 it works perfectly (100ms).
> >>>
> >>> In 8 , depending from the network connection and mainly from the
> >>> http client itself (the browser in the PC) the same operation takes from
> >>> 50ms to 4500 ms.
> >>
> >> One of the things I would look at is the browser debug window. Open the
> >> debugger, and go to the Networks/Timings tab and load both pages. That
> >> would give some insights as to what's happening. Perhaps it is the page.
> >> Perhaps there's something else.
> >>
> >>>
> >>> On the same PC I find more or less the same time using Chrome and Firefox
> >>> also changing network connections (wifi, lan, adsl).
> >>>
> >>> Could someone suggest a solution ?
> >>>
> >>> Tks
> >>> Tullio
> >>>
> >>
> >> --
> >> George Sexton
> >> *MH Software, Inc.*
> >> Voice: 303 438 9585
> >> http://www.connectdaily.com
> >
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
RE: Performance regression from 7 to 8
I applied tour suggestion and analyzed, with firebug, the composition of the time. The difference between 7 and 8 is the "receiving" time which is more or less zero in 7 and 2sec. in 8. How can I understand such difference ? Tks Tullio P.S. : same server, same client, same network, same code both 7 and 8 installed from scratch > Subject: Re: Performance regression from 7 to 8 > To: users@tomcat.apache.org > From: geor...@mhsoftware.com > Date: Thu, 3 Mar 2016 09:30:33 -0700 > > > > On 3/3/2016 4:06 AM, Tullio Bettinazzi wrote: > > I've an application in which I write a page from a Buffered Stream directly > > to the Servlet output stream (more or less 300kb). > > > > In 7 it works perfectly (100ms). > > > > In 8 , depending from the network connection and mainly from the > > http client itself (the browser in the PC) the same operation takes from > > 50ms to 4500 ms. > > One of the things I would look at is the browser debug window. Open the > debugger, and go to the Networks/Timings tab and load both pages. That > would give some insights as to what's happening. Perhaps it is the page. > Perhaps there's something else. > > > > > On the same PC I find more or less the same time using Chrome and Firefox > > also changing network connections (wifi, lan, adsl). > > > > Could someone suggest a solution ? > > > > Tks > > Tullio > > > > -- > George Sexton > *MH Software, Inc.* > Voice: 303 438 9585 > http://www.connectdaily.com
RE: Performance regression from 7 to 8
So many questions. The JVM is the same 1.8.0_65. The server is the same and empty (nobody is working on it except me) The network connection is the same (same cable, same client same browser) but different client exhibits a constant behaviour in 7 and a very variable behaviour in 8 (but on the same client is stable). What do you mean with test setup ? I use my application as test. No Apache in front, directly calling Tomcat. Memory tuned ? no tuning at all raw, standard installations for both 7 and 8. Tks Tullio > From: tom...@olafkock.de > Subject: Re: Performance regression from 7 to 8 > To: users@tomcat.apache.org > Date: Thu, 3 Mar 2016 14:24:54 +0100 > > Tullio, > > just checking: > * Have you isolated this to be a tomcat 7 vs 8 issue or could it also be > a same-time change of the JVM? Network connection? Caching? > * What's the test setup that you're using? Memory tuned? Apache in > front? HTTP connector? AJP? > > Olaf > > Am 03.03.2016 um 12:06 schrieb Tullio Bettinazzi: > > I've an application in which I write a page from a Buffered Stream directly > > to the Servlet output stream (more or less 300kb). > > > > In 7 it works perfectly (100ms). > > > > In 8 , depending from the network connection and mainly from the > > http client itself (the browser in the PC) the same operation takes from > > 50ms to 4500 ms. > > > > On the same PC I find more or less the same time using Chrome and Firefox > > also changing network connections (wifi, lan, adsl). > > > > Could someone suggest a solution ? > > > > Tks > > Tullio > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
Performance regression from 7 to 8
I've an application in which I write a page from a Buffered Stream directly to the Servlet output stream (more or less 300kb). In 7 it works perfectly (100ms). In 8 , depending from the network connection and mainly from the http client itself (the browser in the PC) the same operation takes from 50ms to 4500 ms. On the same PC I find more or less the same time using Chrome and Firefox also changing network connections (wifi, lan, adsl). Could someone suggest a solution ? Tks Tullio
