FreeLAMP.com

FreeLAMP.com ��Ƶ��

�� — 2008-10-19

��ھ��Ҫ�� Zope + SquishDot �ϵļܹ��ˡ�

��ľ��°��Ƶ��µ��¡� Ȼ��µ��޸�Ϊ FreeLAMP.com ��

ϣ��2009�괺��ǰ�ܹ��ɡ�

Zope Error Email ��ܷ��

�� — 2008-07-21

�ں�̨�� maillog ��Ϣ��
Oct 17 22:07:10 freelamp sendmail[14342]: m9HE70S7014342: ruleset=check_mail, arg1=<Zope>, relay=localhost [127.0.0.1], reject=553 5.5.4 <Zope>... Domain name required for sender address Zope

��İ취��޸� DTML Document: standard_error_message

�޸�Ϊ��
<dtml-if "error_type!='NotFound'">

To: Site Administrator <<dtml-var error_email>>
From: Zope System<ZopeATfreelamp.com>
Subject: Zope Problem
MIME-Version: 1.0
Content-Type: text/plain
Error: <dtml-var error_message>
<dtml-if error_type> Error Type: <dtml-var error_type> </dtml-if>
<dtml-if error_value> Error Value: <dtml-var error_value> </dtml-if>
URL: <dtml-var URL>
Address: <dtml-var REMOTE_ADDR>
Agent: <dtml-var HTTP_USER_AGENT>
Request:
<dtml-in "REQUEST.items()" sort>
<dtml-var sequence-key>: <dtml-var sequence-item>
</dtml-in>


</dtml-if>

Solaris 8 Performance Tuning

James C. McPherson — 2008-08-05

�� SOlaris 8 �ģ��Ƕ��̴桱��

When talking about tuning the performance of a UNIX system, sys admins generally work through a number of concepts, such as the current perceived performance, the difference between this level and a desired level of performance, the optimal level claimed by the application vendor, how to measure performance differences, and finally, what to tune and test.

The current perceived level of performance is based on what your users tell you and what you observe in your regular system monitoring. In a networked environment, if you have some users on the end of a 100-Mbit full-duplex connection, and others who are still using 10-Mbit half-duplex, then the 10-Mbit users will always tell you that the system is slow. However, you might have to wait for a serious application overload or resource crunch before the 100-Mbit users complain. There are also copious logfiles and measurable kernel statistics to facilitate system-level monitoring. Some sites also make use of tools such as CA UniCentre TNG, HP OpenView, or Sun��s SunMC to monitor via snmp MIBs. However, these are tools that must be used by competent systems and application administrators and should not be used alone.

The desired level of performance is somewhat different. Benchmarks are sometimes less than useful, but if you are using an application or system from a large vendor, they should have a specific benchmarking group that will replicate your environment and allow you to test realistic loads. You can trust a benchmark done in this manner because it is specifically tailored to your company��s requirements. If you don��t have the time or resources to organize a tailored benchmark, you��ll have to spend extra time doing it yourself. Before you get started, determine what measurements will be valid for your environment and how to obtain them. Also, work with your users in regard to when you can test tuning and monitoring. Keep the users informed of what you are doing so that they can recognize changes and appreciate the value that you provide to them.

How to Measure before and after Performance Differences

To tune effectively, you must first decide what you want to achieve. Here are some tips to consider:

* Determine your criteria for success.
* Log everything, and run Sun Explorer data gatherer every time you make changes in order to keep a snapshot of your system configuration at each point.
* Analyze the logs carefully.
* Measure the changed performance against what you wish to achieve.
* Be methodical.

If you do not already keep a record of system and resource loads, and have no method of monitoring the applications on your system, start simply. You can measure cpu/memory/swap utilization, disk utilization (specifically your application filesystems), and network utilization using standard system tools. Solaris 8 allows you to use the kstat(1M) utility to view various system properties in a variety of output formats. df -k is also useful. You can write scripts to dump these statistics to a file on a periodic basis or use tools such as apache and mrtg1 to give you a regularly refreshed view. A little bit of shell, awk, sed, or Perl will give you lots of numbers to graph.

The most useful monitoring of performance requires frequent and regular snapshots of your system for a period of time that you, your application admins, and users decide is long enough. My rule of thumb is to accrue not less than eight days of monitoring data (preferably including a peak load period) so that you have obvious peaks and troughs to look at. Another aspect of measurement is to survey the users both before and after to determine how they believe performance has changed in the course of the monitoring period. If your performance tuning has resulted in differences that the users cannot perceive, then I would say the performance hasn��t really been tuned. Useful questions to ask include:

* How long did it take to perform a standard task (measured in seconds) at 9am, 12noon, 2pm, 5pm before you started tuning?
* How long does this task take now?
* Do you think that the performance has (improved, stayed the same, become worse) over the past (X) days? (At least a seven-point scale is recommended for this question).

You, the sys admin, also need to measure these standard tasks yourself so that you have a frame of reference for your measurements.

What to Tune and When to Tune It

I/O and Buffers (Including VxVM and VxFS)

The most common target of performance tuning is obviously I/O, and in Solaris there are several buffers and tunables that we can work on. You are probably aware of the relative speeds of disks versus ram, and how this difference in speed has changed dramatically over the past 20 years. This is particularly important when configuring ��virtual memory�� for your server because of the way Solaris implements paging2. A primary concern here is to avoid paging data to your slow disk (even a 10000-rpm fcal disk is still slow) and ensure that the data stays in ram until it is sent down the SCSI or tcp stack to the next appropriate point.

How does one prevent paging? This question requires an appreciation of ��good�� and ��bad�� paging. So-called ��good�� paging happens when the system allocates or reclaims pages from a process, whereas ��bad�� paging is when this allocation relies upon a disk device and the system incurs a penalty for access. So, we don��t particularly care about the ��good�� paging, because the intelligence built into the kernel��s paging algorithms ensure that it happens as infrequently as possible. The priority_paging setting is necessary for Solaris 2.6 and Solaris 7. Neither Solaris 8 or 9 require this, because a modified version of priority_paging, called the cyclic page cache, was integrated into the new kernel. ��Bad�� paging is also known as swapping, and in extreme circumstances can result in such a high I/O load that your I/O subsystem is said to be thrashing.

You must specifically be aware of two tunables: ncsize and lotsfree from the Solaris side. If you are running Veritas Volume Manager (vxvm), then you need to be aware of volkio and friends. If you are running Veritas FileSystem (vxfs), you must carefully tune vxfs:vxfs_ninode and vxfs:vx_bc_bufhwm. I will address each of these variables in turn.

ncsize

The ��nc�� in ncsize refers to the Name Cache, and is used to set the size of the Directory Name Lookup Cache, or dnlc for short. This is an optimization to give you better performance from your filesystems because inodes are cached in memory and only flushed out of the cache to disk if they have been idle for quite a while. The default setting for ncsize depends on two other variables, max_nprocs and maxusers with the following relationship:

ncsize = (4 * (max_nprocs+maxusers)) + 320
max_nprocs = 10 + (16 * maxusers)
maxusers = physmem - 2

Setting maxusers to less than the maximum possible value of 2048 used to be a required configuration task going back to SunOS 4.x. However, Solaris 2.x does not require maxusers to be set, and you can actually decrease the performance of your system by doing so. If maxusers is set to the system default, you might not have a very large dnlc. The recommendation is first to set maxusers to 2048, reboot, and after about a week of average usage, examine the kernel statistics on the dnlc (scroll forward to the line starting with dnlcstat). Under both Solaris 8 and 9, you can use the kstat(1M) utility. When looking at these statistics, note the value of misses/hits and see how close that ratio is to 0. The closer it is to 0, the less you need to worry about tuning ncsize. For example, my workstation (an Ultra80) has been up for about 36.5 days, and has this output from kstat -m unix -n dnlcstats:

module: unix instance: 0
name: dnlcstats class: misc
crtime 63.090334184
...
hits 141141001
misses 1953220
negative_cache_hits 2070966
pick_free 802468
pick_heuristic 1102434
pick_last 257563
...
snaptime 3162130.15322328 (ends here)

In my case, this works out to be 0.01383, meaning that my dnlc efficiency is very good. On a major fileserver that I use, the values are considerably different:

module: unix instance: 0
name: dnlcstats class: misc
crtime 180.496237386
...
hits 313301011
misses 77458379
negative_cache_hits 14429400
pick_free 3664314
pick_heuristic 51820181
pick_last 24067557
snaptime 6143454.64953917 (ends here)

Here, the ratio works out to be 0.2472, indicating that there is only about a 75% efficiency of the dnlc for this server, so ncsize should be tuned upwards. For the system above, I would recommend that the dnlc size be doubled. It is currently set to the system-calculated default of 139488, which for this E420R running in 64-bit mode takes up slightly more than 8.7mb of kernel memory 3. The system can easily afford double this amount of kernel memory for dnlc, given its workload.

lotsfree

This variable is used as the boundary condition for when to invoke the page scanner and make it look for pages to free. Typically, this is set to 1/64th the number of physical pages in your system, which works reasonably well. However, as the Kernel Tunable Parameters Manual indicates, if your system load is such that it cannot cope with sudden sharp increases in demand for memory, then you should seriously consider increasing this value. A general rule I��ve seen recommended is to set lotsfree to be 1/16th of the physmem value, rather than the default 1/64th. This allows the page scanner to activate in a more timely manner. When combined with priority paging or the cyclic page cache of Solaris 8, you should see that the memory load curve of your system is much smoother than before.

Veritas FileSystem Variables �� vxfs:vxfs_ninode and vxfs:vx_bc_bufhwm

These two variables are particularly important to tune. These have an interdependency on ncsize that is related to their usage of kernel memory. When you use Veritas FileSystem (VxFS), you must tune ncsize to be within 50% and 80% of the value of vxfs:vxfs_ninode in order to achieve good performance. Good performance in this context means that the performance curve of CPU cycles and memory used stays relatively close to the performance curve algorithm that Veritas builds into the product.

The upper limit on the amount of kernel memory that VxFS will allocate for its cache is set with vxfs:vx_bc_bufhwm �� the Buffer Cache��s Buffer High Water Mark. Once the allocated amount reaches this limit, VxFS inodes are flushed from the cache. The vxfs:vxfs_ninode variable is the limit on the number of VxFS inode structures held in memory. This number is usually determined to be 125% of the value of ncsize for reasons of CPU cycle efficiency, and if you have your dnlc set by way of setting maxusers to 2048, then ncsize/vxfs:vxfs_ninode is approximately 0.78. This is very close to the 80% figure mentioned in the VxFS installation guide.

Veritas Volume Manager Variables

Many sites use Veritas Volume Manager (VxVM) to provide data protection and enhance their systems�� performance. Mirrored filesystems, striped data filesystems, and RAID-5 filesystems are all features that VxVM provides. If you use VxVM as well as VxFS, then you should look at vxio:vol_maxio. This variable controls the maximum size of io requests that are sent down the SCSI chain without breaking the request up. Veritas recommends that this tunable not exceed 20% of kernel memory or physical memory (whichever is smaller), and that you match this tunable to the size of your widest stripe. Apart from this tunable, there are no others that must be tuned, and you should only really look at tuning the variables specified in the Veritas Volume Manager Administrator Guide if you are directed to by an appropriate technical contact within Veritas or a Veritas partner. This is because Veritas, like Sun with Solaris, has spent a lot of time and effort in making sure that the self-tuning algorithms work well for the vast majority of systems. If you are fortunate enough to have the sort of large installation where serious VxVM tuning is necessary, then you should engage Veritas or Sun Professional Services to analyze and tune your configuration.

Shared memory, Semaphores, Message Queues

Applications such as rdbms engines (Oracle, Sybase, Informix, DB2, etc.), middleware like MQ-Series and Tuxedo, and some backup packages (Veritas NetBackup) make heavy use of shared memory, semaphore sets, and message queues in order to maximise their performance. For configuring these settings, you should always start with the application vendor��s recommendations, and find out from the vendor how they log a deficiency in these settings. Veritas NetBackup, for example, will dump messages in logfiles like:

waited for empty buffer X times or
waited for full buffer Y times

which in conjunction with the NetBackup Troubleshooting guide will indicate whether you need more semaphores or message queues.

Remember that the kernel will not allow more than 25% of the dedicated kernel space (segkp) to be allocated for the shared memory, message queue, and semaphore structures. So, if you experiment with large values on a machine without much physical memory, you may see different values when you check with the sysdef(1M) utility after rebooting. For my workstation (see the ��System Specification File�� sidebar), the kernel memory usage under Solaris 8 (64-bit mode) for the example semaphore settings is approximately 15898 Kb, for the message queues approximately 1038 Kb, and for the shared memory itself, approximately 18 Kb. You might be wondering why the overhead for shared memory (shmsys) settings is so small compared with the semaphore (semsys) and message queue (msgsys). That is because the only variable used for administrative purposes with shmsys is shminfo_shmmni. This is the maximum number of shmid_ds structures in the system, each of which is 88 bytes.

The rule of thumb for shared memory, semaphores, and message queues is to tune these in conjunction with your application vendor, because the vendor will have concrete customer data and can advise you appropriately.

SCSI tunables

sd_max_throttle and sd_io_time

Two very common tuning targets are those that relate to the SCSI disk (sd) driver module: sd_max_throttle and sd_io_time. You commonly see these set (or need to set them) if you are using EMC, IBM, or Hitachi storage attached to your Solaris system. The sd_io_time variable is the limiter on how long an I/O can be outstanding before an error condition is returned. The Solaris default is 60 seconds (0x3c), but this is often set to 31 seconds (0x1f). The variable sd_max_throttle provides the limit on how many outstanding I/Os the system can handle at any one time and is commonly referred to as the ��queue depth.�� A common setting for this (the default is 256 or 0x100) is 25, which is the mandated setting from JNI Corporation for use with their fcaw driver4 and EMC5 or Hitachi storage6.

The general recommendation for both these variables, however, is that if you are not required to set them by your storage vendor, then leave them unset in your /etc/system file and let Solaris handle the settings for you. This is because these variables cannot be set on a per-LUN or per-instance basis: any change made to these two variables affects the entire SCSI subsystem. If you set them to values greater than or much less than your storage subsystem can handle, you run a very real risk of having a badly performing system for disk, tape, and memory operations. Another important aspect to tuning the sd driver is that Sun��s disk storage attaches using either the sd or, if attached using the Fibre Channel (FC) protocol, the ssd drivers. This allows for separate tuning of those stacks, but could well change in a later version of Solaris.

maxphys

The maxphys setting, often seen in conjunction with JNI and Emulex HBAs, is the upper limit on the largest chunk of data that can be sent down the SCSI path for any single request. There are no real issues with increasing the value of this variable to 8 Mb (in /etc/system, set maxphys=8388608), as long as your IO subsystem can handle it. All current Fibre Channel adapters are capable of supporting this, as are most ultra/wide SCSI HBAs, such as those from Sun, Adaptec, QLogic, and Tekram. It is possible (although I have not yet tested it) to set this variable in an (E)IDE-based system, such as a PC running Solaris for Intel, a Sun Ultra 5/10/Blade 100, or the lower end Netra systems. With the current range of (E)IDE disks and at least an ATA-66 interface, the system should be able to support this value for maxphys.

Networking Tunables

At a former employer, I worked closely with the DBAs on a particular system running a financial management application. After monitoring the system for several weeks, the first step in tuning was to get a 100-Mbit switched interface activated. When this 100FDX interface was connected, we noticed an immediate improvement in system performance: less swap in use due to less buffering of data, fewer ��wasted�� cpu cycles, and a much happier group of users. The change was so significant that we put off implementing the rest of the tuning while we analyzed whether our plan was still relevant. We did not need to do any specific configuration on our server because the switch handled it.

If you need to force your interface, there are several simple ways to do this. To begin, you must be absolutely certain that your Ethernet interface is cabled to plug into a 100-Mbit Ethernet switch, otherwise you will not get any response from your network connection. Let��s look at the two most common methods: an rc script and editing /etc/system.

The boot-time rc script allows you to specify which instance of the interface you want to change the settings for. In the example below, I am setting the properties for my qfe3 interface:

#!/bin/sh
#
# script to force the interface properties for qfe3
# script name is /etc/rc2.d/S50ndd_qfe3
#
ndd -set /dev/qfe instance 3
# force OFF 100Mb half duplex
ndd -set /dev/qfe adv_100hdx_cap 0
# force OFF 100Mb T4
ndd -set /dev/qfe adv_100T4_cap 0
# force ON 100Mb full duplex
ndd -set /dev/qfe adv_100fdx_cap 1
# force OFF autonegotiation (FORCE mode)
ndd -set /dev/qfe adv_autoneg_cap 0
# end of script

Here��s the /etc/system modification method:

set qfe:adv_100hdx_cap=0
set qfe:adv_100T4_cap=0
set qfe:adv_100fdx_cap=1
set qfe:adv_autoneg_cap=0
set qfe:adv_10hdx_cap=0

This method sets all of your qfe interfaces to operate at 100FDX, and if that��s what your switch is configured to do, then you are ready to reboot and enjoy the benefits.

Of the two methods, I recommend using a boot-time rc script. It��s easier to maintain if you write it correctly (because it uses the Bourne shell), and you don��t have to worry about testing by way of a reboot because a quick unplumb/plumb followed by ndd(1m) allows you to make changes while your system is up and running. The /etc/system method is also useful, but given that you cannot really tune each instance separately using this method, it may not be appropriate for every site.

�� ntfs-3g ��д��ʽ�ҽ� USB �ƶ�Ӳ��ϵ� NTFS ��

�� — 2008-07-21

��̳ ��Ǹ��Ƽ��ĵط��˼·�� MSS ��ӣ��ͨ�� Linux ��а汾��Ҳ��н��ֵ��

��裺

�� MSS ��Ҫ�ñ��Լ��޸Ĺ��ںˣ�ͨ�� fuse ��

insmod fuse.o

��װ ntfs-3g

��ƶ�Ӳ�̣��ϵͳ�Զ��ҽӣ��
umount /foreign_shares/NTFS Ȼ�� ntfs-3g �ҽ� �ƶ�Ӳ��:
# ntfs-3g /dev/scsi/host1/bus0/target0/lun0/part1 /foreign_shares/NTFS

��汾��
fuse kernel 2.5.3
ntfs-3g 1.2531

ͨ��ַ�ʽ�ҽӺ󣬲��д��ԭ��ļ��Ҳӭ�ж��⡣

�� loop filesystem �ҽ� ext3 ��ʽ�ļ�ϵͳ�� reiserfs ��

�� — 2008-07-13

Maxtor Shared Storage (MSS) ��һ�� Linux �ĺ��ӡ��ҽ� IDE Ӳ�̺�Ĭ�ϸ�ʽΪ reiserfs ��

�� rtorrent ��ش�� 4GB ��ļ�ʱ��ȷ��Ҫʹ�� ext3 �� Ȼ��Ӳ��ʶ��һ��ķ��취��ڵ�ǰ�� reiserfs ��ͨ�� loop filesystem ��ҽӡ�

��˼·��⻯�ķ��к��ã��˵�ǽ��Ķ��ˡ�

��岽��£�

׼��

�� insmod ��Ҫʹ�õ��ļ��ģ�鵽�ںˣ� loop64.o ext2.o ext3.o jbd.o ��װ�� e2fsprogs

1. ��ļ�ϵͳ�� /sbin/reiserfsck /dev/ide/host2/bus0/target0/lun0/part3

2. �޸��ļ�ϵͳ��СΪ 1GB��/sbin/resize_reiserfs -s 1G /dev/ide/host2/bus0/target0/lun0/part3

3. ��Ҫ�� ext3 �ļ�ϵͳ�� /opt/sbin/losetup -o 1084227584 /dev/loop/0 /dev/ide/host2/bus0/target0/lun0/part3

1084227584 �� 1GB �� 10MB��

4. �� ext3��/opt/sbin/mkfs.ext2 -b 4096 -j -r 0 /dev/loop/0

��ȥ�� -j ��Ȼ��У�/opt/sbin/tune2fs -j /dev/loop/0 ת��Ϊ ext3

5. ��ԣ�mount -t ext3 /dev/loop/0 /mnt

˼·��ԣ� ��̳

�� Fedora 9 ��Ϊ Lighttpd ��װ mod_geoip

�� — 2008-06-28

GEOIP ��һ��ͻ� IP �͵��λ�ö�Ӧ��ϵ��ݿ⡣�� Web Server �Ͽ��ĳЩ��ҵķ��ʡ� ��Ȼ��ʹ�õ��ж�Ҳ��һ��Ӽ򵥵İ취��Ҳ��
��װ�Ĺ��ʵʮ�ּ򵥣�
��ƪ��Ҳֻ��ȼ��С�

http://www.howtoforge.com/installing-mod_geoip-for-lighttpd-on-fedora9

��˼·��ǿ��Խ��ġ�

�� Linux �ϰ�װ Socks Server 5

�� — 2008-06-15

��Ҫ��ĵط��ܶ࣬�и��Լ��Ĵ��Ȼ�á� Apache �� Squid ��Ե��Ƕ��ǡ�רҵ��ġ�

ԭ��и� socks5 �ĳ�� NEC �� sf.net ��רҵ�� ss5 ��ء�
Ĭ�� ./configure;make;make install �� /etc/opt/ss5 �� ss5.conf �ļ��Բο��

# grep -v ^# /etc/opt/ss5/ss5.conf
ע�� u ��ӡ�� Open Proxy �Ļ��鷳�ˡ�

auth 0.0.0.0/0 - u
permit u 0.0.0.0/0 - 0.0.0.0/0 - - - - -

��Ļ��man ss5.conf Ҳ��ѧϰ��
��԰� tarball �ļ��Ŀ¼�µ� conf �� ss5.passwd �� /etc/opt/ss5 �£��Ϊ��֤�ļ�� ÿ��һ��û�� + �ո� + ����磺��
billgates password

��
/usr/sbin/ss5 -b ipaddress:port

�ܺ��õ� ss5.

�� Zope �� 2.7.7 ��OS �� RHEL 5 ��

�� — 2008-06-15

�ܳ�ʱ��û�в�� Zope �ˡ� �м�Ĺ��Ҳ�Ǻ��˼�ġ�

RHEL �� SELinux ��ɫ��˼��
Zope ��Ҫ�ض�� Python �汾��ס�
�� Zope �Ĺ��
./configure --prefix=/opt/Zope2.7.7
make
make install
mkzopeinstance.py

��Լ��Ҫ�޸� $INSTANCE_HOME/etc �µ� zope.conf
�� Zope:

su - Zope -c "$INSTANCE_HOME/bin/zopectl start"

ps -Zef �ض� Zonename �Ľ��취

�� — 2007-10-18

Solaris 10 �� ZONE ��㼼��ս��Ӧ�á��ɽ�� ps -Zef ��ʾ�� ZONE Name �İ취��
ps -Zef ֻ��ʾ 8 ��ַ�� zonename �� ֻ�� ps -o ��ʾ�İ취��ʾ�� zonename ��⡣

# ps -ef -o user,zone,nlwp,stime,args

�Ż� PHP �� 40 ��С��

�� — 2007-10-16

ժ�ԣ� http://reinholdweber.com/?p=3

40 Tips for optimizing your php Code

1. If a method can be static, declare it static. Speed improvement is by a factor of 4.
2. echo is faster than print.
3. Set the maxvalue for your for-loops before and not in the loop.
4. Unset your variables to free memory, especially large arrays.
5. Avoid magic like __get, __set, __autoload
6. require_once() is expensive
7. Use full paths in includes and requires, less time spent on resolving the OS paths.
8. If you need to find out the time when the script started executing, $_SERVER[��REQUEST_TIME��] is preferred to time()
9. See if you can use strncasecmp, strpbrk and stripos instead of regex
10. str_replace is faster than preg_replace, but strtr is faster than str_replace by a factor of 4
11. If the function, such as string replacement function, accepts both arrays and single characters as arguments, and if your argument list is not too long, consider writing a few redundant replacement statements, passing one character at a time, instead of one line of code that accepts arrays as search and replace arguments.
12. Error suppression with @ is very slow.
13. $row[��id��] is 7 times faster than $row[id]
14. Error messages are expensive
15. Do not use functions inside of for loop, such as for ($x=0; $x < count($array); $x) The count() function gets called each time.
16. Incrementing a local variable in a method is the fastest. Nearly the same as calling a local variable in a function.
17. Incrementing a global variable is 2 times slow than a local var.
18. Incrementing a object property (eg. $this->prop++) is 3 times slower than a local variable.
19. Incrementing an undefined local variable is 9-10 times slower than a pre-initialized one.
20. Just declaring a global variable without using it in a function also slows things down (by about the same amount as incrementing a local var). PHP probably does a check to see if the global exists.
21. Method invocation appears to be independent of the number of methods defined in the class because I added 10 more methods to the test class (before and after the test method) with no change in performance.
22. Methods in derived classes run faster than ones defined in the base class.
23. A function call with one parameter and an empty function body takes about the same time as doing 7-8 $localvar++ operations. A similar method call is of course about 15 $localvar++ operations.
24. Surrounding your string by ' instead of " will make things interpret a little faster since php looks for variables inside "..." but not inside '...'. Of course you can only do this when you don't need to have variables in the string.
25. When echoing strings it's faster to separate them by comma instead of dot. Note: This only works with echo, which is a function that can take several strings as arguments.
26. A PHP script will be served at least 2-10 times slower than a static HTML page by Apache. Try to use more static HTML pages and fewer scripts.
27. Your PHP scripts are recompiled every time unless the scripts are cached. Install a PHP caching product to typically increase performance by 25-100% by removing compile times.
28. Use memcached - memcached is a high-performance memory object caching system intended to speed up dynamic web applications by alleviating database load
29. Use ip2long() and long2ip() to store IP addresses as integers instead of strings in a database. This will reduce the storage space by almost a factor of four (15 bytes for char(15) vs. 4 bytes for the integer), make it easier to calculate whether a certain address falls within a range, and speed-up searches and sorts (sometimes by quite a bit).
30. Partially validate email addresses by checking that the domain name exists with checkdnsrr(). This built-in function checks to ensure that a specified domain name resolves to an IP address. A simple user-defined function that builds on checkdnsrr() to partially valid email addresses can be found in the user comments section in the PHP docs. This is handy for catching those occasional folks who think their email address is ��joeuser@wwwphp.net�� instead of ��joeuser@php.net��.
31. If you��re using PHP 5 with MySQL 4.1 or above, consider ditching the mysql_* functions for the improved mysqli_* functions. One nice feature is that you can use prepared statements, which may speed up queries if you maintain a database-intensive website. Some benchmarks.
32. Learn to love the ternary operator.
33. If you get the feeling that you might be reinventing the wheel during a project, check PEAR before you write another line. PEAR is a great resource that many PHP developers are aware of, yet many more are not. It��s an online repository containing over 400 reusable snippets that can be dropped right into your PHP application. Unless your project is trully unique, you ought to be able to find a PEAR package that saves at least a little time. (Also see PECL)
34. Automatically print a nicely formatted copy of a page��s source code with highlight_file().This function is handy for when you need to ask for some assistance with a script in a messageboard, IRC, etc. Obviously, some care must be taken not to accidently show your source when it contains DB connection information, passwords, etc.
35. Prevent potentially sensitive error messages from being shown to users with the error_reporting(0) function. Ideally error reporting should be completely disabled on a production server from within php.ini. However if you��re on a shared webhost and you aren��t given your own php.ini, then your best bet is to add error_reporting(0); as the first line in each of your scripts (or use it with require_once().) This will prevent potentially sensitive SQL queries and path names from being displayed if things go awry.
36. Use gzcompress() and gzuncompress() to transparently compress/decompress large strings before storing them in a database. These built-in functions use the gzip algorithm and can compress plaintext up to 90%. I use these functions almost everytime I read/write to a BLOB field within PHP. The only exception is when I need full text indexing capabilities.
37. Return multiple values from a function with ��by reference�� parameters. Like the ternary operator, most PHP developers who come from a more formalized programming background already know this one. However, those who��s background is more HTML than Pascal, probably have wondered at one time ��how do I get multiple values back from a function I wrote, even though I can only use one return value?�� The answer is that you precede a variable with ��&�� and use it ��by reference�� instead of ��by value��.
38. Fully understand ��magic quotes�� and the dangers of SQL injection. I��m hoping that most developers reading this are already familiar with SQL injection. However, I list it here because it��s absolutely critical to understand. If you��ve never heard the term before, spend the entire rest of the day googling and reading.
39. When working with strings and you need to check that the string is either of a certain length you'd understandably would want to use the strlen() function. This function is pretty quick since it's operation does not perform any calculation but merely return the already known length of a string available in the zval structure (internal C struct used to store variables in PHP). However because strlen() is a function it is still somewhat slow because the function call requires several operations such as lowercase & hashtable lookup followed by the execution of said function. In some instance you can improve the speed of your code by using a isset() trick.

Ex.
if (strlen($foo) < 5) { echo "Foo is too short"; }
vs.
if (!isset($foo{5})) { echo "Foo is too short"; }

Calling isset() happens to be faster then strlen() because unlike strlen(), isset() is a language construct and not a function meaning that it's execution does not require function lookups and lowercase. This means you have virtually no overhead on top of the actual code that determines the string's length.
40. When incrementing or decrementing the value of the variable $i++ happens to be a tad slower then ++$i. This is something PHP specific and does not apply to other languages, so don't go modifying your C or Java code thinking it'll suddenly become faster, it won't. ++$i happens to be faster in PHP because instead of 4 opcodes used for $i++ you only need 3. Post incrementation actually causes in the creation of a temporary var that is then incremented. While pre-incrementation increases the original value directly. This is one of the optimization that opcode optimized like Zend's PHP optimizer. It is a still a good idea to keep in mind since not all opcode optimizers perform this optimization and there are plenty of ISPs and servers running without an opcode optimizer.
41. Excellent Article about optimizing php by John Lim

�Ͱ汾 Client �� MySQL 4.1 ��ϰ汾�Ŀ��

�� — 2007-08-20

һ�㶼�� tarball ��ķ�ʽ��װ LAMP��һ�� RHES 4.1 �� Red Hat �ϰ�װ�� MySQL ��ɾ��ϵ� 4.1.20 �汾�󣬰�װ�� MySQL ��վ�ϵ�

MySQL-server-standard-4.1.22-0.rhel4.i386.rpm
MySQL-client-standard-4.1.22-0.rhel4.i386.rpm
MySQL-devel-standard-4.1.22-0.rhel4.i386.rpm

MySQL ��ˣ� ��ԭ�� php-mysql ȴ��֧�� PHP �ˡ�
ֻ��ͨ�� rpmfind ��

php-mysql-4.3.11-2.8
php-pear-4.3.11-2.8
php-4.3.11-2.8

PHP �� MySQL ֧�֣��ǳ��´��

Client does not support authentication protocol requested by server; consider upgrading MySQL client

��İ취��ǣ�

mysql> set PASSWORD FOR 'miska'@'localhost' = OLD_PASSWORD('muska');

�� Binary �� rpm ��װ��Щ ��Щ LAMP ��ȷʵ�鷳��

==== ��Ҫ�õ��һЩ rpm ��
��Ѿ��װ�� PHP ��

#rpm -qa|grep -i php
php-mysql-4.3.11-2.8
php-pear-4.3.11-2.8
php-4.3.11-2.8

ǿ��ɾ�� rpm -e --nodeps php-4.3.11-2.8
��װ�� rpm -ivh php-mysql-4.3.11-2.8.i386.rpm

��ļ��
rpm -qil php-4.3.11-2.8

/etc/httpd/conf.d/php.conf
/etc/pear.conf
/etc/php.d
/etc/php.ini
/usr/bin/php
/usr/lib/httpd/modules/libphp4.so
/usr/lib/php4
/usr/share/doc/php-4.3.11
/var/lib/php
/var/lib/php/session

sendmail ��

�� — 2007-06-22

һ��Ĭ�ϰ�װ�Ժ�Ĳ��ϵͳ�� sendmail ��һ��Ը��У��ܼ��õ��Ҫ�޸ĵĲ��
1. DaemonPortOptions �޸� sendmail �� ַ�Ͷ˿ڣ��޸� HELO ��֡�

http://www.sendmail.org/~gshapiro/8.10.Training/DaemonPortOptions.html

2.MX list for hostname points back to hostname

http://www.sendmail.org/faq/section4.html#4.5

3. /etc/aliases ��붨��

MAILER-DAEMON: root
postmaster: root
nobody: /dev/null

http://www.unet.univie.ac.at/aix/aixbman/commadmn/ml_alias.htm

ȡ��PHP��е� short_open_tag

�� — 2007-06-11

һЩ�ϵ� PHP ��򣬲�� short_open_tag ��
<?
��ͷ�� PHP ��
<?php

��취�� Perl �� pie ��䣬һ�д��޸��е� short_open_tag Ϊ��׼ tag.

# find . -name "*.php" |xargs perl -pi -e 's/\<\?$/\<\?php/g'

�޸��ɺ󣬲�Ҫ��޸� php.ini ��

short_open_tag = Off

Ȼ�� Apache

# bin/apachectl graceful

��֤�޸��Ƿ��ȷ��

�� Sun �� AMP ��(Cool Stack) ��Լ�� Blog ��

�� — 2007-05-31

��Щ��һ��ϲ��Լ��ֵ��˵��Ҫ֪��Ǹ�ʲô�ģ��֪��ľ��ص�ַ�ˡ�

Sun �� Cool Stack ��Ͽ��Դ��أ�
http://cooltools.sunsource.net/coolstack/

Cool Stack �� Sun �Ż��Ժ��һ�׿��Դ��ϣ��°汾 1.1 ��

* CSKamp. �� Apache2, MySQL5 �� PHP5
* CSKmysql. ��Ҫ�� 64 λ�� MySQL��밲װ��
* CSKperl. ��˺ܶ� Perl ��չ
* CSKphplibsBundle. ��Ҫ PHP ��չ�Ļ��Ҫ��װ�ð�
* CSKmemcached. memcached, �ֲ�ʽ��󻺳�ϵͳ
* CSKruby. �� ruby, rubygems and rails.
* CSKsquid. �� Squid Web Proxy Cache.
* CSKtomcat. �� Apache Tomcat

��Ľ�ͨ��ܰ�װ WordPress 2.0 �Ĺ��Զ� Cool Stack �бȽ��ϸ��˽⡣

��Ľ��ܵ��Ҫ Solaris 10 ��ϵͳ��֧�֡�

1��أ�
# mkdir /var/tmp/CoolStack
# cd /var/tmp/CoolStack
# ftp ftp.sunfreeware.com
user:ftp
password:youremail@yourcompany.com
cd /pub/freeware/CSK/
bin
get CSKamp_x86.pkg.bz2
get CSKmysql_x86.pkg.bz2
bye

2��װ��
# bunzip2 CSKamp_x86.pkg.bz2 CSKmysql_x86.pkg.bz2
# pkgadd -d CSKamp_x86.pkg.bz2
# pkgadd -d CSKmysql_x86.pkg

3�� Apache
# vi /opt/coolstack/apache2/conf/httpd.conf

�޸�� Web Server ��û��
�޸� ServerName
�޸� ServerAdmin
�޸� DirectoryIndex Ϊ
DirectoryIndex index.html index.php
�� # /opt/coolstack/apache2/bin/apachectl start
��д��󣬲鿴 ErrorLog:
# tail -100f /opt/coolstack/apache2/logs/error_log

��ԭ�Ȱ�װ�� Sun �� Apache ��
# svcadm disable apache2
# svcadm refresh apache2

Ȼ��Ƴ��İ��ѡ��
SUNWapchd
SUNWapchu
SUNWapchr
SUNWapch2d
SUNWapch2u
SUNWapch2r
SUNWaclg

4�� PHP
�� Web Ŀ¼�½��һ�� test.php
<?php
phpinfo()?
?>
��ļ�� Web Server Name Ϊ freelamp.com��
��룺 http://freelamp.com/test.php Ӧ�û��ʾ PHP �ı��ȡ�

5�� MySQL
�� # isainfo -b ��Ƿ� 64 λ
��64 �� MySQL Ŀ¼Ϊ /opt/coolstack/mysql��32�Ļ��Ϊ�� /opt/coolstack/mysql_32bit

�� mysql �û��
#groupadd mysql;useradd -g mysql mysql

��װ��ʼ��ݿ⣺
# $MYSQL_DIR/bin/mysql_install_db
# chown -R mysql $MYSQL_DIR/var
��
# $MYSQL_DIR/bin/mysqld_safe &

��ʧ�ܣ�� $MYSQL_DIR/var Ŀ¼�µ� `hostname`.err �ļ�
# tail -100f `hostname`.err

6��ز��װ WordPress
��أ�
# cd /var/tmp
# wget http://wordpress.org/latest.tar.gz

��ѹ��
# cd /opt/coolstack/apache2/htdocs
# gzcat /var/tmp/latest.tar.gz|tar xf -

��ļ��
# cd wordpress
# mv wp-config-sample.php wp-config.php
# vi wp-config.php
define('DB_NAME', 'wordpress'); // The name of the database
define('DB_USER', 'wordpress'); // Your MySQL username
define('DB_PASSWORD', 'wordpress'); // ...and password

��ݿ⣺
�� MySQL ��У�
# /opt/coolstack/mysql/bin/mysql -uroot
mysql> create database wordpress
mysql> grant all on wordpress.* to wordpress@localhost identified by 'wordpress';

�� Web ��ã�
http://freelamp.com/wordpress/
��ݿ��û�д��Ļ��ϵͳ��ʾ�� install.php ��װ��ݣ�
��װ�ɹ��󣬼�¼ admin ��¼��ɹ��Լ�� Blog �ˡ�

Sun �� Cool Stack ��Ϊ��۵�Ӧ��Ǿ��Ż�� MySQL 64 λ�汾��в��

Apache �ṩ�Ĳ�� worker ģ�飬��ϵ� prefork.c ģ�顣
PHP û��ṩ Zend Optimizer

��¼��

A. ��ݿ��İ汾(32 �� 64)��

bash-3.00# file bin/mysqld
bin/mysqld: ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, not stripped, no debugging information available
bash-3.00# file ../mysql_32bit/bin/mysqld
../mysql_32bit/bin/mysqld: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped, no debugging information available

B.�鿴��ݿ�֧�ֵ��棺

mysql> show engines;
+------------+---------+----------------------------------------------------------------+
| Engine | Support | Comment |
+------------+---------+----------------------------------------------------------------+
| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great performance |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables |
| InnoDB | YES | Supports transactions, row-level locking, and foreign keys |
| BerkeleyDB | NO | Supports transactions and page-level locking |
| BLACKHOLE | NO | /dev/null storage engine (anything you write to it disappears) |
| EXAMPLE | NO | Example storage engine |
| ARCHIVE | YES | Archive storage engine |
| CSV | NO | CSV storage engine |
| ndbcluster | NO | Clustered, fault-tolerant, memory-based tables |
| FEDERATED | NO | Federated MySQL storage engine |
| MRG_MYISAM | YES | Collection of identical MyISAM tables |
| ISAM | NO | Obsolete storage engine |
+------------+---------+----------------------------------------------------------------+

C.�鿴 Apache ��ģ�飺

bash-3.00# /opt/coolstack/apache2/bin/httpd -l
Compiled in modules:
core.c
prefork.c
http_core.c
mod_so.c

��Ҳ�� http://samp.nalai.net/57600

��й� Solaris �ϵ� AMP ��£��ڣ�

http://samp.nalai.net/

FreeLAMP.com

FreeLAMP.com �����Ƶ�������

Zope Error Email ���ܷ���

Solaris 8 Performance Tuning

�� ntfs-3g ��д��ʽ�ҽ� USB �ƶ�Ӳ���ϵ� NTFS ����

�� loop filesystem �ҽ� ext3 ��ʽ�ļ�ϵͳ�� reiserfs ��

�� Fedora 9 ��Ϊ Lighttpd ��װ mod_geoip

�� Linux �ϰ�װ Socks Server 5

���� Zope �� 2.7.7 ��OS ������ RHEL 5 ��

ps -Zef �ض� Zonename �Ľ���취

�Ż� PHP ����� 40 ��С����

�Ͱ汾 Client ���� MySQL 4.1 ���ϰ汾�Ŀ�������

sendmail ������������������

ȡ��PHP�����е� short_open_tag

�� Sun �� AMP ���(Cool Stack) ��Լ��� Blog ������