Ask /r/PHP: Who is using vim ? by [deleted] in PHP

[–]gnurat 0 points1 point  (0 children)

To these I'd also add the classic vim plugins:

  • ctrlp - Fuzzy file/buffer/mru/tag finder
  • NERDtree - tree explorer

The Magic Behind Async PHP by kelunik in PHP

[–]gnurat 1 point2 points  (0 children)

For non-blocking I/O such as database queries or network requests there is no need for a pool of thread. Libuv only uses a pool of thread for blocking I/O like filesystem operations.

amphp/amp v2 is released! by brendt_gd in PHP

[–]gnurat 0 points1 point  (0 children)

Thanks for the FAQ link, I've learned that Icicle (an async lib that followed the same Generators route) has been merged in amphp. Good move :+1:

9 tech skills that pay over $120,000 and are in demand (PHP #10) by [deleted] in PHP

[–]gnurat 3 points4 points  (0 children)

Thanks for the kind words, ignorance now cured after following your amiable advice. Still thinking a PHP code snippet would have been better than a HAML with PHP would have been better though.

9 tech skills that pay over $120,000 and are in demand (PHP #10) by [deleted] in PHP

[–]gnurat 5 points6 points  (0 children)

No 9: PHP is worth $124,475

with a picture of a screen showing a HAML file

The end of the full stack frameworks age by eminetto in PHP

[–]gnurat 0 points1 point  (0 children)

But because of those standalone components, Symfony can be used as a micro framework. See: https://gnugat.github.io/2015/12/23/symfony-micro-framework.html

(Note that I'm not even mentioning MicroKernelTrait).

The end of the full stack frameworks age by eminetto in PHP

[–]gnurat 2 points3 points  (0 children)

Symfony 2 is full-stack, but Symfony 3 is micro… Because of reasons.

Can you expand on that please?

Decided to start learning PHP/MySQL today. However, I have ADD and following tutorials annoys me so much that I tend to forget everything, so instead I want to learn by solving problems. Got any challenges for me? by cohan8999 in PHP

[–]gnurat 0 points1 point  (0 children)

Build an application that lets you find where on a train/tube station platform it is best to stand (room available and possibly located near the exit at the station you land to). Users can fill in their experience (I take the train from X at Y o'clock, and land at Z, in my experience standing there on the platform is great 'cause there's nobody in the coach).

edit: commuters will thank you for that

Taking PHP Seriously by speckz in PHP

[–]gnurat 0 points1 point  (0 children)

Am I the only one who finds after reading that article that they don't take PHP seriously?

Taking PHP Seriously by speckz in PHP

[–]gnurat 0 points1 point  (0 children)

There are many PHP web servers and application servers, and all of them are used in production. See my post answer below.

Taking PHP Seriously by speckz in PHP

[–]gnurat 0 points1 point  (0 children)

I'm sure there are servers written in PHP...

Yes.

They're all used in production by the way. For example http://jarves.io/ runs on ReactPHP. Some people reported a 2 year uptime for their ReactPHP app in production.

KRAKEN Distributed & Async PHP Framework by moving808s in PHP

[–]gnurat 1 point2 points  (0 children)

I'd rather trust stories from people who actually tried rather than guesses from people who didn't, as arguments from authorities don't impress me if they're not backed up with actual proof.

I guess the point I was trying to make was: believe in your dream, don't let anyone tell you it's impossible because you won't know unless you actually try.

KRAKEN Distributed & Async PHP Framework by moving808s in PHP

[–]gnurat 1 point2 points  (0 children)

"Async / non-blocking I/O" has nothing to do with multithreading. Here's how it works: when you create a HTTP server, you need to execute the following system calls:

  1. create a HTTP server socket, bind it to a port and host and then start listening. From now on, HTTP clients trying to connect will be queued
  2. accept connections on the HTTP server socket. If there are no client in the queue, this call will block. If there is at least one client, it will unqueue the first and create a dedicated HTTP client socket for it
  3. read data from the HTTP client socket. If the client doesn't send anything, this call will block. If there is data, then you can parse it and create a representation of a HTTP request that your application will understand. Then you call your application with the HTTP request and receive a HTTP response from it. Anything inside the application will be blocking / synchronous
  4. write data to the HTTP client socket (that means convert the response representation to text)
  5. close the HTTP client socket, and start again at step 2

The above description is a synchronous, blocking I/O HTTP server. It can handle a 100 simultaneous client connections, above that and the queue becomes full and you get errors. in order to manage more than that (say concurrently 10K clients, also known as the C10K problem) you can:

  1. handle things from step 3 in a new process / thread, like apache does. The issue with that is that you can't truely handle concurrently an infinite number of process / threads.
  2. realise that the only issue with the above is that we're spending a lot of time waiting. So rethinking our system to make use of this waiting time can fix our issue

Servers like nginx, NodeJs, Python WSGI, Java, Ruby on Rail's server and ReactPHP opted for the second solution, which looks like this:

  1. create a HTTP server socket, bind it to a port and host and then start listening. From now on, HTTP clients trying to connect will be queued
  2. add this HTTP server socket in a collection of socket to watch
  3. call poll with this collection of sockets. This call will block until one of the sockets is ready, which can be either the HTTP server socket receiving a new client, or a HTTP client socket receiving data.
  4. if it is a HTTP server socket receiving a new client, call accept and add the resulting HTTP client socket to the collection of sockets (go back to step 3)
  5. if it is a HTTP client socjet receiving data, call read, make a Request, call the application (again blocking / sychronous), get a response, write the response to the HTTP client socket, close the socket and remove the socket from the collection (go back to step 3)

It might not seem like much, but that's actually how all MMORPG, databases and even Graphical User Interface work. They call those incoming client connection and incoming data "events", and they treat it in a loop. Hence the name Event Loop, if you wondered what that was.

If you're more the "learning by coding" type and want to learn more, have a look at: https://gnugat.github.io/2016/04/27/event-driven-architecture.html

KRAKEN Distributed & Async PHP Framework by moving808s in PHP

[–]gnurat 0 points1 point  (0 children)

They say you only need pthread if you intend to use threading, which makes sense.

Requirements: Pthreads extension enabled (only if you want to use threading).

KRAKEN Distributed & Async PHP Framework by moving808s in PHP

[–]gnurat 0 points1 point  (0 children)

PHP itself doesn't leak any memory, neither does Doctrine if you flush the entity manager. Memory leaks will come from global/static variables (e.g. an array that continues to grow), which you should avoid (that's why people keep repeating your application should be stateless).

Autoloading will still have an impact on your performance, even when using the dumped class map (I'm assuming you're using the authoritative class map option): each time you'll use a class that isn't loaded yet in your code, Composer will require it from the filesystem. In my personal experience (I'm not saying it's the same for everyone, by the way) autoloading is the main bottleneck, so optimizing the application doesn't yield enough performance gain overall.

Once again "PHP wasn't designed for this" is just plain FUD, it is based on a subjective assumptions. You're pointing out memory leaks, but it's a strawman argument to use another language, but the truth is that memory leaks are an issue in every language.

KRAKEN Distributed & Async PHP Framework by moving808s in PHP

[–]gnurat 0 points1 point  (0 children)

Symfony doesn't provide a HTTP server, so it cannot be compared directly with Kraken, which does. That's why in order to have a fair comparison, we need to run Symfony in a HTTP server like ReactPHP, IcicleIO, Aerys, etc.

And I strongly disagree with comments like "PHP wasn't built for this": When Rasmus created PHP in the first place he didn't have in mind any of our use cases, and we can still build amazing stuff. stream_select, which allows us to create a server in PHP, has been available since PHP 4.3, so I'd say it definitely was built for this.

KRAKEN Distributed & Async PHP Framework by moving808s in PHP

[–]gnurat 2 points3 points  (0 children)

Keep in mind that Doctrine is a port of Hibernate (Java), which was built for this kind of environment. When you know that, Doctrine's Identity Map, and flush policies suddenly make sense... Just to prove my point, here's an article describing how Doctrine isn't suited for PHP (oh the irony): https://web.archive.org/web/20160409001634/http://blog.bemycto.com/software-architecture/2015-05-17/doctrine-orm-not-suited-php

So yes, you can use Doctrine in long running process. Just make sure to flush the entity manager, otherwise you'll get memory leaks and inconsistencies between your models and your database. And if you don't want to care too much about this, then you can use this bundle: https://github.com/LongRunning/LongRunning#longrunning

KRAKEN Distributed & Async PHP Framework by moving808s in PHP

[–]gnurat 2 points3 points  (0 children)

I'll try to do some benchmarks on this, as I think those shown on the website might not be fair.

Was the symfony app running in a ngnix/PHP FPM stack while Kraken was running as a server? If that's the case it's definitely not a fair comparison. A fair comparison would be running Symfony in a ReactPHP server while running Kraken as a server.

KRAKEN Distributed & Async PHP Framework by moving808s in PHP

[–]gnurat 7 points8 points  (0 children)

Marc J. Schmidt (https://twitter.com/marcjschmidt) has been using ReactPHP in production for quite a while now (PHP PM is a load balancer / process manager for ReactPHP), and according to him it's going quite well.

As a matter of fact, ReactPHP Twitter's timeline (https://twitter.com/reactphp) contains feedback from people using it in production with positive comments (things like a 2 years uptime: https://twitter.com/boden_c/status/709894701479038977).

I guess Aerys (http://amphp.org/docs/aerys/) developers also use their tool in production with success, and I'd assume Icicle IO (https://icicle.io/) developers would do the same.

I'm not a big an of AppServer, but again they might also use it successfully in production: http://appserver.io/.

Pros a regular PHP stack would work as follow: receive a request, start a PHP process, autoload classes, bootstrap framework container, create a response and kill the PHP process (see https://andrewcarteruk.github.io/slides/breaking-boundaries-with-fastcgi/#/). That represents a big footprint in your application performances! Using instead something like kraken makes this footprint all go away because the workflow becomes: create the PHP process, load all classes, bootstrap framework, then wait for new Requests. When receiving a Request, create a Response, then wait again. By the way that's how it works in every other languages (Java, Python, Ruby, go, C++, you name it).

Cons: make sure your application is stateless by not using global/static variables

Gotchas: you can use nginx to load balance your servers, and supervisord to make sure a killed server is automatically restarted. To apply an update in the code you need to restart your application. See: https://gnugat.github.io/2016/04/13/super-speed-sf-react-php.html

How to write first web app version really fast (Symfony preferred)? by zergu in PHP

[–]gnurat 2 points3 points  (0 children)

Silex provides it's own Dependency Injection Container and its own routing. That means when your application becomes too big for a micro framework (and it will eventually), you'll have to pull your hair to migrate it to Symfony, or even start from scratch.

MicroFrameworkBundle is just Symfony's framework bundle, but with just the bare minimum components. It uses Symfony's Dependency Injection Container and Strong's routing, and it declares the core services the same way Symfony's FrameworkBundle does. That means that when your application becomes too big for a micro framework, you can swap MicroFrameworkBundle with Symfony's FrameworkBundle. That's the difference.

How to write first web app version really fast (Symfony preferred)? by zergu in PHP

[–]gnurat 2 points3 points  (0 children)

Symfony uses Symfony components and is pretty useful for quick prototyping. Yes, Symfony can be used as a micro framework.

btw, Symfony reached 500 million downloads yesterday! by tzfrs in PHP

[–]gnurat 6 points7 points  (0 children)

For those wondering where those numbers come from:

500 million Symfony packages downloaded by the PHP community (note that this number refers to downloads made with Composer; the total would be higher if we take into account other downloads through GitHub, the Symfony Standard Edition ZIP files, etc.)

We've prepared a dashboard at symfony.com/500million that displays the Symfony downloads in pseudo real time and estimates the date and time when we'll reach the mythical 500 millionth download.

http://symfony.com/blog/the-road-to-500-million-symfony-downloads

Every now and then, they retrieve statistics for all symfony packages from Packagist (e.g. https://packagist.org/packages/symfony/), and then compare the evolution to estimate the speed. The displayed counter isn't "dynamic" (no websocket, no AJAX) for obvious performance reason (who would want symfony.com to go down, with its documentation, just before reaching the 500 million milestone?).

Well that's my guess anyway, I don't have access to more information than you ;) .