Nós terminamos apenas uploading as versões as mais atrasadas de nossos encaixes de XCache e de eAccelerator, agora na versão 0.6.

Para aqueles de você que faltou anúncio inicial, nós escrevemos dois encaixes isso deixou WordPress comunicar-se diretamente com os esconderijos variáveis memory-resident do opcode PHP que são usados em XCache e em eAccelerator impulsionar o desempenho e diminuir a atividade do I/O.

eAccelerator e XCache é o opcode mais-popular da abr-fonte dois que caching os motores para PHP, e nós recomendamos altamente que alguns e todos os anfitriões o usam melhorar o desempenho de PHP por diversas dobras. No detalhe, nós recomendamos XCache para o mais melhor desempenho.

…

Nós temos trabalhado em mover-se para um usuário novo toda a semana, e nós terminamos apenas a transição. Melhor de tudo, nós temos comutado aos usuários novos sem nenhum downtime in-between. Nosso usuário novo é 1.86 um Duo do núcleo 2 do gigahertz e com o 3GB da RAM DDR2 - todos os agradecimentos aos guys awesome e galões em Lunarpages, o mais melhor anfitrião lá é.

Os muitos do trabalho entraram nesta transição nas esperanças de levantar o desempenho - e mais importante, a confiabilidade - de nosso usuário. No ano passado (desde que nós começamos primeiramente nosso hospedar com LP), nós fomos de diverso milhão batidas um o mês às dúzias dos milhões, e nosso usuário velho fêz exame completamente de uma batida. A essa extremidade, nós focalizamos em desdobrar o código de pouco peso e elevado-optimized toda ao redor; esperançosamente não haverá não mais downtime inesperado… sempre.

Nossa instalação atual do software é muito complicada, mas esperançosamente far-nos-á exame de toda a maneira a 0.00 minutos do downtime - que é nosso objetivo! Nós temos usuários múltiplos e programas da aplicação que funcionam no fundo cada um que faz que ele melhor - em vez do tradicional t--correia-usuário---toda maneira. No momento em que, nós temos atualmente uma pilha do software compreender de um engranzamento do apertado-knit destes produtos:

…

Congratulations are in order for Microsoft’s IIS development team - today they’ve just announced the public availability of the final version of the IIS-FastCGI ISAPI Extension - a long-awaited and much-improved way of running just about any open-source scripting engine on IIS, safely and quickly.

This FastCGI module for IIS 5.1, 6, and 7 (with Windows Vista and Server 2008) have been in the works for quite a while now, and we’ve been using them since the first beta release - they’re good. While the biggest benefit will be seen in using FastCGI w/ IIS7 to take advantage of the new kernel-mode caching, it’s still a huge improvement over the old way of running scripting engines for languages like PHP on Windows.

The Problem: Most open-source scripting engines like PHP and Ruby on Rails were initially developed on/for the *nix world. On Unix-based platforms, the easiest way of creating multi-threaded applications is just to run the same app twice or more (The CGI model). On Windows, that doesn’t work out so well, because it takes a lot more resources to create another process. So these engines released Windows-specific single-process multi-threaded engines; the only problem was, they weren’t stable. Too many race conditions in some very non-thread-safe code wreaked havoc on many Windows systems, with the PHP developers themselves giving “Stability on IIS” the lowest level of concern.

…

For all the Windows-bound PHP users out there, consider yourselves warned: even if you’re running the (supposedly) thread-safe PHP Win32 binary redistribution, you’re still susceptible to PHP Access Violation Errors, race problems, heap corruption, and much worse if you use the popular eAccelerator opcode-caching extension.

We did our testing with the binaries compiled by SiteBuddy using the latest versions of both PHP and eAccelerator. Almost immediately after initiating a stress test on our test servers we experienced the dreaded “PHP Access Violation” error - which brings down the entire IIS Worker Process to its heels.

…

PHP Fatal error:  require_once()[function.require]: Failed opening
required 'SAM/php_sam.php' (include_path='.;C:php5pear') in
sam_factory on line 1

…