I have memcache extensions on apache/php windows 10 (details at the end)
Created a simple test:
$memcache = new Memcache;
$memcache->addServer("ext-memcached.e-memcached.xxx.net",11211);
$memcache->addServer("ext-memcached.e-memcached2.xxx.net",11211);
$memcache->addServer("ext-memcached.e-memcached3.xxx.net",11211);
$key='xxx_54921';
$settings = $memcache->get($key);
print_r ($settings);
the memcache servers are on AWS and they work well (production servers).
This test code works - it retreives the value from the memcache servers.
However if I wait a couple minutes and refresh it will not return value.
Then if I refresh again it will return the value.
The same code/config works from another dev computer.
What can cause this?
Config:
PHP Version 5.6.34
Windows NT SPECTRE 6.2 build 9200 (Windows 8 Home Premium Edition) i586
Build Date Feb 28 2018 17:45:55
Compiler MSVC11 (Visual C++ 2012)
Architecture x86
Memcache extension:
ts x86 version from here:
https://windows.php.net/downloads/pecl/releases/memcache/3.0.8/
memcache info:
memcache support enabled
Version 3.0.8
Revision $Revision: 329835 $
Directive Local Value Master Value
memcache.allow_failover 1 1
memcache.chunk_size 32768 32768
memcache.compress_threshold 20000 20000
memcache.default_port 11211 11211
memcache.hash_function crc32 crc32
memcache.hash_strategy standard standard
memcache.lock_timeout 600 600
memcache.max_failover_attempts 20 20
memcache.protocol ascii ascii
memcache.redundancy 1 1
memcache.session_redundancy 2 2
The memcached service doesn't actually install the PHP memcached extension for you. It only installs the memcached server used to store your cache.
You'll need to download the Windows DLL from the PECL repository first (click on the blue Windows DLL link). Then you must add the extension=php_memcache.dll line to the correct php.ini file for your SAPI. Also, note the extension DLL file needs to be placed in the correct path for your XAMPP installation.
For Apache, simply create a script in your document root with the line
For the CLI SAPI, you can use php.exe --ini to do the same. Again, you may need to rely on the XAMPP package if it has modified your configuration path (since this is a compile time directive).
After making your changes to php.ini you will need to restart PHP for the changes to take effect.
You can refer: https://pureform.wordpress.com/2008/01/10/installing-memcache-on-windows-for-php/
Since you're using PHP 7 on Windows it's probably also important to note that the compiled DLL from PECL may not actually work under apache for Windows, because you're more than likely using a theaded SAPI. So make sure you are downloading the correct version. As far as I can tell that version is only compiled to work with up to PHP 5.6. The github alternative, for PHP 7, available at https://github.com/nono303/PHP7-memcahe-dll as mentioned in the comments is tested under non-thread safe. So you may only be able to get this working for your CLI scripts on Windows.
The problem seems to be more in the way you are writing (set) and getting (get) the data having multiple nodes. - Memcache does not support replication.
Try a single node, in that case, you should be available to get the data just after being set.
When having multiple nodes "sharding" is a common approach to store the data, this means that a logic is implemented in place to determine what server to use for either writing or getting the data:
From https://en.wikipedia.org/wiki/Memcached:
Clients use client-side libraries to contact the servers which, by default, expose their service at port 11211. Both TCP and UDP are supported. Each client knows all servers; the servers do not communicate with each other. If a client wishes to set or read the value corresponding to a certain key, the client's library first computes a hash of the key to determine which server to use. This gives a simple form of sharding and scalable shared-nothing architecture across the servers.
Therefore in PHP client you could try a consistent hashing:
$memcache = new Memcache;
$memcache->setOption(Memcached::OPT_LIBKETAMA_COMPATIBLE, true);
From: http://www.php.net/manual/en/memcached.constants.php
Memcached::OPT_LIBKETAMA_COMPATIBLE
Enables or disables compatibility with libketama-like behavior. When enabled,
the item key hashing algorithm is set to MD5 and distribution is set
to be weighted consistent hashing distribution. This is useful because
other libketama-based clients (Python, Ruby, etc.) with the same server
configuration will be able to access the keys transparently.
Note:
It is highly recommended to enable this option if you want to use
consistent hashing, and it may be enabled by default in future releases.
Also, try:
memcache.hash_strategy = consistent;
Check this post for more details: https://blog.fedecarg.com/2008/12/24/memcached-consistent-hashing-mechanism/
and this answer: https://stackoverflow.com/a/48006009/1135424
Check your
memcache.redundancy memcache.redundancy
setting, your data is not be available on every memcached node. Setting it to 3 should be sufficient in your example case.
Related
I have a Joomla 1.5.10 based Intranet system. In this application, we have more than 80% custom extensions. Below is the configuration:
Apache version : Apache/2.2.22 (Win32) mod_ssl/2.2.22 OpenSSL/0.9.8
PHP version : 5.3.13
MySQL version : mysqlnd 5.1.11
It has 3 dedicated Appliocation Server which configuration is :
Windows Server 2008 Standard Edition Service Pack 2
Compiler: MSVC9 (Visual C++ 2008)
Architecture: x86
Again, it has dedicated DB server which configuration is :
8x Intel(R) Xeon(R) CPU X5460 #3.16GHz, 8.0GB RAM, Windows Server 2008 Standard Edition Service Pack 2.
Below is the MySQL settings in my system:
Sl.# Parameter Value
1 Key Buffer 547M
2 Sort Buffer Size 256K
3 Query cache limit 4M
4 Cache size 350M
5 Long query time 5
6 Interactive timeout 300
7 Max Connection 800
8 Thread cache size 36
We have configured WAMPSERVER (32 BITS & PHP 5.3) 2.2E on our servers and then install MySQL5.1 on other dedicated server. Hence, we are not using MySQL provided with WAMP.
My system become too slow or crash when number of DB connection threads crossed 100. Number of logged-in users we can see are 3000-5000 only. Multiple queries start logging in the slow query logs and huge number of queries are in sleep state. Those queries which are running normal also start logging in slow query log and taking much time in execution.
I am unable to find the bottlenecks in my system. Is there Joomla or MySQL creating bottlenecks. Would upgrade helpful to avoid the bottlenecks and increased the performance of our system? If yes, what should we upgrade - Joomla or MySQL and what will be the strategy to upgrade the system. Is there a known performance/scalability issue in 1.5.10 that is resolved by an upgrade?
My overall goal is to increase the system performance.
Thanks in advance.
First of all as mentioned in my comments, upgrading your CMS to atleast Joomla 1.5.26 will help. You're running PHP 5.3 and only Joomla 1.5.15+ is fully compatible with this PHP version. Seeing as you're using 1.5.10, there will be some issues there.
Apache is not an issue here. There are sites out there running Joomla that have thousands of users and run Aache without any problems, so not to worry about this.
From Joomla 1.6 onwards, the optimization started. Reduced and sorted database tables, endless bug fixes and also security issues. The framework has also improved majorly not to mention it supports PDO, mysqli (more secure than mysql) and postgre. Ugrading to Joomla 3.2 (latest version) will be of course a massive step. You will have to make all your custom extensions compatible with the new Joomla version and keep up to date with the latest coding standards. Even though this is a big step and will of course take some time, it's fully worth it. Joomla 1.5 hasn't been supported for a long time now and things are moving forward majorly.
Your server specs are good, you're running a decent PHP and Apache version, you're MySQL version could be upgraded however it's still not bad. So overall, it's not a server related issue.
I do think that it could very well be the way your custom extensions have been coded. So my final suggest would simply be taking a backup of your site and start migrating it and all of your extensions to Joomla 3.2.
You can change the webserver. Apache is totally bloat. Lighttpd can help to fix the problem. It' also simpler to run. A cms upgrade most likely break something.
PHP 5.5 includes zend opcache by default, which basically means that almost nobody will use APC.
But what to use instead of the user data cache part of APC (apc_store & apc_fetch & similar)?
One use case where I really like to use APC user data cache are "versions" of static assets (javascript, css..). Whenever I reference static file, I add hash of its content into the url (e.g. <script src=/script.js> will became <script src=/script.js?v=hash>), so that browser always uses current version and can cache it permanently.
I can imagine using redis or memcache to store the hashes of static files, but it seems silly to ask another process over network or socket just to get a hash of file content. APC user data cache (which is in shared memory and accessing it is almost as fast as accesing php variable) seems just the right thing to use for such data.
So the question is: what to use in php 5.5 to cache small bits of data instead of APC?
Starting from PHP 5.5 the APC user data storage is packaged separately as PECL APCu.
Source code: http://pecl.php.net/package/APCu
MacOS homebrew package is php55-apcu (brew install php55-apcu)
Debian/ubuntu is called php5-apcu (apt-get install php5-apcu)
Fedora/RedHat is called php-pecl-apcu (yum install php-pecl-apcu)
Windows - use precompiled APCu dll - follow instructions provided in the answer below.
This allows you to use all user cache functions, such as apc_store(). It will also return true for extension_loaded('apc') - this means that all libraries depending on APC will work similarly to PHP 5.4.
I recently dealt with this question after upgrading from php 5.3 to php 5.5 beta 2.
I looked at Memcache and Redis. Depending upon whom you ask, the performance between the two is approximately the same. Some claim that Redis is marginally faster. However, Redis has a lot more features than Memcahe so I decided to go with Redis.
For a PHP client, I chose Phpredis over Predis. Phpredis is a C extension whereas Predis a pure PHP implementation. Thus, Phpredis is generally faster.
I'm primarily using Redis to cache and retrieve serialized objects. I started the project I'm currently developing in PHP 5.3 with APC. I'm continuing to develop the project with php 5.5 and Redis. While I don't have benchmark statistics, I can tell you that the app "feels" faster. This is likely due to performance enhancements in php 5.5 as opposed to APC user cache verses Redis. Either way, I'm happy with my choice.
I hope that helps. Good luck and happy hacking :-)
Nothing more to say. You got the correct answer already. I guess I can provide you with a link to tutorial to how to download and install APCu on XAMPP on Windows for php 5.5 and 5.6:
Link do download APCu for php build from 5.3 and higher:
download APCu different versions
Installation tutorial: installation instructions (The newest version should be on the very bottom of the file list - use this one)
Also bear in mind that you will have two to choose from few options like 64 or 84 version as well as nts or ts and vc9 or vc11 (it can be different in your case) and of course the correct PHP version (in my case that would be PHP 5.6 for my xampp).
EXAMPLE:
if you want to pick right you have to run phpinfo() first and check for those parameters:
Zend Extension Build and Architecture
In my case that would be:
[Zend Extension Build:] API220131226,TS,VC11
[Architecture:] x86
That mean that in my case I would have to choose ACLu wchich contain
in file name those parameters 5.6, TS, VC11, 86
file name to download: php_apcu-4.0.7-5.6-ts-vc11-x86.zip
Hope that clear things up for you.
Some aditional explanations on different PHP builds:
difference ts vs nts:
TS refers to multithread capable builds. NTS refers to single thread only builds. Use case for TS binaries involves interaction with a multithreaded SAPI and PHP loaded as a module into a web server. For NTS binaries the widespread use case is interaction with a web server through the FastCGI protocol, utilizing no multithreading (but also for example CLI).
difference vc9 vs vc11 vs vc14:
More recent versions of PHP are built with VC9, VC11 or VC14 (Visual Studio 2008, 2012 or 2015 compiler respectively) and include improvements in performance and stability.
The VC9 builds require you to have the Visual C++ Redistributable for Visual Studio 2008 SP1 x86 or x64 installed
The VC11 builds require to have the Visual C++ Redistributable for Visual Studio 2012 x86 or x64 installed
The VC14 builds require to have the Visual C++ Redistributable for Visual Studio 2015 x86 or x64 installed
difference 86 vs 64:
The x64 builds of PHP for Windows should be considered experimental, and do not yet provide 64-bit integer or large file support.
Take a look at the XCache opcode cacher, from the authors of lighttpd. It supports both php 5.5 and user data cache: http://xcache.lighttpd.net/wiki/XcacheApi
I didn't try it my self (still using APC and php 5.4).
I'm trying to setup a SVN Server 1.7.5 on my development workstation which has the following tools already working:
Apache Server 2.2.22 (64 bits) - VC10 from Apache Lounge
PHP 5.4.3 VC9-TS (64 bits) from Anindya's Blog
XDebug 2.2.0 VC9 for PHP 5.4.x TS (64 bits) from Xdebug.org
MySQL CE 5.5.24 (64 bits) MSI installer from MySQL Dev. Web Site
NetBeans IDE 7.2 RC1 with JRE 7 update 5 (64 bits) from NetBeans Web Site
Windows 7 Professional Edition (64 bits)
As you can see, all used tools are 64 bits.
My headache starts when I try to include SVN server to the toolset.
Well, before posting this message in this forum, I found many very good SVN solutions for Windows 64 bits such as Visual SVN Server, Subversion Edge from CollabNet and uberSVN from WanDisco. However, all of them install an embedded Apache Server along with SVN Server.
So, as I already have an Apache server working and well configured with all my personal needs, I would totally avoid having two different Apache servers just because of SVN.
I have also searched on the web in order to know whether I could install either VisualSVN or Subversion Edge without their embedded Apache server, but it seems it's not an option.
In my opinion, the only way to use my currently working Apache server is if I could find the SVN binaries for Apache 2.2.22 64bits.
As additional information, also searching many forums on the web, it seems that no SVN 64 bits libraries are released just because there are already good enough free tools in the market for this purpose such as the aforementioned ones. The price is that they also come with the Apache server which I really don't want.
I would fully apreeciate your help in this regard.
Best Regards.
SOLUTION UPDATE
Well, fortunately I managed to find Apache Haus web site. They have available Subversion 64 bits binaries ready to integrate with Apache 64 bits.
The setup process is really simple: Just extract the zip file, copy all contents to bin and modules folders inside Apache folder and configure htdocs.conf properly that you are all set.
As additional information, I also found that in order to have a local SVN setup, I really don't need to have a SVN server at all. The only thing I need in this case is to install a 64 bits client.
FINAL WORD
Although I don't need SVN server to install subversion on my local environment, I believe it's still worth the lessons learned with this setup and it's still worth to share here on StackOverflow as other guys may need to configure a SVN Server in a Windows 64 bits environment with Apache 64 bits.
Thanks a lot.
FWIW - Apache in uberSVN is self-contained so you should be fine to use uberSVN and still have your newer version of Apache installed for all your other needs.
I have a cluster of servers running apache+mod_python with a MySQL Cluster (NDB) as the database. The code in python uses MySQLdb.
Today I was adding a new package to the web portal that needed PHP. So unaware of the so called mysqlnd internal driver that PHP 5.3 now comes with, I enabled mod_php on the same servers.
This suddenly resulted in total break down of python codes!!! After digging a bit, I noticed that the MySQLdb library is returing integers and other types as string (which the python code is not expecting).
Disabling mod_php from apache fixed it.
My conclusion is that somehow overrides the native mysql driver that handles the NDB stuff in the apache environment and messes up the returns and everything.
Now, my question is that what can I do? Is there a way to tell PHP to use the mysql driver installed in the system and disable the internal mysql driver of it?
Your best bet may be using FastCGI and the new FPM SAPI instead of mod_php. This detaches PHP itself from Apache, which will prevent the library confusion you're experiencing.
(It's also worth noting that if your Python programs use WSGI, then you can also use one of the WSGI-FastCGI adapters instead of mod_python.)
I compiled a PHP extension on Fedora Core 12, but when I send it to someone using CentOS they get the error: "ELF file OS ABI invalid"
I'm not sure what causes this running file provides the following info:
ELF 64-bit LSB shared object, AMD x86-64, version 1 (GNU/Linux), not stripped
An extension that loads fine provides the following from file:
ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped
So it seems I need to generate a SYSV type file for some distributions, instead of a GNU/LINUX file, no idea how though. Any pointers?
Also should I be statically linking?
The statement: "ELF file OS ABI invalid", means that the Application Binary Interface is non compatible between binaries used (i.e. one is trying to mix host and target binaries, which may not work as expected). The e_ident[EI_OSABI] byte of the ELF header contains the operating system/ABI identification. Your Fedora system is setting this to ELFOSABI_LINUX (3) while your friend's CentOS system is setting it to ELFOSABI_SYSV (ELFOSABI_NONE or 0).
You may be able to compile the FreeBSD brandelf utility (brandelf.c) and use it to set the OSABI to ELFOSABI_SYSV (brandelf -f 0 <file> or brandelf -t SVR4 <file>.
I am not aware of any gcc flags for specifying this value at compile/link time. I believe that the version of binutils used by gcc on your Fedora system is responsible for setting the OSABI to Linux. It is my understanding that the linker only specifies the ABI if a STT_GNU_IFUNC symbol ends up in the output file (see ifunc.txt at http://groups.google.com/group/generic-abi for details on STT_GNU_IFUNC).
The readelf(1) command can be used to retrieve and display the ABI information stored in the ELF header (readelf -h <file>).
This similar question may also be of interest.
Compiled object files don't usually transfer well between different linux distributions. Different Distributions often have different policies regarding libraries, where they're stored, how they're loaded.
There's so many differences between them (yes, even in Fedora & RedHat/CentOS). They're likely to supply their own patches to componenets at every level (kernel, PHP, library location). If they're using the distribution PHP package, the distribution might have patched it better intergrate into their system.
The major issue you'll likely run into is that the distribution have used a different libraries/compiler settings. Check to see what verision gcc is on his computer and compare it to what's on yours. (Fedora 12 has quite a few newer libraries than CentOS). That's where your issue might be.
Another possible issue is that your binary is fine, but its incompatible with all the libraries it uses. I'm not sure if there's a good way to get around this one without compiling on the target-distribution (or a varient). You can see what libraries each shared object/executable uses by using the lld <file> command.
Also, was there any output before the error ELF file OS ABI invalid? Most places I see it being referenced there's more information than that.
It's most likely that your friend is not running a 64-bit system. ELF is the standard format for Linux executables, but 32-bit systems can't run 64-bit executables.
Get the output for uname -a from your friend. If the output doesn't contain "x86_64", then he's on a 32-bit version of CentOS.
If so, you either need to set up a cross-compiling environment, or a virtual machine for compiling 32-bit binaries on, or just provide your friend with the sources so that he can compile it himself.