3 ms·

PHP is horrible at long running processes, among other things. We regularly run out of file descriptors and memory usage is a big issue too. The "solution" is f

PHP is horrible at long running processes, among other things. We regularly run out of file descriptors and memory usage is a big issue too. The "solution" is for the process to kill itself every couple minutes and restart with a clean slate. It's a gigantic hack. A long running process on Python, OTOH, is less of a problem. More generally, it becomes pretty clear when you're using a tool for something it's not really meant to do. PHP is an okay programming language/runtime, but there are other tools that would do some of these jobs better, hence our interest in Go and Python.

zer00eyz 11y ago
Python is "less of a problem" but you still may hit that wall. You can do "stupid stuff" in any language and have that same outcome, php just gives more rope than the rest! Recently, on a short term contract, I had to deal with a lot of PHP code that was running in a similar manner. I ended up using golang, to monitor the queue and spin up Goroutines that executed the PHP code ONCE. Between the concurrency, and php back in "one and done" mode the problem was "solved" and the internal team happily took over finishing the porting to pure Golang. Its a great example of Go "in the small" and it really does shine. Go "in the large" is a whole other matter. You should read the following (in this order) http://thenewstack.io/a-survey-of-5-go-web-frameworks/ http://thenewstack.io/a-survey-of-5-go-web-frameworks/ <<< Im a user of gorilla/mux gorilla/context and alice for middleware chains. Gorilla/context and alice are not mentioned by this article, but the lament a the end about the concept of context being lacking in golang is spot on. https://blog.golang.org/context https://blog.golang.org/context <<< but this would be better for context however its does not mix with the current HTTP server (no ones solution does)... its from the go team but there isn't a lot of indication on how to use it and be future proof https://joeshaw.org/net-context-and-http-handler/ https://joeshaw.org/net-context-and-http-handler/ <<< explains the context package well https://github.com/remind101/pkg https://github.com/remind101/pkg <<< has wrappers for getting net/context into gorilla and alice.. The end result is non of the GO web support is what I would call "great" yet. However it isn't stopping me from building with them. Look at the tradeoffs your going to have to make, be smart about how you couple your business logic to your server/framework, as your framework will quickly become a hard dependency. If your careful in that implementation, this http://blog.golang.org/introducing-gofix http://blog.golang.org/introducing-gofix might be a way to back out one of those dependency if your unhappy. The tooling to help you root out an issues exists and you should know its there and how to use it: http://blog.golang.org/profiling-go-programs http://blog.golang.org/profiling-go-programs http://saml.rilspace.org/profiling-and-creating-call-graphs-for-go-programs-with-go-tool-pprof http://saml.rilspace.org/profiling-and-creating-call-graphs-... https://deferpanic.com/blog/compile-time-code-weaving-in-go/ https://deferpanic.com/blog/compile-time-code-weaving-in-go/
- cweagans 11y ago
  Yeah, we definitely won't be writing a web app in Go. We can just build it with Drupal and it'll be fine. Most of what we'd use Python or Go for are small services that handle one thing that run in their own container. https://github.com/progrium/gitreceive https://github.com/progrium/gitreceive is a good example of the kind of services that we'll be building (we didn't build gitreceive, obviously, and we probably won't re-implement it because it's already pretty good. Just wanted to give an example)

zer00eyz 11y ago

Python is "less of a problem" but you still may hit that wall. You can do "stupid stuff" in any language and have that same outcome, php just gives more rope than the rest! Recently, on a short term contract, I had to deal with a lot of PHP code that was running in a similar manner. I ended up using golang, to monitor the queue and spin up Goroutines that executed the PHP code ONCE. Between the concurrency, and php back in "one and done" mode the problem was "solved" and the internal team happily took over finishing the porting to pure Golang. Its a great example of Go "in the small" and it really does shine. Go "in the large" is a whole other matter. You should read the following (in this order) http://thenewstack.io/a-survey-of-5-go-web-frameworks/ http://thenewstack.io/a-survey-of-5-go-web-frameworks/ <<< Im a user of gorilla/mux gorilla/context and alice for middleware chains. Gorilla/context and alice are not mentioned by this article, but the lament a the end about the concept of context being lacking in golang is spot on. https://blog.golang.org/context https://blog.golang.org/context <<< but this would be better for context however its does not mix with the current HTTP server (no ones solution does)... its from the go team but there isn't a lot of indication on how to use it and be future proof https://joeshaw.org/net-context-and-http-handler/ https://joeshaw.org/net-context-and-http-handler/ <<< explains the context package well https://github.com/remind101/pkg https://github.com/remind101/pkg <<< has wrappers for getting net/context into gorilla and alice.. The end result is non of the GO web support is what I would call "great" yet. However it isn't stopping me from building with them. Look at the tradeoffs your going to have to make, be smart about how you couple your business logic to your server/framework, as your framework will quickly become a hard dependency. If your careful in that implementation, this http://blog.golang.org/introducing-gofix http://blog.golang.org/introducing-gofix might be a way to back out one of those dependency if your unhappy. The tooling to help you root out an issues exists and you should know its there and how to use it: http://blog.golang.org/profiling-go-programs http://blog.golang.org/profiling-go-programs http://saml.rilspace.org/profiling-and-creating-call-graphs-for-go-programs-with-go-tool-pprof http://saml.rilspace.org/profiling-and-creating-call-graphs-... https://deferpanic.com/blog/compile-time-code-weaving-in-go/ https://deferpanic.com/blog/compile-time-code-weaving-in-go/

cweagans 11y ago
Yeah, we definitely won't be writing a web app in Go. We can just build it with Drupal and it'll be fine. Most of what we'd use Python or Go for are small services that handle one thing that run in their own container. https://github.com/progrium/gitreceive https://github.com/progrium/gitreceive is a good example of the kind of services that we'll be building (we didn't build gitreceive, obviously, and we probably won't re-implement it because it's already pretty good. Just wanted to give an example)