My Cup of PHP @mycupofphp - Tumblr Blog

My Cup of PHP turned 1 today! Happy Birthday!

PHP and Async requests with file based sessions

We recently ran into an issue where several of our ajax requests were taking an inordinate amount of time to execute. Digging a little deeper into the queries being executed, I was expecting return times in the order of 200ms, not the several seconds I was seeing. Installing XHGui only furthered my confusion: session_start() was the culprit with incredibly high run times. I started exploring how we were storing sessions, the default file store. My first thought was that perhaps there was so many files in the session directory that directory access was slowed (easily fixed with some options onsession.save_path). But we only had a few active sessions and fewer than 100 files. No dice. After some head pounding, I realized the issue: PHP locks the session file for the duration of script execution. The first ajax request took the expected amount of time, but locked the user’s session file for the duration of the request. The second ajax request was blocked on session_start() until the first call had finished. The third ajax request blocked on the first two, and was left with the incredibly high run length that drew me in in the first place.

#php #session #session lock

Sometimes we will get an idea that would create something our limited foresight says will be beautiful. We chase after the idea, regardless of everything. We have unicorns in programming. This morning I want to talk briefly about the approach some of us are trying to make in adding Unicode string support to PHP7.

#php #unicode #unicorn #php7 #php6

A few days ago, I wrote An Open Letter to PHP-FIG. Largely the feedback on it was positive, but not all. So I feel like I do have a few more things to say. What follows is a collection of followups to specific points of contention raised about my post. I'm going to ignore the politics and any non-technical discussion here.

I Don't Understand The Cache Proposal!!!

One point I want to make before we dive into the tech: My post wasn't about the cache proposal. I used it as a literary device. I used it as an example. My point was about the FIG group itself, and the standards they are creating. The points I were making could be applied to any of the recent proposals and discussions they have been having. And they could be applied to any framework or library creator as well. But let's talk about the cache proposal anyway. Let's show why I think the complexity is not necessary. And while this may seem like it's a "strong item vs weak item" debate, it's not (whether get($key) should return the raw item, or an object which can return the item). It's more about using composition instead of inheritance. It's more about creating simple interfaces that we can compose together to make functionality.

#php #caching #PSR

csardelacal

Undefined Index Error in PHP

It happens a lot that we get an undefined index error in PHP on one server that doesn’t happen on another. Let’s see why this happens.

The undefined index error is not fatal, it won’t cause the compiler to stop executing your script and makes this error even more dangerous, since it can cause the application to act up when left untouched.

Two PHP developers fighting over which is faster echo with double quotes vs. echo with single quotes...

// Everyone knows that echo with nowdoc is way faster...duh! echo <<<'HELLOWORLD' Hello PHP World! Why you have so many bad developers? HELLOWORLD;

#php

software-gunslinger

PHP is meant to die

Disclaimer: I’ve got 10+ years on my back as a PHP developer. I started using it when PHP4 was a little boy and PHP5 only a dream in Zend’s mind. I did a lot with it, loved it, cursed it, and saw it grow and evolve, sometimes with great shame. I still use it for some legacy projects, but it’s been a while since it’s not the language of my choice anymore. Also, I’m not affiliated with any framework or tool mentioned here.

TL;DR: If your project will rely on continually-running processes to function, avoid PHP.

In my opinion, a lot of the hatred that PHP receives misses the utter basic point: PHP is meant to die. It doesn’t mean that a perfectly capable (to some extent) programming language will disappear into nothingness, it just means that your PHP code can’t run forever. Now, 13 years after the first official release in 2000, that concept still looks valid to me.

The title of the post is quite obvious. Apache2 + mod_php5 lost the so called “crown” for quite a while. The fist eye opener was a thing that got me pretty annoyed back in 2008. Dual-quad machine, 4 GiB of RAM, RAID 5 SAS @ 10k RPM – the server was looking pretty good, apparently. The only show stopper: Apache2 + mod_php5 that choked at 350 concurrent clients. What? No more free RAM? WTF? LAMP is not my cup of tea for obvious reasons. LEMP seems to be more appropriate while I ditched Apache from all the production servers.

Since then, I keep telling people that Apache2 + mod_php5 + prefork MPM is a memory hog, while most of the stuff comes from the brain-dead client connection management that Apache does. One process per connection is a model that ought to be killed. Probably the best bang for the buck is using nginx as front-end for serving the static objects and buffering the response from Apache in order to spoon-feed the slow clients. But here’s the kicker: for virtual hosting setups, Apache/prefork/PHP is pretty dull to configure safely aka isolate the virtual hosts. Packing more applications together over a production cluster is an obvious way for doing server consolidation.

#php #php-fpm #nginx #apache #highload #scaling php

PHP is a server-side scripting language designed for web development but also used as a general-purpose programming language. As of January 2013, PHP was installed on more than 240 million websites (39% of those sampled) and 2.1 million web servers. Originally created by Rasmus Lerdorf in 1994, the reference implementation of PHP (powered by the Zend Engine) is now produced by The PHP Group. While PHP originally stood for Personal Home Page, it now stands for PHP: Hypertext Preprocessor, which is a recursive acronym.

When developing compilers and interpreters, their source code and its testing procedure are demanded to comply with especially strict quality and reliability requirements. However, there are still some suspicious fragments found in the PHP interpreter's source code.

In this article, we are going to discuss the results of the check of the PHP interpreter by PVS-Studio5.18.

#php #pvs-studio

So if you really wanted to revamp this ancient API you probably want to do away with $_POST/$_GET/$_REQUEST/$_FILES superglobals altogether and really think about this problem for a second.

PHP deals with HTTP directly in many ways. It reads, parses, and sometimes even generates HTTP headers/bodies in key areas. Like when session_start() is called, PHP looks for an HTTP cookie header and seeks out the session_name() cookie then matches it against the available session storage data to either populate or initialize the $_SESSION superglobal.

So why is the HTTP request METHOD important in distinguishing which super global variable we use?

It isn't!

Things php populates $_POST are merely form url encoded parts of the HTTP request body. $_GET is populated from the request header's path string after parsing the query parameters (if any). So realistically anyone requesting support for $_PUT actually doesn't understand how HTTP works or how PHP deals with HTTP requests and how these superglobals are being populated.

The real problem here is that PHP doesn't parse the request body and populate it in $_POST unless the body is properly url encoded according the HTTP spec. Instead, you have to deal with the php://input stream directly and parse it yourself.

The PUT HTTP verb is intended to act upon the destination URI directly as per the enclosed entity, according to rfc2616. Yet, people seem to understand RESTful less than they regurgitate the word.

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource.

So let's forget about HTTP verbs for a second and deal with the HTTP request through some sane (non-backwards-compatible) interface.

First, make PhpRequest a new extensible interface, expose it to userland, and allow the user to override it's implementation with user-implemented classes. Second, stop making the request parsing and content buffer flushing decisions at the RINIT stage. Let's just buffer and delegate to the runtime!

Done. Problem solved. Everyone happy. No more confusing nonsense super globals.

#php 7 #HTTP request #$_PUT #$_POST #$_GET #$_REQUEST

In recent months I've been ultra busy working on our Z-Ray time-warping technology. Now that it's out, I finally had a bit of free time to follow up and on what was clearly a very interesting topic for many in the PHP community - what kind of impact does PHPNG - a massive refactoring effort of the Zend Engine - have on PHP's performance.

#phpng #php 7 #php #hhvm #php 5.4 #php 5.5 #php 5.6

sherifr

PHPNG is beating HHVM… WAT?!?!

(via sherifr)

phptek2013 - Project files for "PHP Extension Writing" tutorial at php|tek 2013

#php #php extension #tutorial

#php

Zuck's engineers unveil formal spec based on PHP 5.6

#php #php specification #php spec

Trending Blogs

Recently Viewed Blogs

My Cup of PHP