I've faced a situation when some of my tests require posting some absolutely unique data. Therefore I need to use __UUID() function.
I was wondering if the usage of this function can create additional load, as apart from doing what the test is supposed to do it generates the guid.
How memory-consuming is this operation, and how 'clean & objective' such a test can be considered in terms of performance analysis?
It should be reasonable as it calls :
UUID.randomUUID().toString()
Of course it uses a bit of memory (JMeter function system + few bytes for UUID)
It think the impact is more related to CPU.
Just monitor your JMeter JVM and check it stays in reasonable limits.
Related
Hi guys I want to run a test ( load test) with almost 200 users. I needed to know the exact hardware configuration I would require like : RAM, disk space, and all.
Can someone help me on this....thanks in Advance.
(P.S : please don't tell me it depends on your user and all I'm new to Jmeter I don't know anything)
Actually it depends on what your test is doing, number of Samplers, number of PreProcessors, PostProcessors, Assertions, request and response size, etc.
Minimal configuration would be:
At least 512KB per thread + around 100 megabytes for JMeter to operate which gives ~100 MB of RAM
At least ~50 MB of disk space (JMeter) + ~400 MB for Java SDK/JRE + how many extra space you need for test data and test results
However only you can get the exact answer by running your actual test and measuring the JMeter's footprint using i.e. JVisualVM or JMeter PerfMon Plugin
Also make sure you're following JMeter Best Practices
#Mehvish It is impossible to say the correct hardware requirement. But, a normal machines of this generation might support it. But, only way to validate is to actually do it.
Please refer this article as it has some good info which might help.
https://sqa.stackexchange.com/questions/15178/what-is-recommended-hardware-infrastructure-for-running-heavy-jmeter-load-tests
I was just doing a 10Million insert benchmark to see the performance of a small cache system I'm building. While observing the Activity Monitor I noticed that the main Go process only shows 100% (of the 800%) CPU.
Do I need to split my loops into routines to make it split up to all 8 cores or is there another reason?
I'm not posting code as the test code is not much more than a loop in a testing function in the main body.
Your application is using only one thread so it's correct that there is only one core that run at 100%.
If you want use more than one core you must use more than one go routine, remeber to set GOMAXPROCS shell enviroment or your application will use only one core.
Remember that it's possible that your application could be even slower using more than one process because if your behaviuor is intrinsically sequential you cannot speed up the application just adding more goroutine. You can take a real advantage of multi threading only if your behaviour is intrinsically parallel.
I have Neo4j 1.9.4 installed on 24 core 24Gb ram (centos) machine and for most queries CPU usage spikes goes to 200% with only few concurrent requests.
Domain:
some sort of social application where few types of nodes(profiles) with 3-30 text/array properties and 36 relationship types with at least 3 properties. Most of nodes currently has ~300-500 relationships.
Current data set footprint(from console):
LogicalLogSize=4294907 (32MB)
ArrayStoreSize=1675520 (12MB)
NodeStoreSize=1342170 (10MB)
PropertyStoreSize=1739548 (13MB)
RelationshipStoreSize=6395202 (48MB)
StringStoreSize=1478400 (11MB)
which is IMHO really small.
most queries looks like this one(with more or less WITH .. MATCH .. statements and few queries with variable length relations but the often fast):
START
targetUser=node({id}),
currentUser=node({current})
MATCH
targetUser-[contact:InContactsRelation]->n,
n-[:InLocationRelation]->l,
n-[:InCategoryRelation]->c
WITH
currentUser, targetUser,n, l,c, contact.fav is not null as inFavorites
MATCH
n<-[followers?:InContactsRelation]-()
WITH
currentUser, targetUser,n, l,c,inFavorites, COUNT(followers) as numFollowers
RETURN
id(n) as id,
n.name? as name,
n.title? as title,
n._class as _class,
n.avatar? as avatar,
n.avatar_type? as avatar_type,
l.name as location__name,
c.name as category__name,
true as isInContacts,
inFavorites as isInFavorites,
numFollowers
it runs in ~1s-3s(for first run) and ~1s-70ms (for consecutive and it depends on query) and there is about 5-10 queries runs for each impression. Another interesting behavior is when i try run query from console(neo4j) on my local machine many consecutive times(just press ctrl+enter for few seconds) it has almost constant execution time but when i do it on server it goes slower exponentially and i guess it somehow related with my problem.
Problem:
So my problem is that neo4j is very CPU greedy(for 24 core machine its may be not an issue but its obviously overkill for small project). First time i used AWS EC2 m1.large instance but over all performance was bad, during testing, CPU always was over 100%.
Some relevant parts of configuration:
neostore.nodestore.db.mapped_memory=1280M
wrapper.java.maxmemory=8192
note: I already tried configuration where all memory related parameters where HIGH and it didn't worked(no change at all).
Question:
Where to digg? configuration? scheme? queries? what i'm doing wrong?
if need more info(logs, configs) just ask ;)
The reason for subsequent invocations of the same query being much faster can be easily explained by the usage of caches. A common strategy is to run a cache warmup query upon startup, e.g.
start n=node(*) match n--m return count(n)
200% CPU usage on a 24 core means the machine is pretty lazy as only 2 cores are busy. When a query is in progress it's normal that CPU goes to 100% while running.
The Cypher statement above uses an optional match (in the 2nd match clause). These optional matches are known as being potentially slow. Check out if runtime changes if you make this a non-optional match.
When returning a larger result set consider that transferring the response is driven by network speed. Consider using streaming in the case, see http://docs.neo4j.org/chunked/milestone/rest-api-streaming.html.
You also should set wrapper.java.minmemory to the same value as wrapper.java.maxmemory.
Another approach for your rather small graph is to switch off MMIO caching and use cache_type=strong to keep the full dataset in the object cache. In this case you might need to increas wrapper.java.minmemory and wrapper.java.maxmemory.
how to measure memory usage on gwan application (each request made)?
for the memory usage consumed by /csp script and /handlers script.
You can use the server_report function.
Check out http://gwan.ch/source/report.c for an example.
To measure the memory consumed by a G-WAN script (either handler or servlet), you will have to consider two things:
code size (see the gwan.log file which dumps it along with an MD5 checksum)
data size (which is dependant on your code so it can only be reported at runtime)
As Paulo suggested it, you can check what every malloc() / calloc() / strdup(), etc. does in your code but you will miss whatever memory used by G-WAN, system or third-party library calls.
The worker thread stack is also dynamically growing when needed... so, unless you know what you do there is no obvious way to precisely check what amount of memory is used by any given script.
I'm using a version of SQL Server 2005 that does not support the profiler, trying to figure out how best to compare the performance of two stored procedures. I've run the execution plan for each, but it's not clear to me which of the provided metrics I should be focusing on. Do I go through and add up the various costs? What's the best approach?
Thanks in advance.
Look at this article: Measuring SQL Performance
If you don't want to register to free account, here is a solution 1:
DECLARE #start datetime, #stop datetime
SET #start = GETDATE()
EXEC your_sp
SET #stop = GETDATE()
2nd:
SET STATISTICS TIME ON
EXEC your_sp
3rd:
SET STATISTICS IO ON
EXEC your_sp
Btw, this site has some nice articles. I'd recommend to register. It's free.
The question is what are you optimizing for? Is it for speed or resources used?
If speed, then in the query analyzer I would look at the execution between several runs, make changes and time them again.
If it is resources then I would look through the execution plan. In that case I would start with the worse offenders and work my way down the list. Adding them up will tell you the over all performance, but most cases it is an item or 2 that is the bottle neck.
if you are using something like
SET SHOWPLAN_ALL ON
look at the TotalSubtreeCost column value for the row with the EXE YourProcedureName
this might help:
http://technet.microsoft.com/en-us/library/ms180765.aspx
Like most questions, the answer depends... In the final analysis, the only measure that matters is end-user perception, which can be affected by many things,including not only the stored procedure, but network performance, usage patterns (is the sProc being called 20x/day, or 1000x/ second?), etc., - and the sProc may not be the determining factor.
But if the stored procedure is the "piece if the puzzle" that is having the major adverse impact on the end-user perception of some function, then, you have to look at elapsed time to run the stored procedure. But this itself can be affected by numerous underlying metrics, and to do anything about it you need to analyse them all to determine which of them is the major or overriding contributer to the overall stored proc performance.
You could always rig a test harness to call your stored procedures and measure the call times. Unfortunately you're not going to get the details about exactly which parts of the Stored Procedure are causing the slow-down.
You could always run the Stored Procedure by hand in Query Analyzer and measure the results that way as well. The .NET harness just automates the process for you.
The simple low-brow solution is to run them with print statements printing the execution time over the various parts. This won't help if the performance problem is more subtle and found in production only, but if you can reproduce it in your test environment, you should be fine.
One handy technique if you are trying to compare the performance of two procs or statements is to select both blocks of sql in query analyzer and run the query plan. The plan will tell you the cost percentage of each block relative to one another. This is not full proof. I have seen it tell me one was cheaper when it was clearly more expensive when actually ran, but for the most part it is a nice, quick trick.