Monthly Archives: July 2015

Understanding Citrix Performance Issues

Bottleneck: provisioning services. Customers note there is excessive Network I/O and CPU utilization.
Bottleneck: vDisk fragmentation or server virtual instances. Customer notes there is excessive page file utilization and disk I/O.
Bottleneck: delays mounting new vDisks. Check for excessive Network and Disk I/O on delivery controllers.
Bottleneck: delivery controllers. Check for excessive historical CPU utilization.
Bottleneck: slow application enumeration. Check for excessive disk and network I/O on the data collectors.
Bottleneck: slow session creation noted within the director console: Check for historical CPU and Memoyr consumption, consider adding VCPU and memory when/where needed.
Bottleneck: higher than expected user logons. Check for high CPU and/or network utilization (not historical but may trend at random intervals). Add processing or new delivery controller if necessary to handle the expected loads.
Bottleneck: issues with local host cache (LHC). Disk and Page File I/O in excess can cause unanticipated issues with LHC. Alert and adjust when/where needed.
Bottleneck: Processor intensive apps. Check questionable servers for larger disk I/O and page file utilization. Consider adding more VCPU’s and/or memory to offset the demand on disk and page file.
Bottleneck: vDisk and/or Provisioning Services. Check for higher than normal CPU and/or Memory consumption as a deficiency will slow down the loading of vDisks and caching via Provisioning Services (PVS).
Bottleneck: Web interface authentication. Consider adding more memory and looking at network utilization trends. It may be necessary to either add more memory or to add an additional WI to your GSLB URL.
Bottleneck: slow PXE and vDisk. Check for memory and/or network utilization and consider addresssing depending on noted trends.
Bottleneck: target device latency. Check CPU and network I/O for spikes and/or trending issues.

use unix socket instead of tcp connection for memcached to speed up web servers

By default, memcached is listening on port 11211 for all connections. But for a single server, it’s better to config memcached to use unix socket which improve the performance and reduce the legacy.

On freebsd, it’s easy to change from TCP/IP to unix socket. But there are some steps you need to pay more attention.

1. Modify rc.conf to force memcached to use unix socket.

memcached_flags="-m 2048 -s /tmp/memcached.sock"

2. Modify the connection string in your php files.
For TCP connection, use

$_config['memory']['memcache']['server'] = '127.0.0.1';
$_config['memory']['memcache']['port'] = 11211;

If you are using php-memcache, you should change it to

$_config['memory']['memcache']['server'] = 'unix:///tmp/memcached.sock';
$_config['memory']['memcache']['port'] = 0;

If you are using php-memcached, you should change it to

$_config['memory']['memcache']['server'] = '/tmp/memcached.sock';
$_config['memory']['memcache']['port'] = 0;

3. Another thing I found in Freebsd is that if you force memcached to use unix socket, every time you restart the service, memcached will change the socket file permission to 550 which means php can’t connect to the socket file. So you need to grant php user access to that file.

chmod 777 /tmp/memcached.sock

You need to do this each time after you restart memcached.