PHP Nuclear Reactor

25. Januar 2017

0 Kommentare

Asynchronous programming is a way to create programs that can execute multiple parallel tasks faster in the same process by executing code while other parts if the programs wait for I/O operations to finish, like database accesses, file accesses, network accesses, etc..

ReactPHP is a low level library similar to JavaScript Node.js that can be used to implement asynchronous programming in PHP, so you can write PHP code that can efficiently access multiple files, databases, or network computers in parallel, making everything faster.

The PHP Nuclear Reactor is library based on PIMF micro-framework that implements the MVC design pattern on top of ReactPHP.

This way you can continue to write PHP MVC components the way you are used to do, and still work well in an asynchronous programming environment based on ReactPHP.

http://gjerokrsteski.github.io/reactphp-pimf/

¬ geschrieben von gjerokrsteski in News und Trends, PIMF

Lean Testing und eine Beobachtung der letzten Jahre – ein Gastbeitrag von Nils Langner

17. Januar 2017

0 Kommentare

Über den Autor: Einige von euch kennen Nils vielleicht aus seinem Blog phphatesme, die anderen von Konferenzen oder ähnlichem. Vor einem Jahr hat er sich aufgemacht das “Lean Testing”-Vorgehen unter die Leute zu bringen. Das liegt hauptsächlich daran, dass diese Testing-Methodik wunderbar zum Internet passt, aber vielleicht auch, weil er mit Leankoala die erste “Software as a Service”-Lösung in diesem Bereich auf den Markt gebracht hat. Ach ja, er schreibt Texte über sich gerne in der dritten Person.

Was haben wir nicht alles die letzten Jahre ausprobiert?! Seit über zehn Jahren habe ich mich jetzt schon in das Thema des Qualitätsmanagements gestürzt. Die meiste Zeit davon im Web. Ausprobiert habe ich fast alles und vieles lieben gelernt. Begonnen haben wir oft mit einfachen Testplänen, die wir dann genutzt haben, um manuell Webseiten durchzutesten, wenn einem das zu blöd wurde, hat man Selenium angeworfen und echte Browser automatisiert ferngesteuert. Danach wurde man etwas mutiger und hat sich Behaviour Driven Development angeschaut. Auch eine feine Sache. Die Testabdeckungen wurden immer ausgereifter und umfänglicher, was leider häufig dazu geführt hat, dass die Wartbarkeit gelitten hat. Alles in allem war man aber glücklich, da trotz des manchmal hohen Aufwandes man trotzdem schneller mit der Testen von Funktionen war, als die Entwickler neue Features rausgebracht haben.

2012, nachdem wir fast alles ausprobiert hatten, was der Markt so zu bieten hatte, wollten wir etwas Neues ausprobieren. Also schrieben wir unser eigenes kleines Werkzeug, um uns zu helfen Tests zu schreiben und durchzuführen. Wir haben es LiveTest2 genannt und es sollte dabei behilflich sein einfache Eigenschaften von Webseiten abzutesten. So konnte man zum Beispiel in einer Konfigurationsdatei sagen, dass auf jeder hinterlegten Seite der String Impressum vorkommen soll. So wollten wir sicherstellen, dass der Footer überall gerendert wird. Ziel war es möglichst einfach simple Smoke-Tests aufzustellen. Ein Test wie dieser muss schnell durchgeführt sein, um zu entscheiden, ob es sich lohnt die teuren, lange dauernden Tests auszuführen. Zu dieser Zeit sind wir zweigleisig gefahren. Einfache Tests als erste Testphase und danach die Tests, die wir mit unserem QA-Stolz gebaut hatten.

Nach einer gewissen Zeit kam dann die angekündigte Beobachtung. Jedes Mal wenn die einfachen günstigen Tests angeschlagen haben, haben uns auch die teuren alarmiert. Und wenn die einfachen Tests gesagt haben, dass alles grün ist, so haben sich die teuren angeschlossen. Daher haben wir erstmal die Theorie aufgestellt, dass LiveTest2 genauso gut ist wie andere Testing-Tools, nur mit weniger initialen Aufwand. Betrachtet man die beiden Herangehensweisen genauer, fällt einem ein großer Unterschied auf. Bei Unit-Tests, BDD-Tests und Selenium-Tests versucht man häufig jeden möglichen Fehlerfall auszutesten. Jeder potentiellen Ursache von Fehlern sollte möglichst ein Test zugeordnet sein. Bei unserer neuen Methodik ging es nicht mehr um Ursachen, sondern um Symptome.

Nehmen wir wieder das Beispiel des Footers. Sobald das Wort Impressum nicht mehr vorhanden ist, wissen wir, dass wir funktionale Probleme haben. Welche Ursache dies hat, können wir anhand des Testes nicht sagen. Der Erfahrung nach ist den Entwicklern dies aber trotzdem sehr schnell klar.

2014 kamen wir dann mit dem Begriff Lean Testing auf, den ich für diese Art des Testens prägen wollte. Dabei geht es darum sich auf Symptome zu konzentrieren und nicht mehr auf Ursachen.

Wenn man eine Weile im Internet unterwegs ist, dann ist einem klar, dass die Anzahl der Symptome, die klassischerweise auftauchen, sehr beschränkt ist. So kommt man mit einem einfachen “Http-Status-Code 200”-Test in der Integrations- oder Stage-Umgebung schon sehr weit. Fügt man dann noch die Möglichkeit hinzu nach Texten zu suchen ist man fast durch. Weil man das Web kennt garniert man das ganze noch mit XPath und Css-Selektoren. Dazu hatten wir 2015 das Open-Source Tool Smoke released, was all diese Tests beinhaltet.

2016 haben wir begonnen diese Methodik in eine “Software as a Service”-Lösung zu gießen und es ist mit dem Anfang dieses Jahre die erste Produktivversion unter www.leankoala.com erschienen.

¬ geschrieben von gjerokrsteski in Externe News & Posts

Why reactive application?

11. Mai 2016

0 Kommentare

Application requirements have changed dramatically in recent years. Only a few years ago a large application had tens of servers, seconds of response time, hours of offline maintenance and gigabytes of data.

Today applications are deployed on everything from mobile devices to cloud-based clusters running thousands of multi-core processors. Users expect millisecond response times and 100% uptime. Data is measured in Petabytes. Today’s demands are simply not met by yesterday’s software architectures.

Traditional applications

reactive-api-with-php_traditional_

Each request is using 2 running processes, one for each instance of HTTP server and database server. The PHP framework might also generate its own additional process.

The HTTP server instance is generating a request object, which is mostly overloaded for later usage.

The database instance is blocking the response until it has finished its task.

The database response is being buffered by the PHP process in order to generate the DTO (data transfer object).

The PHP process is using the DTO to generate a JSON response for the HTTP server instance.

The entire process starting with the HTTP request until serving the response back to the client, is running in the same thread. This uses the CPU’s default behaviour, which leads to an unbalanced usage of CPU cores.

cpu_traditional_application

Reactive applications

We believe that all necessary aspects are already recognised individually: we want systems that are responsive, resilient, elastic and message driven. We call these Reactive Systems.

reactive-api-with-php_reactive

There is no need for a HTTP server. The application is using one single process. PHP and the database (SQLite) are running inside this process.

There is no need for an overloaded HTTP request object. The required data is mostly limited to request method, path and payload.

The response can be sent immediately to the client, while the data is being processed in the background and all necessary steps are being handled in an asynchronuous manner, using events.

The database is not blocking the response, as its task is being handled asynchronuously.

The entire process is happening within one persistent TCP socket, enabling the repsonse to be streamed to the client.

The process is managing its tasks with several threads, balancing the usage of all CPU cores.

cpu_reactive_application

Example Implementation

As an implementation example we used lightweight components which we packed in Docker containers. AlpineOS and Ubuntu already come as Docker images ready to be used.

ReactPHP is responsible for establishing the TCP socket, transferring the raw HTTP request and sending the HTTP response back.

PIMF micro framework is responsible for managing the HTTP resources using the HTTP request methods, validating the data and handling the persistence interaction.

reactive-api-with-php_example

You can find the source code at GitHub: https://github.com/gjerokrsteski/reactphp-pimf

Feel free to fork it and experiment yourself!

Conclusion

Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than disaster. Reactive Systems are highly responsive, giving users effective interactive feedback.

Resources:

The Reactive Manifesto
http://www.reactivemanifesto.org

What is Reactive Programming?
https://medium.com/reactive-programming/what-is-reactive-programming-bc9fa7f4a7fc#.j5m4cnvck

ReactPHP
http://reactphp.org

PIMF
http://pimf-framework.de

Docker
https://docs.docker.com

This is the result of an Exploration Day exercise by Gjero Krsteski and Ralph Bach.

¬ geschrieben von gjerokrsteski in News und Trends, PHP Tricks und Tipps, PIMF

Checkout PIMF Starter Book

28. April 2016

0 Kommentare

pimf-php-micro-framework
This is a hands-on book. You won’t be able to complete it by reading it in a metro on a way to work. You’ll have to read this book while in front of a computer getting your hands dirty. You will learn developing console and web applications as well as micro services. This book is interesting for intermediate developers as well as beginners.

Learning PIMF

One of the best ways to learn PIMF is to read through the entire of its documentation. This guide details all aspects of the framework and how to apply them to your application. http://docs.pimf-framework.de

Read the PIMF Starter book almost anywhere. Available as a PDF, EPUB and MOBI. You can now read it on all devices, as well as offline: http://book.pimf-framework.de

Eventually, you might get stuck and in need of help. Or you might want to write a review or comment on the book’s content. Please post your thoughts on this blog post. If you prefer one-on-one discussion, feel free to send me an email to gjero@krsteski.de, and I’ll give my best to help you out.

¬ geschrieben von gjerokrsteski in News und Trends, PIMF

Powered by Wordpress • Abonniere den RSS Feed