Is php suitable for long-standing background programs?

I currently use php as the background scripting language. Many people say that php is prone to memory leaks, but it has been running well for a month. In addition, php has greatly improved the memory recycle mechanism. In addition, with its simplicity, there is no reason to refuse to use it. I use php as the background scripting language. Many people say that php is prone to memory leakage, but it has been running well for a month. In addition, php has greatly improved the memory recycle mechanism. In addition, with its simplicity, there is no reason to refuse to use it. Except that it does not support multithreading, there is no problem in some areas with low performance requirements.

I don't know whether my considerations are comprehensive and whether there are any omissions.

Reply content:

I currently use php as the background scripting language. Many people say that php is prone to memory leaks, but it has been running well for a month. In addition, php has greatly improved the memory recycle mechanism. In addition, with its simplicity, there is no reason to refuse to use it. Except that it does not support multithreading, there is no problem in some areas with low performance requirements.

I don't know whether my considerations are comprehensive and whether there are any omissions.

Since this is a php questionSuitable or notAs a background resident program, I think we should give a very clear answer, that isNot Suitable

As stated in other answers, it is a good thing that php can implement all functions and memory problems gradually become better, but this is not the reason that php is suitable for doing this. To implement the function, you can use awk + nc to write a web server resident in the background, and the performance is not necessarily worse than php. However, no one will actually use this geek technical solution.

There are three reasons why php is not suitable for doing this:

1. Php is designed to facilitate the construction of dynamic web pages, rather than background services. It is not appropriate to use a language tool to foster strengths and circumvent weaknesses.
2. Php lacks built-in thread and non-blocking mechanisms. The fork-based non-blocking solution has been proven to be inefficient several years ago and is not the most suitable technical solution.
3. Php lacks libraries, frameworks, and success stories for making background resident programs, php is not suitable for other languages that have developed in this field for many years, or languages that are specifically developed to create background programs (such as C, Java, and Go ).

However, even if php is not suitable for background resident programs, it does not prevent it from being used in some situations, such

• When there is no performance pressure and no special requirements on Stability
• You must call a lot of php-written libraries.
• Developers only write php and cannot find better people to implement this project.

In short, it is not necessary to use php as a background program. If it is used and will be available in the future, it is best to rewrite it in other languages.

Before 5.3, it should be a circular reference problem, which is not suitable. After 5.3, there will be no problem.

However, we generally use crontab.

Someone uses PHP as the server. Whether the background is resident depends on the code, not the language.

Since it is comfortable and there is no problem, there is no need to find something.

The reason is not recommended. The exception handling mechanism of PHP is a problem.

Webserver of friend network is written in php.

@ Summic is reserved for this answer... I have implemented webServer and socketServer using php myself...

Use libevent to replace the endless loop... use shmop cache... and use multi-process fork...

I used all the optimizations I could think of... but the performance is still bad...

SocketServer is fine... because you need to maintain persistent connection push...

WebServer can only be used to describe things... it can also be used as toys... there is no way to actually use the production environment...

As for the top floor... Memory leakage or something... dare not say no or dare not say yes...

I only know that my php daemon has been running for a few months... I haven't seen any exceptions when I eat much memory...

MeNoneDeliberately calling gc_collect_cycles () or unset () in the program...

Everything is also running... and I think the php language itself is quite simple...

As long as you don't directly operate on the memory... just do normal operations... it's hard to leak the memory...

The only thing you need to pay attention to is... php's daemon...

If you connect to an external service...Remember to close the previous connection before opening the connection again !!

A lot of php programmers I 've seen don't get used to this anymore... only this one is worth noting when writing daemon...

This is basically the case... all in all... well... No matter what language... just write it smoothly...

After all, there are no brute-force languages, but only programmers who are brute-force...

It is actually a code issue, and there will be no memory leakage during normal code.

Shell is recommended for background scripts, Which is powerful and deeply integrated with the operating system.
Of course, php is also optional. It is recommended for programs that consume CPU or disk I/O to use C or Java for writing, which will improve the performance. Of course, the bad C code may be much worse than the excellent php code, suitable.

Suitable. In addition, the development efficiency is high. Only the best programmers do not have the best language. Does Java, C/C ++ do not expose memory? I am afraid it is more serious. So PHP also has memory leakage. This is not a problem, as long as there is a reasonable mechanism to ensure that the memory can be recycled.

The max_request in the swoole extension is designed to prevent memory leakage. After running for more than a certain number of times, the process is terminated and a new process is created.

Talk with facts:

1. Regular tasks, php fully qualified
2. Long standing in the background, I feel that memory recycling is the biggest problem. The memory consumption of php will continue to grow, which is terrible. I know it only when I have used it.

After all, there are no brute-force languages, but only programmers who are brute-force,