Tag Cloud
Currently Reading
Latest Book Reviews
- Rancher Deep Dive Posted on March 31, 2023
- Leveraging Kustomize for Kubernetes Manifests Posted on March 24, 2023
- Automating Workflows with GitHub Actions Posted on October 13, 2022
- Deep-Dive Terraform on Azure Posted on August 30, 2022
- Effective DevOps Posted on January 5, 2022 All Book Reviews
Latest Posts
- User creations in Solaris 11 Posted on April 13, 2013
- OSSEC agent install issue on Debian Squeeze Posted on April 9, 2013
- ZFS on Linux: Stability Issues Posted on April 1, 2013
- PHP: XCache performance testing Posted on March 27, 2013
- Apache Stress Testing Posted on March 25, 2013
April 13, 2013
User creations in Solaris 11
by Alpha01
To my surprise Solaris 11 does not create new user’s home directory by default.
Errors
root@solaris:~# su - testuser
su: No directory!
root@solaris:~# pwck
[....]
testuser:x:106:10::/export/home/testuser:/usr/bin/bash
Login directory not found
Fix
root@solaris:~# useradd -m testuser
80 blocks
In the process, I learned something new about the su command. In Linux, when switching from root to a limited user, I used to do the following:
[root@rubyninja ~]# su tony -
What I did not know was that the above command will indeed load up the PATH of tony, but it will also append root’s PATH at end of it which is kind of scary. In theory the command that I wanted to use was su - username, luckily this feature is not supported in Solaris 11.
root@solaris:/# su testuser -
bash: /root/.bashrc: Permission denied
solaris April 9, 2013
OSSEC agent install issue on Debian Squeeze
by Alpha01
So the OSSEC installer has a conditional expression that doesn’t seem to be supported with the version of Bash in Debian Squeeze.
Error
3- Configuring the OSSEC HIDS.
./install.sh: 158: [[: not found
Fix (workaround)
Update line 372 on install.sh to the following:
if [ "X${USER_AGENT_SERVER_IP}" = "X" -a "X${USER_AGENT_SERVER_NAME}" = "X" ]; then
This was so frustrating, and it appears to be known issue. Unless I’m mistaken double brackets are only used in Bash to do a regular expression conditions, at least that’s the only time I’ve used them…
UPDATE: I also ran into this same issue on FreeBSD 9 and Ubuntu Server 12.04 LTS.
Resources
Tags: [ubuntu security freebsd April 1, 2013
ZFS on Linux: Stability Issues
by Alpha01
So far I’ve had one stability issue on my backup virtual machine. Though, I can’t really blame ZFS for crashing my VM, instead I believe this was a consequence the VM running out of memory due to large amount of rsync, and the heavy I/O caused on the ZFS drive.
After updating the dedicated memory on my backup VM from 512 MB to 3.5 GB and updating my rsync’s to run with low process and I/O priority, I have yet experience any more problems.
nice -n 19 ionice -c 3
zfs March 27, 2013
PHP: XCache performance testing
by Alpha01
Aside APC, as far as I know XCache is the second most popular PHP caching optimizer. So I manually compiled and installed XCache on my www.rubyninja.org VM and configured the WordPress W3 Total Cache plugin to use the XCache optimizer and ran the same benchmarks test that I did when APC was enabled.
After a few tests, the total requests per second was around 24-25 seconds. Slightly slower than APC. However, unlike APC, I noticed that with XCache the overall server load was less (peak at about 3.3), in addition the I/O system activity also appeared to be less than with APC.
Concurrency Level: 5
Time taken for tests: 40.740110 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1000
Total transferred: 351000 bytes
HTML transferred: 0 bytes
Requests per second: 24.55 [#/sec] (mean)
Time per request: 203.701 [ms] (mean)
Time per request: 40.740 [ms] (mean, across all concurrent requests)
Transfer rate: 8.39 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 6 134.1 0 3000
Processing: 99 196 25.6 200 297
Waiting: 98 196 25.6 199 297
Total: 99 202 136.9 200 3209
Percentage of the requests served within a certain time (ms)
50% 200
66% 209
75% 214
80% 216
90% 222
95% 227
98% 234
99% 241
100% 3209 (longest request)
php apache wordpress March 25, 2013
Apache Stress Testing
by Alpha01
As I didn’t have anything much better to do a Sunday afternoon, I wanted to get some benchmarks on my Apache VM that’s hosting my blog www.rubyninja.org. I’ve used the ab Apache benchmarking utility in the past to simulate high load on a server but have not used it on benchmarking Apache in detail.
My VM has a single shared Core i5-2415M 2.30GHz CPU with 1.5 GB of RAM allocated to it.
I based made my benchmarks using a total of 1000 requests with 5 concurrent requests at a time.
ab -n 1000 -c 5 http://www.rubyninja.org/index.php
Results
Using just the mod_pagespeed Apache module enabled.
Time taken for tests: 154.687976 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1000
Total transferred: 351000 bytes
HTML transferred: 0 bytes
Requests per second: 6.46 [#/sec] (mean)
Time per request: 773.440 [ms] (mean)
Time per request: 154.688 [ms] (mean, across all concurrent requests)
Transfer rate: 2.21 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 3
Processing: 328 772 46.4 772 1040
Waiting: 327 771 46.4 772 1040
Total: 328 772 46.4 772 1040
Using mod_pagespeed and APC enabled.
Time taken for tests: 41.355400 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1000
Total transferred: 351000 bytes
HTML transferred: 0 bytes
Requests per second: 24.18 [#/sec] (mean)
Time per request: 206.777 [ms] (mean)
Time per request: 41.355 [ms] (mean, across all concurrent requests)
Transfer rate: 8.27 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 6 134.1 0 3000
Processing: 88 199 28.4 202 459
Waiting: 88 199 28.4 201 459
Total: 88 205 137.2 202 3208
Using the WordPress W3 Total Cache plugin configured with Page, Database, Object, and Browser cache enabled the APC caching method and mod_pagespeed.
time taken for tests: 37.750269 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Non-2xx responses: 1000
Total transferred: 351000 bytes
HTML transferred: 0 bytes
Requests per second: 26.49 [#/sec] (mean)
Time per request: 188.751 [ms] (mean)
Time per request: 37.750 [ms] (mean, across all concurrent requests)
Transfer rate: 9.06 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 5 133.9 0 2996
Processing: 74 181 26.6 185 315
Waiting: 74 181 26.6 184 314
Total: 74 187 136.4 185 3178
As you can see, APC is the once caching method that makes a huge difference. Without APC, the server response time was just 6.46 requests per second and the load average peaked at about 12, while with the default APC configuration enabled, the server response time was 24.18 requests per second, with a load average peaking about 3. Adding the W3 Total Cache WordPress plugin helped performance slightly more, from 24.18 requests per second to 26.49 requests per second (load was about the same, including I/O activity). One interesting thing that I noticed is that with caching enabled, that is APC, the I/O usage spiked considerably. Most notably, MySQL was the high cpu usage process when doing the benchmarks. Since the caching is based in memory at this point it appears that the bottleneck in the web application is MySQL.
Tags: [apache php wordpress