If the “curl_loader” tool is used to load test a website that is available through HTTPS (TLS / SSL) and if certificate chain verification is required then you would need to update the source and recompile. Note that curl_loader utilizes libcurl that generally is powered by OpenSSL API. In steps:
- Open the loader.c file
- Search for “SSL_VERIFY_PEER” in loader.c file
- Replace and add the following code:
curl_easy_setopt (handle, CURLOPT_SSL_VERIFYPEER, 1);
curl_easy_setopt (handle, CURLOPT_SSL_VERIFYHOST, 2);
// this is the location of the foile that holds the CA certificate that would be trusted by the underlying curl protocol stack
curl_easy_setopt (handle, CURLOPT_CAINFO, "chain.pem");
// Specify the cipher-suite as an environment variable.
char *cipherString = getenv("CIPHER_STRING");
curl_easy_setopt (handle, CURLOPT_SSL_CIPHER_LIST, cipherString);
And that is it.
I was interested in figuring out the time taken for a HTTP SSL handshake and the following file download time and after a discussion with colleagues decided in utilizing ssldump.
The ssldump utility can either read the output of tcpdump or could simply be set to listen on a particular interface as well. Some examples follow:
Listen on the Loopback interface “lo”:
Note that if the client and server are on the same machine then this is what you might need to do.
Listen on a particular interface:
It could also read the generated output of tcpdump:
ssldump -r tcp1 [here tcp1 is the file that was generated
as a result of running tcpdump]
However if you have network traffic captured as a result of running tcpdump and running ssldump on it leads to “ERROR: Length mismatch” message, then one needs to increase the packet capture size. This is what I did for a quick check:
tcpdump -nnvvXSs 0 -w tcp1 [write to file tcp1]
Here the value “0” is assocated with the “snarflen” (-s) argument and it implies that we “use the required length to catch whole packets” (from the man page of tcpdump).
For ssldump troubleshooting, please refer to:
To use a later version of Python to what the RPM is available for, one needs to build and install it.
This is what I did and it was a breeze to get that to up:
[I am installing in this folder]</li>
And that is it. If you run into issues, one can always start from scratch by running:
<li>./configure -h [to print out the help]</li>
and then continue with the 3 steps that were outlined earlier viz.
./configure [Specify options to fine tune the deployment]
There are a myriad of tools and scripts that one runs on Linux to figure out the important question of how much free memory is left viz. “how much RAM is available?”.
And to answer the query, we use the following 3 tools that are almost guaranteed to be on all Linux systems and some Unix variants:
The following command line demonstrates the invocation of the “free” command to display the amount of free and used physical and swap memory in the system in megabytes – borrowing the description from the man pages.
$ free -m
total used free shared buffers cached
Mem. 3887 3731 155 0 314 1171
-/+ buffers/cache: 2245 1641
Swap: 501 0 501
Free memory => free + buffers + cached = 155 + 314 + 1171 = 1640 =~ 1641 [the value in 3rd row. 4th col]
---- removed the top two lines from brevity -----
Mem: 3980704k total. 3821604k used, 159100k free. 321752k buffers
Swap: 514040k total. 368k used. 513672k free. 1199916k cached
Free memory => 159100k + 321752k + 1199916k = 1680768k =~ 1641M (this is the value that we arrived at from the “free” coammand above]
Using vmstat with the ‘s’ switch to display the memory statistics, we have the following:
$ vmstat -s
3980704 total memory
3823000 used memory
2604536 active memory
791544 inactive memory
167704 free memory
322028 buffer memory
1201220 swap cache [This is the swap that has been loaded
into RAM - it is not the ‘cache from the output of top.
It is RAM that was swapped out but is now back in RAM]
514040 total swap
368 used swap
513672 free swap
1185336 non-nice user cpu ticks
3479 nice user cpu ticks
345953 system cpu ticks
2193981008 idle cpu ticks
361097 I0-wait cpu ticks
27842 IRQ cpu ticks
65187 softirq cpu ticks
0 stolen cpu ticks
9239003 pages paged in
43636292 pages paged out
8 pages swapped in
94 pages swapped out
2617332222 CPU context switches
1344272629 boot time
Free memory => free memory + buffer memory + swap cache = 157704 + 322028 + 1201220 = 1680952 = 1641.554M =~ 1640M
The paths to discovering memory statistics are many but they ultimately lead to the same figures.
The following query will get the space (on disk) being utilized by a table. This would include space for that table in all tablespaces that the table data is persisted to.
SELECT sum( bytes)/1024/1024 size_in_MB
WHERE (segment_name = :1
OR segment_name in (
WHERE table_name = :1
WHERE table_name = :1
Here: “:1″ => name of table.
Note that a table maps to segments.
Individual db objects such as tables, indexes are stored in segments that are collections of extents which in turn are comprised of contiguous data blocks. If an extent runs out of space then another extent (a datablock in that extent) is made available and that may not be contiguous.
A table can have many segments associated with it – one could be for the table, another for one of the indexes defined on the table and so on. Partitioned tables have system generated indexes as well.
A data block size is usually 8192 bytes.
To get size of a table broken down according to the tablespaces, a different set of queries are used. This could happen if table columns are persisted into different tablespaces. For instance: column 1 in tablespace 1 and so on.
To get those nos, you would have to repeat the following for the table, each index in that table and so on:
select sum(bytes) from user_segments where segment_name = ‘$1′;
Replace ‘$1′ with name of table or the name of the indexes defined on it.