Archivio per la categoria "Programmazione"



About Predis and benchmarks: why a pure-PHP Redis client anyway?

As some of you might know I'm the author and maintainer of Predis, a pure-PHP client library for Redis. When I started this project back in mid-2009 Redis was a very young yet promising NoSQL key-value store with only three client libraries available for PHP (one of which was a C-based extension that eventually led to phpredis) offering support only for the Redis commands implemented at that time, and plagued by many bugs. Fast forward to date, and both Predis and phpredis are now the two most used, stable and up-to-date clients in PHP-land among the bunch available. Although it's mostly a one-man project, I'm very proud of the work behind its development and thankful for the contributions received from the community.

So why am I writing this blog post? To cut it straight to the point, I think there's sometimes a little misconception about the very reason for which Predis exists nowadays and Aleksey's recent blog post is offering me a good opportunity to clarify things a bit. Don't get me wrong he made various valid points, but what has actually caught my attention and prompted me to write this post is the very introduction:

As some of you may know, I’m crazy about speed. So when I saw that people were happily using Predis as their choice of PHP client for Redis, I was a bit confused.

Why use a client written in PHP for something that should be ‘fast’ like Redis?

That kind of defeats the purpose - unless you don’t really care about response times and scalability. 

Predis was initially developed to fill the lack for a decent client library but turned into a more comprehensive solution allowing for maximum extensibility. In a sense, you may think of this library not only as a mere client for Redis but as a sort of framework (pass me the buzzword) with various building blocks that developers can leverage to create abstractions for features based upon Redis and expose them through a consistent interface. In my opinion a great example of such extensibility is the abstraction used to support Lua scripts exposing them as if they were common Redis operations such as GET or SET (and it works when using client-side sharding or master/slave replication too). Some parts were also reused to build a fully-asynchronous version of the client!

Obviously there's a price to pay for everything and, in our case, that price is a penalty in raw speed compared to a C-based extension due to the undeniable greater overhead of a pure-PHP implementation. You can mitigate part of this overhead by using PHP >= 5.4 (faster at method dispatching), an opcode cache (you should do that anyway on production servers) or even plugging in phpiredis for faster protocol (de)serialization, but in the end you are optimizing your stack on a single-server basis. You can have 5, 10, 100 servers hitting Redis for distributed operations: that's where Redis shines the best and that's why it's considered blazing fast. In such distributed scenarios, when one or more Redis instances are running on remote hosts, you will soon notice that most of the difference in speed is lost due to network round-trip times so you will be left for the most part with the inherent overhead of compiling the source code (or loading the cached opcodes) of Predis on each request. We've always been clear on what to expect out of Predis in this case and this is the reason why we have a FAQ about performances shipped along with the library. It's a matter of trade offs: you sacrifice a low overhead for the sake of flexibility.

But then again, is it possible to use Predis when you also need decent overall performances or scalability? Depending on your definition of "decent performances" in the context of your application and provided a correct setup and architecture, yes. I personally know of a few high-load web sites using Predis, each one with a different reason behind their choice. Sure, if you don't need fancy features and you only have one server performing requests against Redis running on the localhost then you would probably prefer to stick with phpredis thanks to its lower overhead, but that doesn't mean being able to scale. Is Predis better than phpredis, or the other way around? Simply put, they are two solutions to the same problem and both have their different strong and weak points. In the end you are the one to decide based on your needs but, more importantly and as Aleksey concluded, don't base your decisions on assumptions. And, I'd just like to add, not even on general benchmarks.

This\is\lame\r\n ... è un namespace, almeno in PHP 5.3

Finalmente la lunga saga dell'introduzione del supporto per i namespace in PHP 5.3 è giunta, forse, al termine nelle ultime ore. Finalmente perché la discussione è andata avanti per diversi mesi, con lunghi thread su php.internals aperti in maniera pressoché perpetua ma spesso abbastanza inconcludenti. Vi anticipo fin da subito il finale della storia, ma vi avviso che secondo me non è dei migliori: è stato deciso di sostituire :: con il carattere \ per identificare la separazione dei namespace.

Il problema principale della scelta di :: come separatore per i namespace, secondo i core developer di PHP, risiede nel fatto che in alcuni casi può crearsi un'ambiguità non risolvibile dall'interprete poiché lo stesso :: viene usato anche per accedere ai metodi di classe statici. Ecco un esempio pratico:

1 // -------------------------------------- 2 // primo caso: Classe::methodoStatico() 3 4 class Foo { 5 public static function bar() { 6 echo "Foo::bar()"; 7 } 8 } 9 10 Foo::bar(); 11 12 // -------------------------------------- 13 // secondo caso: Namespace::funzione() 14 15 namespace Foo; 16 17 function bar() { 18 echo "Foo::bar()"; 19 } 20 21 Foo::bar();

L'ambiguità delle righe 10 e 21 risulta evidente, tanto che anche l'interprete in questo caso non saprebbe come comportarsi. Per questo motivo gli sviluppatori di PHP hanno pensato di aggirare il problema cambiando appunto in \ il separatore per i namespace.

Se doveste chiedermi cosa ne penso vi direi che, così di primo acchito e pur non avendo da offrire soluzioni in merito alla questione, per conto mio l'idea non è stata delle migliori. Senza alcun dubbio c'erano dei problemi, ma se da un lato è vero che così vengono risolte possibili ambiguità, con la scelta di \ vedo l'introduzione di bug subdoli dovuti alla mancata attenzione nell'uso della quotazione singola o, in caso contrario, un errato escaping.

$singleQuote = new ReflectionClass('foo\bar\className'); $doubleQuoteWithEscape = new ReflectionClass("foo\\bar\\$classNameInVar");

Ad ogni modo vi fornisco alcuni link la cui lettura può tornarvi utili per farvi un'opinione sulla decisione presa:

Microsoft Silverlight 2.0 RTM, support per Eclipse, port su Symbian. Poi?

Ok anche questa volta penserete allo scherzo ma no, non lo è nemmeno in questo caso. Scott Guthrie, oltre ad aver appena annunciato via conferenze telefonica che domani (14 ottobre 2008) vedrà la luce la versione RTM di Silverlight 2.0, ha dato la notizia che la piattaforma di sviluppo offerta da Eclipse sarà supportata, seppur non direttamente, per la creazione di applicazioni Silverlight:

Microsoft announced plans to support additional tools for developing Silverlight applications by providing funding to Soyatec, a France-based IT solutions provider and Eclipse Foundation member, to lead a project to integrate advanced Silverlight development capabilities into the Eclipse IDE. Soyatec plans to release the project under the Eclipse Public License Version 1.0 on SourceForge and submit it to the Eclipse Foundation as an open Eclipse project.

Potete trovare maggiori dettagli in questa pagina fresca di pubblicazione, inoltre è stato reso noto il sito Eclipse Tools for Microsoft Silverlight su cui è già online e disponibile per il download una prima alpha del plugin per Eclipse con dettagli e istruzioni su alcune modalità di configurazione. Nella stessa pagina si può notare anche una curiosa nota: Windows XP SP2 (or above) or Windows Vista SP1 - Other OS are planned for future versions. In effetti mi chiedo quanti sviluppatori .NET su Windows usino Eclipse, considerazione che riporta un po' tutti con i piedi per terra, però quel futuro supporto per altri sistemi operativi... mah, chissà...

Ad ogni modo l'altra notizia (di cui non ci sono ancora testimonianze ufficiali scritte mentre sto scrivendo) è che a quanto pare Microsoft e Nokia lavoreranno per portare Silverlight su piattaforma Symbian.

Per ora sembrerebbe non esserci altro. E dire che il PDC 2008 è tra meno di quindici giorni...

Ruby Social Club, Milano - Atto terzo: missione compiuta

Anche se con un po' di ritardo, ci tenevo a esprimere la mia soddisfazione per la bella serata che è stata organizzata mercoledì scorso in quel di Milano dai ragazzi di Mikamai per il terzo Ruby Social Club. Una trentina di persone (successone), atmosfera molto informale, talk veloci ma interessanti e una transumata di massa al locale dove sono continuate le discussioni sugli argomenti più disparati tra birra e qualche piatto di cibarie. Purtroppo non sono mai riuscito a partecipare alle precedenti edizioni e devo dire che questa volta è valsa la pena fare di tutto per esserci. Il buon riffraff (a cui tra l'altro devo anche una birra, lo scrivo qui così rimane fino alla prossima occasione) ha già scritto qualche dettaglio sparso sulla serata, per cui non mi dilungherò ulteriormente. Sicuramente ci saranno altri appuntamenti in futuro, per cui... al prossimo RSC 🙂

Microsoft e jQuery (sembra uno scherzo, ma non lo è)

Risale a qualche minuto fa la notizia che Microsoft ha stretto una partnership con il team di jQuery non solo per supportare ufficialmente questa libreria all'interno dei suoi prodotti di sviluppo come Visual Studio 2008 e la versione free di Visual Web Developer ma anche per distribuirla in alcune sue librerie web-oriented come l'ormai prossima ASP.NET MVC o AJAX Control Toolkit. Il supporto negli ambienti di sviluppo sarà fornito inizialmente da un pacchetto scaricabile gratuitamente nelle prossime settimane mentre in futuro sarà integrato direttamente in Visual Studio. Vorrei citare solo due passaggi, il primo dal blog di Scott Guthrie che riporta l'annuncio:

We will distribute the jQuery JavaScript library as-is, and will not be forking or changing the source from the main jQuery branch.  The files will continue to use and ship under the existing jQuery MIT license.

Il secondo invece arriva dal post di Scott Hanselman (e che in effetti riassume uno dei principali motivi per cui questo annuncio mi ha stupito):

Folks have said Microsoft would never include Open Source in the platform, I'm hoping this move is representative of a bright future.

Ecco i rispettivi annunci ufficiali da parte di Scott Guthrie e John Resig (il quale estende la notizia riportando anche la collaborazione ufficiale di jQuery con Nokia).