Posted by stoyan
via DebianHelp
...Disabling the TCP options reduces the overhead of each TCP packet and might help to get the last few percent of performance out of the server. Be aware that disabling these options most likely decreases performance for high-latency and lossy links.
net.ipv4.tcp_sack = 0
net.ipv4.tcp_timestamps = 0
Increasing the TCP send and receive buffers will increase the performance a lot if (and only if) you have a lot of large files to send.
net.ipv4.tcp_wmem = 4096 65536 524288
net.core.wmem_max = 1048576
If you have a lot of large file uploads, increasing the receive buffers will help.
net.ipv4.tcp_rmem = 4096 87380 524288
net.core.rmem_max = 1048576
Posted by stoyan
Test Driven Development (TDD) has you define the behaviour of your system by writing small tests that precisely define some small piece of your system’s behaviour. Then you implement that behaviour. Then you clean up and improve your design…It is no surprise that it takes beginners some time to get to the understanding that TDD isn’t about testing at all...if they ever do.
How true!!! Until today I didn’t pay much attention to the TDD. Like most people my opinion was “Why to lose time for testing my small programs. Some day…on bigger project…maybe”. Oh no…I was sooo far from the true. But I’m going to change…
Everything started from a post in the Dave Astel’s blog: A New Look at Test Driven Development . He explain very well my and maybe other people’s confusion about TDD – all these Test class names, trying to test every class and method (1-1 relationship) etc. In the same post he is proposing a new look on the same problem – writing specifications of what your code will have to do. The name for this new look is Behaviour Driven Development . It’s already implemented in Ruby – the RSpec framework . For bad luck there is still not good Rails support in it.
So on first time I’ll start with the old, but well supported rails testing framework. A very good starting point: Putting REST on Rails – step by step REST implementation. The article itself is better to be tryed with Rails 1.0, because Rails 1.1 way for implementing REST is different and seems easier. But the flow of creating the application is good. I’ll try to follow it.
Posted by stoyan
Found via Rails Tips , link point to TextDrive weblog
- Minimize the amount of FCGI listeners
- Use caching
- NEVER run “development” on FastCGI for more than 1-2 hours
- Observe your memory consumption
- Rotate your logs
- Write and run unit tests
- Check for memory leaks when you are developing
- Be careful with iterations
- Watch the Rails TRAC for bug reports
- Be vigilant when restarting your server
Use RailsHelp for quick searching through the Rails API docs.
Posted by stoyan
Q: I am experiencing a heavy slowdown of the entire dom0 and all other domUs if one domU gets under heavy load.Is there any way to tighten this domU by adjusting something like scheduling?
A: You can use elevator=cfq as the command line option for both the dom0 and domU kernels in grub.conf and /etc/xen domU config files respectively. This will force the use of cfq as the default scheduler. By default anticipatory is the scheduler in dom0 and noop in domU. Alternatively:
echo "cfq" > /sys/block/sda/queue/scheduler
Posted by stoyan
New post on the ‘RailsExpress’ blog
”...On pages with 25 dates displayed it is approximately 70% faster than the original version. On a page with 1 date, it’s already 6% faster…”
”...If you have pages with a large number of date displays, you might consider this technique to make them a tad snappier…”
Hm, the best candidate for me seems blog index page. Will try.
