I run this command on ubuntu:
./ab -n 2000 -c 10 http://localhost:7000/index.html
and each time I get a different number for "Time per request".(huge difference like once is 0.66 ms next time is 0.17 ms).
Why is the result unstable and how can I measure the actual performance of the Apache server?
If just the first request is slower than the following and the next results tend to be faster than it´s very likely some kind of cache which speeds up the response. In the simplest case this is just the disk cache of the os.
If you´re benchmarking on a virtual machine you probably will not get very credible results:
http://communities.vmware.com/docs/DOC-5581
Benchmarking, Profiling on Virtual Machines
Here some general best practices for benchmarking web servers:
http://www.cyberciti.biz/tips/howto-performance-benchmarks-a-web-server.html
Related
I am running Apache Guacamole on a Google Cloud Compute Engine f1-micro with CentOS 7 because it is free.
Guacamole runs fine for some time (an hour or so) then unexpectantly crashes. I get the ERR_CONNECTION_REFUSED error in Chrome and when running htop I can see that all of the tomcat processes have stopped. To get it running again I just have to restart tomcat.
I have a message saying "Instance "guac" is overutilized. Consider switching to the machine type: g1-small (1 vCPU, 1.7 GB memory)" in the compute engine console.
I have tried limiting the memory allocation to tomcat, but that didn't seem to work.
Any suggestions?
I think the reason for the ERR_CONNECTION_REFUSED is likely due to the VM instance falling short on resources and in order to keep the OS up, process manager shuts down some processes. SSH is one of those processes, and once you reboot the vm, resource will resume operation in full.
As per the "over-utilization" notification recommending g1-small (1 vCPU, 1.7 GB memory)", please note that, f1-micro is a shared-core micro machine type with 0.2 vCPU, 0.60 GB of memory, backed by a shared physical core and is only ideal for running smaller non-resource intensive applications..
Depending on your Tomcat configuration, also note that:
Connecting to a database is an intensive process.
Creating a Tomcat with Google Marketplace, the default VM setting is "VM instance: 1 vCPU + 3.75 GB memory (n1-standard-1) so upgrading to machine type: g1-small (1 vCPU, 1.7 GB memory) so should ideal in your case.
Why was g1 small machine type recommended. Please note that Compute Engine uses the same CPU utilization numbers reported on the Compute Engine dashboard to determine what recommendations to make. These numbers are based on the average utilization of your instances over 60-seconds intervals, so they do not capture short CPU usage spikes.
So, applications with short usage spikes might need to run on a larger machine type than the one recommended by Google, to accommodate these spikes"
In summary my suggestion would be to upgrade as recommended. Also note that, the rightsizing gives warnings when VM is underutilized or overutilized and in this case, it is recommending to increase your VM size due to overutilization and keep in mind that this is only a recommendation based on the available data.
I have a SVN repository behind an Apache HTTPS server that stores small and large (+1GB) files. When I commit a large file, the transfer speed is about 10MB/sec (using a 1GBit network line). When I look at CPU utilization on the server, it is saturated with about 85% being consumed by apache2, and some 15% by the disk driver.
I have already tried disabling Apache logging and SSL, but that didn't help to improve the transfer speed. This makes me think that mod_dav_svn is using most of the CPU? I have also tried to increase the amount of available cores on the server (default = 1 core), but this mysteriously slows down the commits while httpd remains using 1 core. And setting SVNCompressionLevel 0 also didn't result in any noticeable speed improvement.
Is there any way to significantly increase the transfer speed through parallelization or some other optimization?
Server:
Debian 9.3
Apache 2.4.25
libapache2-mod-svn 1.9.5
svn repository: default FSFS config (i.e. all commented out in fsfs.conf). The HDD can write up to 30Mb/sec (hardware limited) without saturating the CPU (tested with copying). FS is NTFS, using ntfs-3g with big_writes enabled which is using some 10-15% CPU while writing #10MB/sec.
Client:
svn 1.8.13
CPU: first generation Intel Core #3.20Ghz
Obviously, I would be very pleased if I could transfer at 25-30MB/sec.
Is there any way to significantly increase the transfer speed through
parallelization or some other optimization?
Yes, there is. However, the question lacks necessary details about the SVN client and server version, the server's and FSFS repository configuration and the hardware it runs on. It is hard to tell what kind of optimizations will help in your case. You may want to upgrade your server and client to the latest versions and disable the compression in the server's config.
FYI: VisualSVN Server in my tests can deliver 1Gbps speed.
I am trying to understand the difference between iperf (version=2.0.8b) and iperf3 (version=3.15) which are showing different network bandwidths between the two VMs and with same parameters.
When I run "iperf -s" on server and "iperf -c -t 30 -P 8" on client, I get the bandwidth equal to 45 Gb/s.
But, when I run "iperf3 -s" on server and "iperf3 -c -t 30 -P8", I am getting 25 Gb/s as network bandwidth. So, there is a difference of 15Gb/s.
Any idea what could be the cause of this big difference? What are the main differences between iperf and iperf3?
Thanks a lot
NKD
There are a couple of possible reasons for the difference: One is that iperf2 has a multi-threaded design that might very possibly perform better than iperf3 on parallel tests (-P 8). Another is that iperf3's TCP window size might be set too small and you might need to make it larger with the -w option.
More information on the comparative use of iperf2 and iperf3 can be found here:
http://fasterdata.es.net/performance-testing/network-troubleshooting-tools/throughput-tool-comparision/
We're experiencing a strange problem with our current Varnish configuration.
4x Web Servers (IIS 6.5 on Windows 2003 Server, each installed on a Intel(R) Xeon(R) CPU E5450 # 3.00GHz Quad Core, 4GB RAM)
3x Varnish Servers (varnish-3.0.3 revision 9e6a70f on Ubuntu 12.04.2 LTS - 64 bit/precise, Kernel Linux 3.2.0-29-generic, each installed on a Intel(R) Xeon(R) CPU E5450 # 3.00GHz Quad Core, 4GB RAM)
The 3 Varnish Servers have a pretty much standard, vanilla cfg: the only thing we changed was the vcl_recv and vcl_fetch in order to handle the session cookies. They are currently configured to use in-memory cache, but we already tried switching to HDD cache using an high-performance Raid Drive with the same exact results.
We had put this in place almost two years ago without problems on our old web farm, and everything worked like a blast. Now, using the machines described above and after a clean reinstall, our customers are experiencing a lot of connection problems (pending request on clients, 404 errors, missing files, etc.) when our websites are under heavy traffic. From the console log we can clearly see that these issues start happening when each Varnish reaches roughly 700 request per seconds: it just seems like they can't handle anything more. We can easily reproduce the critical scenario at any tme by shutting down one or two Varnish Servers, and see how the others react: they always start to skip beats everytime the req per seconds count reaches 700. Considering what we've experienced in the past, and looking to the Varnish specs, this doesn't seem to be normal at all.
We're trying to improve our Varnish servers performances and/or understand where the problem actually is: in order to do that, we could really use some kind of "benchmark" from other companies who are using it in a similar fashion in order to help us understand how far we are from the expected performances (I assume we are).
EDIT (added CFG files):
This is our default.vcl file.
This is the output of varnishadm >param.show output console cmd.
I'll also try to post a small part of our varnishlog file.
Thanks in advance,
To answer the question in the headline: A single Varnish server with the specifications you describe should easily serve 20k+ requests/sec with no other tuning than increasing the number of threads.
You don't give enough information (vcl, varnishlog) to answer your remaining questions.
My guess would be that you somehow end up serialising the backend requests. Check out your hit_for_pass objects and make sure they have a valid TTL set. (120s is fine)
I'm thinking of getting my own dedicated server with the following stats:
Processor: Celeron 440 2.0 GHz
Memory: 1 GB
Primary Hard Drive : 160 GB SATA II
This will be running Windows. I have some experience with my local IIS and playing around with servers, but I have never set one up (at least a Windows one) and I've never dealt with DNS/backup/security issues.
My question has two parts:
Will this server be able to run Windows 2008, SQL Server, and possible Exchange on it without trouble. I'm worried about the processor and RAM.
Are there any guides/tutorials that talk about how to admin a windows server from start to finish. (I'm looking for something like the FAQs slicehost has for *nix based servers).
You WILL run into a problems with RAM. Refer to MS documentation and minimum requirements (SQL Server and Exchange). Also please mind that new releases of Exchange run only on 64bit systems.
Personally I would recommend installing CORE version of W2K8 if you plan to go with your described configuration.
It depends from user load. If you have about 1k unique users / month this means that probably, you will have 30 users per day - roughly 1 per hour. I think you will use more CPU working on this computer personally. So it really depends from user load.
If I were you, I would add more RAM to have something about 4 GB. RAM is the cheapest upgrade available.
You state "I've never dealt with DNS/backup/security issues."
I would suggest to you that these are the most important issues. You need to stay on top of security, applying security patches, insuring firewalls are properly configured etc.
Having been called after the fact for websites that have been hacked, I can tell you it is not pretty. Learn all you can before you stand up this server on the internet.